L4: TCP vs UDP — Networking

Side by side

Property	TCP	UDP
Connection	Connection-oriented — three-way handshake required	Connectionless — just send
Reliability	Guaranteed delivery via acknowledgment and retransmission	No guarantee — a lost datagram simply vanishes
Ordering	Guaranteed in-order delivery to the application	No ordering guarantee
Flow control	Sliding window (demo below)	None
Congestion control	Yes — backs off automatically when the network is overloaded	None — the application must self-limit
Header overhead	20+ bytes	8 bytes
Typical uses	Web (HTTP), email, file transfer, SSH	DNS queries, voice/video calls, gaming, live streaming

Flow control: the sliding window

A receiver only has so much buffer space. Its receive window tells the sender exactly how many unacknowledged segments it can have in flight at once. Every time an ACK arrives, the window slides forward by one, making room to send the next segment. Try sliding the window yourself:

Window size 5 segments

Congestion control: the TCP sawtooth

Beyond the receiver's window, TCP also tracks its own estimate of how much the network can handle: the congestion window (cwnd). It starts small and grows — fast at first, then cautiously — until a loss tells it to back off. Repeated over time this produces TCP's famous sawtooth shape:

Slow start — cwnd doubles every round trip Congestion avoidance — cwnd grows by 1 per round trip Loss event — ssthresh halves, cwnd drops with it

Hover the chart to read exact values. Why it looks like this: growing exponentially (slow start) would risk overshooting the network's real capacity, so TCP switches to a cautious linear climb (congestion avoidance) once it's in roughly the right range — then treats any loss as a signal it pushed too far, and cuts back hard before climbing again.

When to reach for which

Choose TCP when correctness matters more than latency: a web page, an email, a file — nobody wants a byte silently missing from a downloaded file just because it arrived a little faster.
Choose UDP when timeliness matters more than completeness: in a live video call, a frame that arrives late is useless anyway — better to drop it and move on than have TCP stall everything waiting to retransmit it.
Or build your own reliability on UDP, which is exactly what QUIC (and therefore HTTP/3) does — reliable and ordered per stream, without inheriting TCP's single ordered pipe for an entire connection.

Common gotchas

UDP isn't "unreliable garbage." It's a deliberate choice to skip guarantees an application doesn't need, or plans to build itself, more cheaply than TCP can.
TCP's reliability has a latency cost. Head-of-line blocking means one lost segment stalls everything behind it, even data that already arrived safely.
A bigger window isn't automatically faster. If the window exceeds the path's actual bandwidth-delay product, the extra capacity just sits unused — matching the two is what TCP window scaling exists for.
Congestion control isn't optional politeness — it's what keeps the internet from collapsing. Every TCP flow backing off under congestion is what lets millions of unrelated connections share the same links without a tragedy-of-the-commons meltdown.