The deliberately minimal alternative
If TCP's header is a certified-mail envelope with tracking, delivery confirmation, and enough bookkeeping to detect and refix a lost carton, UDP is a postcard: address on the front, message on the back, dropped in the mail, and the sender simply moves on. No handshake, no acknowledgment, no retransmission, no ordering guarantee, no congestion backoff. If a UDP datagram doesn't arrive, or arrives out of order, or arrives twice, UDP itself will never notice, tell anyone, or fix it. Any application that cares has to handle that itself, or decide it doesn't matter.
| Field | Size | What it holds |
|---|---|---|
| Source Port | 16 bits | The sending application's port; can be all zeros if no reply is expected |
| Destination Port | 16 bits | The receiving application's port, e.g. 53 for DNS (Domain Name System) |
| Length | 16 bits | Size of the UDP header plus data, in bytes |
| Checksum | 16 bits | Integrity check covering the header, data, and parts of the IP header; optional in IPv4, mandatory in IPv6 |
TCP versus UDP, side by side
| TCP | UDP | |
|---|---|---|
| Connection setup | Three-way handshake required | None, just send |
| Delivery guarantee | Reliable, retransmits lost segments | Best effort, nothing retransmitted |
| Ordering | Guaranteed, reassembled in order | Not guaranteed |
| Congestion control | Built in (see Flow & Congestion Control) | None; the application must self-limit if it needs to |
| Header size | 20 bytes minimum | 8 bytes, fixed |
| Typical uses | HTTP/HTTPS, SSH, file transfer, email | DNS, DHCP, VoIP, video conferencing, online gaming |
Why anything would choose less reliability
- Real-time voice and video (VoIP, video conferencing): a dropped or late audio frame should just be skipped, not resent. By the time a retransmission arrived, the moment it belonged to would already be well past. Skipping a frame is a tiny glitch; waiting for a retransmit is a stall everyone notices.
- Online gaming: the same logic applies to position updates. A stale retransmitted position is worse than useless, since a newer one is already on the way.
- DNS queries: a single small request and a single small response. Paying for a full TCP handshake to ask one question is wasted overhead; if the answer doesn't come back, the resolver just asks again.
- DHCP (Dynamic Host Configuration Protocol): runs before a host even has an IP address, and needs to broadcast, something TCP's connection-oriented, unicast design can't do at all.
DNS defaults to UDP, but falls back to TCP when a response is too large for a single UDP datagram (historically 512 bytes, larger with the EDNS0 extension), and always uses TCP for zone transfers between DNS servers. UDP has no mechanism of its own for splitting a response across multiple datagrams and reassembling it, so anything that genuinely needs that borrows TCP instead.