UDP¶

User Datagram Protocol provides no guarantees: no reliability, no ordering, no connection.

When to use: - Real-time: video streaming, VoIP, online games — a dropped frame is better than a delayed one - DNS: single request-response, application retransmit is cheap - QUIC: builds own reliability on top of UDP - Multicast: one sender to many receivers simultaneously

Why video streaming and games use UDP: A retransmitted TCP segment arrives too late to display. For a 60fps game, each frame has a 16ms deadline. If a TCP retransmit takes 50ms, the retransmitted frame is already 3 frames stale — useless. UDP lets the application drop late data gracefully (show the next frame instead of waiting for the old one).

TCP vs UDP header overhead: TCP: 20+ bytes (seq, ack, window, flags, checksum). UDP: 8 bytes (ports, length, checksum). UDP has ~12 bytes less overhead per packet — significant at very high packet rates.

Common pitfall¶

Choosing UDP because "it's faster" without building the reliability the application actually needs on top of it is how a large fraction of buggy real-time systems get built — UDP's raw speed comes specifically from not guaranteeing delivery or order, and an application that silently assumes packets arrive (or arrive in order) anyway will work perfectly on a clean local network and fail unpredictably on a lossy real one. QUIC (the protocol behind HTTP/3) is the concrete proof that this reliability layer is real, non-trivial engineering — it exists specifically because "just use UDP" isn't sufficient on its own for most applications that need some guarantees, just not TCP's specific ordered-stream ones.