"TCP is reliable, UDP is fast" is the bumper sticker. True, but the interesting question is why you'd ever choose UDP. For decades the answer was niche (DNS, streaming). Now — with QUIC, WebRTC, and modern games — UDP is everywhere under a reliability layer you built yourself. Understanding the tradeoff means understanding what TCP gives you and what it costs.
UDP offers none of this. It's a thin wrapper around IP: fire and forget, per-packet, no delivery guarantee, no ordering, no session.
Three scenarios where TCP hurts:
1. Real-time media. Voice or video: the packet for frame 42 got lost. TCP insists on retransmitting it before delivering frame 43. By the time frame 42 arrives, it's 300ms late and useless — better to skip it and stay current. UDP lets the application choose "skip" without argument.
2. High-frequency small messages. DNS queries, game server updates at 60 Hz. TCP handshake is 1 round-trip. UDP has zero. For short-lived exchanges, TCP setup is more expensive than the payload.
3. Head-of-line blocking across streams. HTTP/2 multiplexes many streams over one TCP connection. If one packet is lost, ALL streams stall until TCP retransmits it — even streams with no lost packets. HTTP/3 (QUIC over UDP) fixes this.
"Fast vs reliable" is misleading. TCP's reliability mechanism causes latency spikes you can't control. UDP lets you build your own reliability tuned for your use case.
| Property | TCP | UDP |
|---|---|---|
| Delivery | Guaranteed (or connection errors) | Best effort — may drop |
| Ordering | In-order | No ordering |
| Connection | Stateful (3-way handshake) | Stateless (no handshake) |
| Congestion control | Built-in | Your responsibility |
| Header overhead | 20 bytes | 8 bytes |
| Setup RTT | 1 (handshake) | 0 |
| Head-of-line blocking | Yes | No |
| Use for | Web, email, most APIs | DNS, video, games, QUIC/HTTP3 |
HTTP has always run on TCP. HTTP/2 (2015) multiplexed many streams over one TCP connection — great in theory, bad in practice because of head-of-line blocking. One lost packet stalled all streams.
QUIC (Google, 2012; standardized 2021) solved this by building a new transport on UDP:
Google and Cloudflare deploy QUIC for 30–40% of their traffic today. The ironic summary: the most important new network transport of the 2020s is UDP-based — not because TCP is bad, but because rebuilding its reliability in userspace was easier than fixing TCP.
Anything where you can't tolerate dropped data. Almost every API.
Low-latency, small-message, loss-tolerant.
When you want TCP's guarantees but not its policies.
30–40% of Google/Cloudflare traffic. Default in new browsers. On by default at most major CDNs.
WhatsApp uses UDP for voice/video (tolerates loss). Video conferencing uses UDP + custom jitter buffering. PUBG uses UDP for game-state sync (latency beats reliability). Live streaming uses UDP-based protocols (SRT, QUIC) for low-latency ingest.
