TCP Deep — Handshake Cost, Congestion Control & Head-of-Line Blocking

The internals of TCP that actually bite you

You know TCP is reliable and ordered (see Networking Fundamentals). The systems-relevant question is why a service feels slow even when the network "works" — and the answers are connection setup, congestion control, and head-of-line blocking.

1. A new connection is slow on purpose

• Handshake: the 3-way handshake costs 1 round trip before any data flows (TLS adds another 1–2). Across a continent that's 100s of ms per new connection — which is why connection pooling / keep-alive matters so much: amortize the setup.
• Congestion control (slow start): TCP doesn't blast at full speed; it starts small and ramps the congestion window up (AIMD — additive increase, multiplicative decrease on loss). So a fresh connection is slow for the first few round trips and speeds up — another reason to reuse connections.

2. Head-of-line (HOL) blocking

TCP guarantees ordered delivery, so the application can't receive byte N+1 until byte N arrives. If one packet is lost, every packet already received behind it waits in the buffer until the lost one is retransmitted — head-of-line blocking. One dropped packet stalls the whole stream.

This is why HTTP/2, despite multiplexing many requests over one connection, still suffers: all its streams share one TCP connection, so a single packet loss blocks all of them. HTTP/3 / QUIC fixes it by running independent streams over UDP and re-implementing reliability per-stream — a loss on stream B no longer blocks streams A and C.

Other latency gotchas

• Nagle's algorithm + delayed ACK can interact to add ~40ms to small writes; TCP_NODELAY disables Nagle for latency-sensitive, small-message protocols.
• Bufferbloat: oversized buffers hide loss and inflate latency under load.

Takeaways

• New connections pay a handshake RTT + slow-start ramp → pool/keep-alive connections.
• TCP's ordering causes HOL blocking: one lost packet stalls the stream (and all HTTP/2 streams on it).
• QUIC/HTTP-3 over UDP gives per-stream independence; TCP_NODELAY for small latency-sensitive messages.

---

Re-authored for this guide; HOL-blocking diagram hand-authored as SVG. Follows the TCP/QUIC specs and the HTTP/2-vs-3 literature. See also: Networking Fundamentals (TCP/UDP, L4/L7), the HTTP-versions advanced topic, CDN.

I just read a lesson on **TCP Deep — Handshake Cost, Congestion Control & Head-of-Line Blocking** (System Design) and want to truly understand it. Explain TCP Deep — Handshake Cost, Congestion Control & Head-of-Line Blocking from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **TCP Deep — Handshake Cost, Congestion Control & Head-of-Line Blocking** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **TCP Deep — Handshake Cost, Congestion Control & Head-of-Line Blocking** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **TCP Deep — Handshake Cost, Congestion Control & Head-of-Line Blocking** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.