TCP vs UDP

In 1974, Vint Cerf and Bob Kahn published a paper titled "A Protocol for Packet Network Intercommunication." It described a single unified protocol they called TCP — Transmission Control Protocol. The idea: a computer sends a stream of bytes to another computer, and the protocol guarantees they arrive in order, with no duplicates, no missing bytes, and no corruption. If a packet is dropped by the network, TCP retransmits it. If two packets arrive out of order, TCP reorders them. If a network is congested, TCP slows down.

Six years later, in 1980, Jon Postel wrote RFC 768 — a 3-page specification for a different protocol called UDP — User Datagram Protocol. UDP does exactly one thing: sends a packet from one process to another. No retransmit. No ordering. No congestion control. No connection. If a packet is dropped, it's gone. If two packets arrive out of order, tough. UDP is 8 bytes of header wrapped around your data.

Why would anyone use UDP? Because for some workloads, reliability costs more than it's worth. Video streaming: a dropped frame from 2 seconds ago is worse than useless — it's stale. Online gaming: a re-sent "player position" from 100ms ago is nonsense. DNS: a single UDP packet is faster than 3 round trips of TCP handshake for a 40-byte query. When latency matters more than reliability, UDP wins. When reliability matters more than latency, TCP wins.

What layer? Both are Layer 4

TCP and UDP are both Layer 4 (Transport) protocols in the OSI model. They sit above IP (Layer 3) and below the application (Layer 7). Their job is the same: get data from a process on one host to a process on another host. They just do it differently.

The TCP 3-way handshake — how a connection starts

Every TCP connection begins with a 3-way handshake. This is why the very first packet of an HTTP/1.1 or HTTP/2 request has ~1 round-trip of latency before any real data flows.

The handshake exchanges initial sequence numbers (ISNs) so both sides can track what's been sent, received, and needs retransmit. It also lets each side confirm the other is reachable and willing to talk. The cost: 1 RTT of latency before your HTTP GET even leaves the client. On transatlantic links (~80ms RTT), that's 80ms of overheadper connection. This is why HTTP/1.1 introduced keep-alive (reuse connections), why HTTP/2 multiplexes many streams per connection, and why HTTP/3 moved to UDP-based QUIC (which combines handshake with TLS handshake for 0-RTT).

TCP reliability — how it works

TCP provides reliable, ordered, exactly-once byte delivery over an inherently unreliable network. Four mechanisms make this work:

• Sequence numbers — every byte has a unique 32-bit sequence number. Receiver can detect gaps and duplicates.
• Acknowledgments (ACKs) — receiver periodically sends back "I've got everything up to byte N." Sender retransmits anything not ACKed within a timeout (RTO — Retransmission Timeout).
• Sliding window flow control — receiver tells sender "I have room for the next 64 KB right now." Sender never overwhelms receiver.
• Congestion control — sender starts slow, ramps up until packet loss is detected, then backs off. CUBIC (Linux default 2004+) and BBR (Google, 2016+) are the modern algorithms.

UDP — everything TCP is not

UDP has none of TCP's mechanisms. No handshake. No sequence numbers. No ACKs. No retransmit. No flow control. No congestion control. Just 8 bytes of header (source port, destination port, length, checksum) around your data. You send a UDP packet; it arrives, or it doesn't. The kernel doesn't track it. There's no connection state.

UDP's minimalism is its power. A UDP packet has no setup cost — first byte can be application data. UDP has no head-of-line blocking — if packet 47 is dropped, packet 48 is still delivered immediately. UDP has no congestion control — but modern UDP-based protocols (QUIC, WebRTC) implement their own, smarter than TCP's.

Side by side — the head-to-head

When to pick each — a real-world guide

QUIC — the third option (2021)

For 40 years the choice was binary: TCP or UDP. In 2021, Google shipped QUIC (Quick UDP Internet Connections, RFC 9000) — a new transport protocol built on UDP that gives you TCP's reliability + ordering + flow control plus UDP's absence of head-of-line blocking, 0-RTT connection setup, and integrated TLS 1.3.

QUIC lives in userspace, not the kernel — so it can be updated faster (Google ships QUIC changes weekly to Chrome). QUIC streams are independent — if one stream stalls, others keep flowing. QUIC survives IP changes (your phone switches from WiFi to LTE, QUIC keeps the connection going via a connection ID). HTTP/3 runs entirely on QUIC.

Applied in real systems — a lot of examples

The choice between TCP and UDP shows up in every system design. Here's a wide sample of real-world usage.

Key takeaways

• Both are Layer 4 (Transport). TCP and UDP both sit above IP and below your application. Ports are their addressing scheme.
• TCP = reliable, ordered, connection-oriented. 3-way handshake, sequence numbers, ACKs, retransmit, congestion control. Adds ~40 bytes header + 1 RTT setup.
• UDP = fire-and-forget, connectionless. 8 bytes header, no setup. Packet delivered or not — no promises.
• Pick TCP when reliability > latency: HTTP, databases, SSH, file transfer, email. Pick UDP when latency > reliability: real-time video, gaming, DNS, NTP.
• QUIC (2021) is a third option — reliability + speed by running on UDP with its own smarter reliability layer. HTTP/3 uses QUIC. ~40% of internet traffic now.
• Head-of-line blocking is TCP's Achilles heel: one dropped packet stalls every subsequent packet on that connection. QUIC / HTTP/3 solved this.
• TCP is slower to start (handshake) and slower under packet loss (retransmit + window shrinking). UDP has no such overhead.

References

• Cerf & Kahn (1974) — A Protocol for Packet Network Intercommunication. IEEE.
• RFC 793 (1981) — TCP specification.
• RFC 768 (1980) — UDP specification. 3 pages.
• Jacobson (1988) — "Congestion Avoidance and Control." The paper that made TCP work under congestion.
• RFC 9000 (2021) — QUIC v1 specification.
• Cardwell et al. (2016) — "BBR: Congestion-Based Congestion Control." Google's modern TCP congestion algorithm.