2026
UDP: For Fast, Connectionless Data Transmission
UDP skips the handshake, skips the acknowledgements and sends datagrams without waiting to see if they arrived. Here is why that is not a flaw, where it matters and what the eight-byte header is actually doing.
UDP has a reputation problem. Most introductions describe it as the unreliable protocol. Networking courses bring it up after TCP, after the three-way handshake, after sequencing and acknowledgements and retransmission. By the time UDP appears it feels like the fallback you accept when speed matters more than correctness.
That framing is misleading. UDP is not a stripped-down TCP. It is a different design built around a different set of priorities. The protocols share a layer of the stack but they make opposite tradeoffs, deliberately, for reasons that become obvious once you look at what each one is actually used for. Understanding UDP on its own terms is worth doing. It runs under a surprising portion of the traffic on the modern internet.
What UDP actually is
The User Datagram Protocol has been around since 1980. Jon Postel described it in RFC 768. The entire specification fits on three pages. That brevity is not a sign of an early draft. The design was intentionally minimal.
UDP wraps application data in a small header and hands it to IP. That is the full scope of what the protocol does. No connection setup, no delivery confirmation, no ordering guarantee, no congestion awareness. What the application gives UDP goes onto the network. What arrives at the destination gets passed to the application. What does not arrive gets dropped with no notification and no recovery at the transport layer.
The unit of transmission in UDP is a datagram. Unlike TCP which treats data as a continuous byte stream, UDP preserves message boundaries. If an application sends a 100-byte datagram, the receiver gets a 100-byte datagram. Not 50 bytes followed by another 50 bytes on a second read. The boundary is preserved end to end.
The header: eight bytes
A UDP header has exactly four fields. The whole thing is eight bytes. Compare that to TCP's minimum of twenty bytes before options. The simplicity of the header is not an oversight. It reflects what the protocol was designed to do.
Source Port
Identifies the sending process. Optional in the sense that it can be set to zero if the sender does not need a reply. In practice most applications fill it in so the receiver knows where to respond.
Destination Port
Identifies which process on the receiving machine should get the data. This is how the operating system routes an incoming datagram to the right application.
Length
The total size of the datagram in bytes, header included. The minimum legal value is eight, which represents an empty payload with only the header present.
Checksum
Covers the header and payload. Optional in IPv4 but mandatory in IPv6. A failed checksum means the datagram gets silently discarded. There is no notification back to the sender.
UDP datagram structure
Each row represents 32 bits. Header total: 64 bits (8 bytes).
No connection, no state
TCP establishes a connection before any data flows. Both sides go through the three-way handshake, agree on starting sequence numbers, then maintain that state for the life of the exchange. When the transfer is done they go through a formal teardown. The connection exists as a tracked thing on both machines from start to finish.
UDP does none of this. There is no handshake. A process sends a datagram to an address and port. The datagram either arrives at the destination or it does not. The sender has no built-in mechanism to find out which outcome occurred. The receiver has no obligation to respond. From the protocol's perspective, each datagram is an independent event with no relationship to what came before.
Round trip cost comparison
TCP connectionSYN → SYN-ACK → ACK. Minimum one full round trip before any application data moves.UDP datagramData goes on the wire immediately. No setup cost. For short exchanges this is the entire difference.DNS over UDPQuery sent. Response arrives. Total cost: one round trip. No setup, no teardown.DNS over TCPHandshake, then query, then response, then teardown. Four exchanges for what UDP does in one.Why "unreliable" is the wrong framing
Packet drops are the exception on a functioning network. Most UDP datagrams arrive. The protocol does not guarantee delivery. That is not the same thing as saying delivery is unlikely.
Calling UDP unreliable implies something is broken. A more accurate description is best-effort delivery with no feedback loop. The sender fires the datagram. IP tries to route it. If it arrives, the application receives it. If something along the path drops it, there is no retransmission, no notification, no recovery mechanism at the transport layer.
Applications that genuinely need recovery can build it themselves on top of UDP. QUIC does exactly this. It implements selective acknowledgements, stream multiplexing and congestion control at the application layer, over UDP, with tighter control over timing than TCP allows. The protocol is not a ceiling on reliability. It is a floor that applications can build from.
Where UDP is the right choice
The pattern that connects UDP's use cases is the same each time. Either the exchange is too short for TCP's overhead to make sense, the data is time-sensitive enough that late delivery has no value, the application already handles reliability itself, or all three at once.
DNS
A name query is a short question. The answer is short too. One round trip in ideal conditions is all it takes. The overhead of a TCP handshake would cost more than the lookup itself, which is why DNS defaults to UDP on port 53 and only falls back to TCP when the response is too large for a single datagram.
Video streaming
A video frame that arrives late is worse than no frame at all. The stream has already moved on. Retransmitting old video data contributes nothing except more buffering. Applications want the freshest data available, not the most complete history of what was sent.
VoIP
A retransmitted voice packet arriving 400 milliseconds after it was needed contributes nothing to the call. The conversation has moved on. Latency is the enemy here. A gap of silence is preferable to a delayed burst of audio that destroys the flow of speech.
Online games
Player position updates are time-sensitive. Sending the current position matters more than confirming the previous one arrived. Game clients that care about delivery write their own thin reliability layer rather than relying on TCP, which would retransmit stale state the server no longer needs.
QUIC
Google designed QUIC as a UDP-based transport that reimplements reliability selectively. Individual streams within a connection can be reliable without head-of-line blocking stalling the others. It became the foundation for HTTP/3 and is now responsible for a substantial fraction of internet traffic.
NTP
Time synchronisation sends small packets at regular intervals. The protocol can tolerate an occasional missed exchange. What it cannot tolerate is a retransmission arriving after the clock has already been adjusted. UDP keeps the timing clean.
UDP versus TCP
The question is not which protocol is better. It is which tradeoffs match the application. TCP and UDP solve different problems. Both of them do it well.
If data must arrive completely and in order, TCP is the right choice. File transfers, database connections, email, web pages: all of these need every byte. A single missing segment corrupts the result. TCP's overhead is what that guarantee costs.
If freshness matters more than completeness, if the application can tolerate occasional loss, if latency is the primary concern: UDP removes the overhead that TCP demands. The tradeoff is explicit. Neither protocol is hiding something the other one is not.
Well-known UDP ports
UDP uses the same port concept as TCP. Port numbers identify processes on a machine. Ports below 1024 are well-known ports and require elevated privileges to bind to on most operating systems. The protocol is part of the socket identity. A process can listen on UDP port 53 and a different process can listen on TCP port 53 simultaneously on the same machine without conflict.
53DNS — query and response, UDP first with TCP fallback67 / 68DHCP — server on 67, client on 68123NTP — time synchronisation161 / 162SNMP — network device polling and traps514Syslog — forwarding log messages to a central collector4500IPsec NAT traversal — VPN traffic across NAT boundariesEphemeral ports above 49152 are the typical range for client-side assignments. When your machine sends a DNS query, the OS picks an ephemeral source port for that exchange. The DNS server sends its response back to that port. Once the exchange completes the port is released.
Watching UDP in practice
DNS is the easiest place to see UDP at work because every machine does it constantly. A packet capture shows the shape of the exchange clearly.
Capture DNS traffic with tcpdump
$ sudo tcpdump -n -i eth0 udp port 53
12:04:31 IP 192.168.1.5.52341 > 1.1.1.1.53: UDP, length 28
12:04:31 IP 1.1.1.1.53 > 192.168.1.5.52341: UDP, length 44
Two packets. Query out, response back. The source port on the client side (52341 in this example) was assigned by the OS for this exchange. The destination port on both sides is 53. That is the entire transport-layer story for a DNS lookup.
Check open UDP sockets on Linux
$ ss -u -a
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 0.0.0.0:68 0.0.0.0:*
UNCONN 0 0 127.0.0.1:323 0.0.0.0:*
UNCONN 0 0 0.0.0.0:5353 0.0.0.0:*
The state shown is UNCONN because UDP has no connection state to report. There is no established handshake to track. The socket is open and listening. That is all the operating system knows.
Worth understanding
UDP sits underneath a surprising share of the traffic that keeps the internet running. DNS runs on it. DHCP runs on it. NTP runs on it. Every video call you make probably uses it. HTTP/3 is built on QUIC which is built on it. Treating it as a lesser protocol misses how much depends on its particular combination of simplicity and speed.
The eight-byte header is not a limitation. It is a statement about scope. UDP does not try to handle delivery confirmation, ordering, congestion control. Those responsibilities go elsewhere: either to the application layer above it when they are needed, or they get dropped entirely when they are not. That division of responsibility is what makes the protocol composable. You can put exactly as much reliability on top of UDP as your application requires and nothing more.
The next time a connection times out with no response, the question worth asking is whether the traffic uses TCP. A TCP connection that never receives a response means a SYN is getting dropped somewhere. A UDP exchange that produces no reply is harder to distinguish from loss. The protocol does not tell you. A packet capture does. Knowing which transport you are dealing with shapes how you start looking.