UDP - The Minimal Transport
UDP (User Datagram Protocol) is transport stripped to the bone. It adds just enough to IP to get data to the right program and to notice corruption - and nothing more. There is no connection, no acknowledgement, no retransmission, and no ordering.
The datagram
A UDP datagram is a single self-contained message with a tiny 8-byte header:
| Field | Bytes | Purpose |
|---|---|---|
| Source port | 2 | reply endpoint (optional) |
| Destination port | 2 | which socket to demux to |
| Length | 2 | header + data size |
| Checksum | 2 | detect corruption in transit |
That is the whole protocol. Each datagram is independent: the network may reorder them, duplicate them, or drop them, and UDP will not notice or care.
Worked example: a DNS query on the wire
A DNS query to 8.8.8.8 might have this actual 8-byte UDP header, in decimal:
| Field | Value | Meaning |
|---|---|---|
| Source port | 51820 | the OS picked this ephemeral port |
| Destination port | 53 | DNS's well-known port |
| Length | 40 | 8-byte header + 32-byte DNS question |
| Checksum | 0x8f3a | computed over header + data + pseudo-header |
The whole datagram - IP header, this 8-byte UDP header, and the 32-byte DNS question - fits in well under 100 bytes, and the reply is often smaller still. That is the entire cost of a DNS lookup: no handshake, no connection teardown, just one datagram out and (hopefully) one datagram back.
No connection, no reliability, no ordering
- No connection - there is no handshake. The first datagram just goes.
- No reliability - a lost datagram is simply gone; UDP never retransmits.
- No ordering - datagrams can arrive in any order; UDP hands them up as they land.
The checksum
The one integrity check UDP keeps is the checksum: the sender sums the datagram (plus a small pseudo-header of IP fields) and the receiver recomputes it. If they disagree, the datagram is silently discarded. The checksum detects corruption; it does not recover from it.
"Unreliable" here means best-effort, not broken. UDP delivers correctly the vast majority of the time on a healthy network. It simply makes no promises - it will not detect or repair the occasional loss, duplication, or reordering. If an application needs those guarantees, it must build them itself (or use TCP).
Low overhead - and when to use it
UDP's appeal is that it gets out of the way: 8 bytes of header, no handshake round-trip, no connection state, no head-of-line blocking. That makes it the right choice when timeliness beats completeness:
- DNS - one small request, one small reply; a lost query is just retried.
- Live video and voice - a late packet is useless anyway, so drop it and keep playing rather than stall waiting for a retransmit.
- Online games - the newest position update matters; a stale one is not worth resending.
Application code that assumes UDP datagrams arrive in the order sent will misbehave the moment routes change mid-stream (common with mobile handoffs or multi-path routing) and two datagrams take different paths. A classic bug: a game or voice app blindly applies "sequence 10" after "sequence 12" simply because that is the order the socket handed them up, corrupting state that depended on ordering. If order matters at all, the application must carry its own sequence numbers and reorder (or discard stale ones) itself - UDP will never do it for you.
A second common failure: sending a UDP payload larger than the path's MTU (often 1500 bytes, 1472 after IP/UDP headers). IP will fragment it, but many firewalls and NAT devices silently drop fragmented UDP traffic as a security policy, so the datagram vanishes with no error on either end - it just never arrives. Keeping payloads under the path MTU avoids relying on fragmentation at all.
UDP vs TCP at a glance
| Property | UDP | TCP |
|---|---|---|
| Connection | none (connectionless) | handshake first |
| Reliability | best-effort, no retransmit | guaranteed delivery |
| Ordering | none | in-order byte stream |
| Flow control | no | yes (rwnd) |
| Congestion control | no | yes (cwnd) |
| Header size | 8 bytes | 20+ bytes |
| Good for | DNS, video, games, VoIP | web, files, email |
TCP trades overhead and latency for guarantees. UDP trades guarantees for speed and simplicity. Pick the one whose promises match what the application actually needs.