TCP/IP & UDP

7 min read

In a Nutshell

Every byte that moves between machines rides on a stack of protocols, and at the heart of it are IP (which addresses and routes packets between machines) and the two transport protocols that sit on top: TCP and UDP. TCP is the reliable, ordered, connection-oriented workhorse — it guarantees your data arrives complete and in order, at the cost of handshakes and overhead. UDP is the fast, connectionless alternative — it just fires packets off with no guarantees, trading reliability for minimal latency. Choosing between them is a fundamental design decision: TCP for correctness (web, APIs, databases), UDP for speed where occasional loss is acceptable (video calls, games, DNS).

2D minimalistic diagram split in two: left side labeled "TCP" shows two computers doing a three-step handshake then exchanging numbered, acknowledged packets in order; right side labeled "UDP" shows one computer firing a stream of unnumbered packets at another with no handshake and no acknowledgments, one packet dropping away

How It Actually Works

The Network Layers (Simplified)

Data is wrapped in headers as it descends the stack, and unwrapped as it ascends on the other side:

Layer	Job	Examples
Application	App-specific data	HTTP, DNS, gRPC
Transport	Process-to-process delivery	TCP, UDP
Network (IP)	Machine-to-machine addressing & routing	IPv4, IPv6
Link	Physical hop between adjacent nodes	Ethernet, Wi-Fi

IP delivers packets between machines but makes no guarantees — packets can be lost, duplicated, or arrive out of order. TCP and UDP are two different answers to "what do we do about that?"

TCP: Reliable and Ordered

TCP turns IP's unreliable packet delivery into a reliable, ordered byte stream. It does this with:

Three-way handshake to establish a connection: SYN → SYN-ACK → ACK.
Sequence numbers + acknowledgments so lost packets are detected and retransmitted, and bytes are reassembled in order.
Flow control (receiver advertises a window) so a fast sender doesn't overwhelm a slow receiver.
Congestion control (slow start, congestion avoidance) so senders back off when the network is congested.

TCP three-way handshake:
  Client ──── SYN (seq=x) ─────────▶ Server
  Client ◀─── SYN-ACK (seq=y,ack=x+1) ─ Server
  Client ──── ACK (ack=y+1) ───────▶ Server
  ── connection established, reliable byte stream begins ──

UDP: Fast and Fire-and-Forget

UDP adds almost nothing to IP — just ports (to reach the right process) and a checksum. No handshake, no acknowledgments, no ordering, no congestion control. Packets ("datagrams") are independent; some may be lost or reordered and UDP won't tell you. This makes it lean and low-latency, and it pushes any reliability logic up to the application.

TCP vs UDP Side by Side

Feature	TCP	UDP
Connection	Connection-oriented (handshake)	Connectionless
Reliability	Guaranteed delivery + retransmit	Best-effort, may drop
Ordering	In-order byte stream	No ordering
Flow/congestion control	Yes	No
Header overhead	20+ bytes	8 bytes
Latency	Higher (setup + acks)	Lower
Use when	Correctness matters	Speed matters, loss tolerable
Examples	HTTP, TLS, SSH, DB connections	DNS, video/voice, gaming, QUIC base

Head-of-Line Blocking and Why QUIC Exists

TCP's in-order guarantee has a downside: if one packet is lost, everything behind it waits for the retransmission — head-of-line blocking. For a page loading many resources, one lost packet stalls unrelated streams. QUIC (the basis of HTTP/3) solves this by running over UDP and implementing its own reliability with independent streams, so a loss on one stream doesn't block the others — plus it folds the TLS handshake into the connection setup for faster starts.

TCP:   [1][2][✗][4][5]  →  4 and 5 wait for 3's retransmit (blocked)
QUIC:  stream A: [1][✗][3]   stream B: [1][2][3] ← B unaffected by A's loss

2D minimalistic diagram showing the protocol stack as four stacked layers (Application, Transport, Network/IP, Link) with a data packet descending through them on the sender side gaining a header at each layer, crossing the network, then ascending and shedding headers on the receiver side, with TCP and UDP both labeled at the Transport layer

Seeing It in Action

Scenario: Choosing a transport for different parts of a video-conferencing app.

Signaling (who's in the call, mute state, chat):
  → TCP / HTTPS.  Must be reliable and ordered.
    A dropped "user muted" message would leave stale state.

Live audio/video media:
  → UDP (via WebRTC/RTP).  Latency is king.
    A lost frame from 200ms ago is USELESS — retransmitting it
    would only delay newer frames. Better to drop it and move on.
    The app conceals small losses (interpolation) instead.

Why not TCP for media?
  TCP would retransmit the stale frame and head-of-line-block the
  fresh ones → growing delay, "robot voice," frozen video.
  UDP's "just skip it" behavior is exactly right for real-time media.

The rule of thumb: if a late-but-complete delivery is better than a missing one, use TCP. If a fresh-but-lossy delivery is better than a late-but-complete one, use UDP. Real-time media wants freshness; file transfers and APIs want completeness.

Interview Questions

Q: When would you choose UDP over TCP? Hint: When low latency matters more than guaranteed delivery and the application can tolerate (or conceal) loss: real-time voice/video, online gaming, DNS lookups, and metrics/telemetry. For these, a retransmitted stale packet is worse than a dropped one. TCP is the default when correctness and ordering matter (web, APIs, file transfer, databases).
Q: Explain the TCP three-way handshake and why it exists. Hint: SYN → SYN-ACK → ACK. It establishes a connection by having both sides exchange and acknowledge initial sequence numbers, confirming two-way reachability and synchronizing state before data flows. This setup enables reliable, ordered delivery — but adds a round-trip of latency before any data is sent.
Q: What is head-of-line blocking in TCP, and how does QUIC/HTTP/3 address it? Hint: TCP delivers a single ordered byte stream, so one lost packet blocks all bytes behind it until retransmission — stalling even unrelated resources multiplexed on the connection. QUIC runs over UDP with independent streams that have their own ordering, so a loss on one stream doesn't block others; it also merges TLS into connection setup for faster starts.
Q: How does TCP achieve reliability over an unreliable IP network? Hint: Sequence numbers and acknowledgments (detect loss, reorder, retransmit), checksums (detect corruption), flow control via the receive window (don't overwhelm the receiver), and congestion control (slow start / congestion avoidance to not overwhelm the network). IP just routes packets; TCP layers these mechanisms on top.
Q: Why is DNS traditionally over UDP, and when does it fall back to TCP? Hint: DNS queries/responses are small and benefit from UDP's low overhead and no-handshake speed — a single round trip. It falls back to TCP when the response is too large for a UDP datagram (e.g., large record sets, DNSSEC) or for zone transfers, where TCP's reliability and larger payloads are needed.

References

TCP/IP Illustrated, Vol. 1 by W. Richard Stevens — the definitive reference
High Performance Browser Networking by Ilya Grigorik — free online; TCP, UDP, TLS, QUIC
Cloudflare: What is the OSI model? — layered networking explained

Dive Deeper

QUIC and HTTP/3 explained (Cloudflare) — why the industry moved transport onto UDP
TCP congestion control (BBR paper) — modern congestion control
Computer Networking: A Top-Down Approach by Kurose & Ross — the classic textbook