User Datagram Protocol: Simple, Fast, Unreliable
UDP (User Datagram Protocol) is a transport-layer protocol that provides a minimal, connectionless interface between applications and the IP network layer. Unlike TCP, UDP makes almost no guarantees — it simply takes data from an application, wraps it in a small header, and hands it to IP for delivery. This simplicity is UDP's greatest strength: it adds virtually no latency, no connection setup cost, and no per-connection state.
UDP Header
The UDP header is exactly 8 bytes — the smallest possible transport header:
| Field | Size | Purpose |
|---|---|---|
| Source Port | 2 bytes | Identifies the sending application (0-65535) |
| Destination Port | 2 bytes | Identifies the receiving application |
| Length | 2 bytes | Total datagram size (header + payload), minimum 8 bytes |
| Checksum | 2 bytes | Optional in IPv4 (mandatory in IPv6); covers header, payload, and a pseudo-header from IP |
That is it. No sequence numbers, no acknowledgments, no window sizes, no connection state. Each UDP datagram is independent — the protocol provides no mechanism to relate one datagram to another.
What UDP Does NOT Provide
Understanding UDP means understanding what it deliberately omits:
- No connection establishment — there is no handshake. The sender fires off datagrams without knowing whether the receiver is even listening. This eliminates the round-trip latency of TCP's three-way handshake.
- No reliable delivery — if a datagram is lost in transit (router drops it due to congestion, bit error, etc.), UDP does not detect the loss and does not retransmit. The application must handle loss if it matters.
- No ordering — datagrams may arrive out of order. UDP delivers each independently. If datagram 5 arrives before datagram 3, the application receives them in that order.
- No flow control — UDP has no mechanism to slow down a fast sender that is overwhelming a slow receiver. The receiver's buffer may overflow, silently dropping datagrams.
- No congestion control — UDP does not reduce its sending rate when the network is congested. This can be both an advantage (low latency) and a problem (UDP floods can starve TCP flows).
Why Use UDP?
Despite these limitations, UDP is the right choice for several important use cases:
DNS (Domain Name System): DNS queries are small (typically under 512 bytes) and need fast responses. A single UDP request-response pair completes in one round trip. If the response is lost, the client simply retries after a short timeout. The overhead of establishing and tearing down a TCP connection for a tiny query would be wasteful.
Video and Audio Streaming: Real-time media tolerates occasional packet loss — a dropped video frame causes a brief glitch, but the stream continues. Retransmitting a lost frame would arrive too late to display, adding latency without benefit. RTP (Real-time Transport Protocol) runs over UDP, adding sequence numbers for reordering but leaving retransmission out.
Online Gaming: Games require ultra-low latency for player input. A 50ms retransmission delay is worse than dropping one position update, because the next update is already on its way. Games often implement their own lightweight reliability on top of UDP, retransmitting only critical data (e.g., "player joined") while letting frequent updates (e.g., position) go unreliably.
QUIC Protocol: QUIC, the protocol behind HTTP/3, is built on top of UDP. It implements its own connection management, reliability, ordering, and congestion control in user space — giving it the flexibility to evolve without waiting for operating system TCP stack updates. By running over UDP, QUIC avoids middlebox interference (firewalls and NATs that understand TCP may modify or block non-standard TCP behavior).
UDP Checksum
The UDP checksum covers the UDP header, the payload, and a pseudo-header extracted from the IP layer (source IP, destination IP, protocol number, UDP length). This pseudo-header ensures that a datagram delivered to the wrong IP address or port is detected. In IPv4, the checksum is optional (a value of 0 means "not computed"). In IPv6, it is mandatory because IPv6 dropped the IP-layer header checksum.
Real-Life: DNS Resolution Over UDP
When you type google.com in your browser, a DNS lookup happens before any HTTP connection:
1. Application sends query: The DNS resolver builds a query message ("What is the A record for google.com?"), wraps it in a UDP datagram with destination port 53 (the well-known DNS port) and a random source port (e.g., 49152), and sends it to the configured DNS server (e.g., 8.8.8.8).
2. One round trip: The DNS server receives the datagram, looks up the answer, and sends a UDP response back to the client's source port. Total time: one network round trip (e.g., 10-50ms). With TCP, this would require a 3-way handshake (1.5 RTT) plus the query-response (1 RTT), totaling at least 2.5 RTT — much slower.
3. Loss handling: If the client does not receive a response within 1-2 seconds, it retransmits the query. After a few retries, it tries the next DNS server in its configuration. This simple timeout-and-retry is adequate because the entire query fits in one datagram.
4. Large responses: If the DNS response exceeds 512 bytes (e.g., DNSSEC signatures), the server sets a "truncated" flag in the UDP response. The client then retries over TCP, which can handle arbitrarily large responses. This is the exception, not the norm.
Why not TCP for all DNS? A busy DNS resolver handles millions of queries per second. Maintaining a TCP connection (with its state: sequence numbers, buffers, timers) for each would consume enormous memory and CPU. UDP's stateless nature allows the server to process each query independently with minimal overhead.