Networking
UDP — User Datagram Protocol
The minimal transport built on IP: adds only port numbers and an optional checksum, and nothing else. No connection setup, no ordering, no retransmission, no congestion control — all of that is left to the application, if it needs it at all.
- What it is
- The minimal transport on top of IP: adds only ports and an optional checksum, nothing else.
- Mental model
- Dropping a postcard in the mail: fast, cheap, no confirmation it arrived, and no automatic resend if it doesn't.
- Key numbers
- 8-byte header (vs. TCP's 20+); no connection setup, no retransmission by default.
- Reach for it when
- Low overhead matters more than guaranteed delivery, or the application already handles its own reliability (e.g. CoAP).
What the header actually adds over raw IP
- Source port
- 16 bits — identifies the sending application/socket.
- Destination port
- 16 bits — identifies the receiving application/socket.
- Length
- Size of the UDP header + payload.
- Checksum
- Optional in IPv4, mandatory in IPv6 — covers header and data, catches corruption but not loss or reordering.
That's the entire header — 8 bytes, versus TCP's minimum 20.
A sensor sends the 2-byte value 0x0419 (1049) from port 51820 to port 5005. The bytes
leaving the network card look like this:
CA 6C13 8D00 0A3F 2E04 19
src port 51820 · dst port 5005 · length 10 (8 header + 2 data) · checksum · data = 0x0419
Message boundaries are preserved
Unlike TCP's byte stream, one sendto() call produces exactly
one datagram, and one recvfrom() call returns exactly that
datagram (or nothing) — never a partial piece of it and never merged
with another. This makes UDP a natural fit for protocols that are
already message-shaped (DNS queries, single-frame telemetry, etc.).
Why choose UDP over TCP
| Use case | Why UDP fits |
|---|---|
| DNS queries | Single small request/response — TCP's handshake overhead isn't worth it for the common case. |
| Real-time media (VoIP, video) | A late retransmitted packet is worse than a dropped one — the application handles loss itself. |
| Simple LAN telemetry / broadcast-discovery | Low overhead, and UDP supports broadcast/multicast, which TCP structurally cannot (it's point-to-point). |
| Constrained IoT devices | CoAP builds a REST-style protocol on UDP specifically to avoid TCP's per-connection RAM and handshake cost on small devices. |
What "unreliable" costs you if you build on it anyway
Any application-level guarantee — ordering, retransmission, deduplication, congestion-aware pacing — has to be built by hand on top of UDP if it's needed. This is a real, non-trivial amount of the complexity that TCP already solved; it's only worth reinventing when TCP's specific behavior (in-order delivery blocking newer data behind a lost old packet, for instance) is actually the wrong fit for the application. See TCP vs. UDP for the full side-by-side tradeoff.
Real-world applications
- DNS — the domain name lookup that runs before nearly every internet connection is a single UDP request/response.
- CoAP-based IoT devices — constrained sensors and actuators (see CoAP) use UDP specifically to avoid TCP's connection-state cost.
- Video calls and streaming — WebRTC and most real-time video/audio protocols use UDP because a dropped frame is better than a stalled one — see Jitter for why irregular delay, not just average latency, is what actually wrecks call quality.
- Network Time Protocol (NTP) — time synchronization is a lightweight UDP exchange, precisely because low, predictable overhead matters more than guaranteed delivery.
- Firmware/device discovery on a LAN — UDP broadcast is how many IoT devices announce themselves on a local network before any connection is established.
"Unreliable" doesn't mean "usually broken" — on a healthy LAN, UDP datagram loss is often rare. It means the protocol makes no promise, so an application that needs a guarantee must provide it itself rather than assuming the network will.