UDP — User Datagram Protocol

UDP is the minimalist transport. Its header is 8 bytes — source port, destination port, length, checksum. There is no sequence number, no ack, no window, no congestion state. You call sendto() and the kernel fires a datagram at the network. The kernel does not know if it arrived. The kernel does not know if datagrams arrived in order. The kernel does not even know if the destination is alive.

This sounds bad, but it is exactly what some workloads need. The cost of TCP's guarantees is latency: every byte must wait for its turn (ordering), the sender must wait for acks (reliability), the connection must slow down on loss (congestion control). For a workload where stale data is useless — a video frame from 200ms ago, a game position update from 100ms ago — these guarantees are pure overhead. Better to drop the stale packet and move on.

The canonical UDP use cases share one trait: late data is worse than missing data.

DNS. A query is one datagram; the response is one datagram. If it does not arrive, the resolver retries. There is no value in TCP's reliability here — you would pay 1 RTT of handshake for a request that is itself one RTT. (DNS does fall back to TCP for large responses over 512 bytes or for zone transfers, but the default is UDP.)

Voice and video. A video call sends 30-60 frames per second. If frame 47 is lost, the player interpolates from frame 46 and 48 — the user sees a brief glitch, not a stalled call. Retransmitting frame 47 would make it arrive 100ms late, which is useless and consumes bandwidth competing with the current frame. UDP lets the codec fire-and-forget; modern codecs (Opus, VP8, H.264) are designed to tolerate loss.

Online games. A shooter's player position updates 20-60 times per second. The current position is all that matters; an old position is not just useless, it would be wrong to display it. UDP lets the server send the latest position; the client uses whatever arrives and ignores gaps.

Live streaming. RTP, SRT, and similar protocols run over UDP for the same reason: late frames are useless, and the bandwidth saved by not retransmitting is better spent on the next frame.

Application-level transports. QUIC (HTTP/3) and WebRTC both run over UDP because they need to implement their own reliability semantics that the kernel's TCP cannot provide: per-stream reliability, 0-RTT setup, connection migration across networks, and custom congestion control optimized for the application.

UDP itself is unreliable, but many UDP-based protocols add back exactly the reliability they need — and nothing more. This is the key insight: reliability is not binary, it is shaped to the workload.

• TFTP adds simple stop-and-wait ACKs for file transfer.
• QUIC adds selective ACKs, per-stream retransmission, and CUBIC/BBR congestion control — essentially rebuilding TCP but with independent streams.
• WebRTC adds NACK (negative acknowledgements), FEC (forward error correction), and bandwidth estimation tuned for real-time media.
• DNS over UDP adds 'just retry the whole query' — the simplest possible reliability.

The reason these protocols do not just use TCP is that they need control over what gets retransmitted. TCP retransmits everything, in order, blocking everything behind it. A real-time protocol wants to retransmit the latest I-frame in a video stream, skip the stale P-frames, and keep the audio stream flowing — priorities TCP cannot express.

The cost is complexity. Building reliability on UDP means you are now responsible for sequence numbers, retransmission timers, congestion control, and security (DTLS, since you cannot use TLS directly over UDP). QUIC is roughly the size of TCP and TLS combined — it is not a 'simpler' protocol. It is a protocol that gives the application the freedom to make different trade-offs than TCP made in 1988.

Two practical consequences every engineer should internalize about UDP.

First, a naive UDP sender is dangerous. Unlike TCP, UDP has no congestion control built in. If your application just sends as fast as it can, you will saturate the link and starve TCP flows (TCP backs off, UDP does not). This is exactly what caused the 1986 internet congestion collapse and why Van Jacobson added congestion control to TCP. Modern UDP-based protocols — QUIC, WebRTC, RTSP — all implement their own congestion control (often BBR or GCC). If you build a custom UDP protocol without one, you are committing a network crime.

Second, UDP datagrams have a size limit you must respect. The theoretical max is 65507 bytes (the UDP length field minus header), but in practice anything over the path MTU (typically ~1500 bytes after IP+UDP headers, so ~1472 bytes of payload) gets fragmented at the IP layer. Fragments that lose any piece are discarded wholesale — a 1473-byte datagram sent as two fragments has roughly 2x the loss probability of a 1472-byte datagram sent whole. Production UDP protocols stay under the MTU (often 1200 bytes to be safe across all path MTUs) or implement their own segmentation and reassembly (which is what QUIC does, with its own per-stream frame boundaries).

These two facts shape every real UDP deployment. DNS stays tiny (one datagram, one response). Voice uses small packets (20ms of Opus audio is ~80 bytes) so loss is fine and bandwidth is cheap. Video uses larger packets but accepts that losing one means losing a frame, not a stream. QUIC keeps packets under MTU and implements its own congestion control. The pattern: UDP gives you a sharp tool; you have to wield it with discipline.

UDP failure scenarios — what breaks in production.

(1) Amplification attack. DNS over UDP is the textbook example: a 60-byte spoofed query triggers a 4000-byte DNSSEC response, ~70x amplification. The attacker forges the source IP to be the victim's; DNS resolvers worldwide pummel the victim. Mitigation: DNS Cookies (RFC 7873), rate-limiting per source IP, and response-size limits.

(2) NAT timeout mid-call. Home NAT boxes expire UDP mappings after 30 seconds of inactivity. A video call that pauses audio for 60 seconds (mute, hold) loses its NAT mapping — audio never returns even when unmuted. This is why every WebRTC client sends STUN keepalives every 20 seconds, and why your video call occasionally needs to be re-initiated.

(3) Path MTU surprises. A 1473-byte UDP datagram fragments at the IP layer into two fragments. If either fragment is lost, the entire datagram is dropped — so a 0.5% per-fragment loss rate becomes a ~1% datagram loss rate, doubling effective loss. Modern QUIC implementations aggressively stay under 1200 bytes per packet to avoid fragmentation across path-MTU-discovered paths.

(4) No congestion control collapses the network. A naive UDP video sender that does not implement BBR or CUBIC will saturate the bottleneck link and starve TCP traffic (which DOES back off). This is the 1986 internet congestion collapse pattern, repeated in modern clothes — it's why every production UDP protocol (QUIC, WebRTC, RTSP) ships with its own congestion control.

(5) Corporate firewall blocking. Many enterprises allow TCP 443 by default but block or rate-limit UDP. A QUIC deployment without TCP fallback will silently fail for 10-20% of corporate users. This is why browsers fall back to HTTP/2 over TCP when QUIC fails — and why 'we run on UDP' is a deployment problem, not just a protocol choice.

UDP scaling implications.

UDP scales to enormous aggregate throughput because the kernel keeps no per-connection state. A single Linux box can service hundreds of thousands of concurrent DNS queries per second because each query is one datagram in, one out, with no handshake, no retransmission buffer, no congestion window. Compare to TCP: each connection requires kernel memory for send/receive buffers, congestion state, and timers — typically 10-50 KB per connection, which caps a single machine at ~100K-1M concurrent connections (the well-known C10K problem, extended to C1M).

This is exactly why DNS resolvers, NTP servers, and QUIC terminators can handle millions of concurrent clients on modest hardware. It's also why Redis (single-threaded, in-memory, custom protocol) used to support UDP for sub-millisecond lookups before deprecating it for security reasons.

But the scaling advantage disappears the moment you implement reliability on top. A QUIC terminator that tracks per-stream ACK state and retransmission buffers uses kernel-or-userspace memory similar to a TCP terminator. The 'UDP is more scalable' truth only holds for fire-and-forget workloads: DNS, syslog, SNMP traps, VoIP keepalives. For everything else, UDP is a substrate that lets the application choose its scaling trade-offs — but the application then has to actually make those choices.

Mental model. Think of UDP — User Datagram Protocol as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does UDP — User Datagram Protocol mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose UDP — User Datagram Protocol, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.