Networking & Protocols
TCP handshake: multiple-choice review
Crux Multiple-choice synthesis across the TCP-handshake unit — RTT cost, ISN randomisation, SYN cookies, congestion control, Nagle stalls, and TIME-WAIT exhaustion.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a call you make in a real incident — not a flag to name, but a tradeoff to weigh while latency or memory is on fire.
Goal
Confirm you can connect the handshake’s RTT cost, ISN security, flood defence, congestion control, and the canonical production pathologies — the synthesis the individual lessons built toward.
Quiz
Completed
A REST client opens a fresh TCP connection per request to an origin 140 ms RTT away, then layers TLS 1.3. Why does each call feel slow even though the payload is tiny, and what is the structural fix?
Heads-up A tiny payload is not a CPU problem. The latency is the chain of round-trips (TCP handshake + TLS) paid per connection, which is exactly what keep-alive amortises.
Heads-up A tiny response fits inside the default IW=10 (~14.6 KB) in the first RTT; slow start is not the bottleneck. The cost is the per-connection handshake round-trips.
Heads-up Nagle stalls pipelined small writes on one connection, not the cold-start round-trips of opening a brand-new connection per request. The fix here is reuse, not TCP_NODELAY.
Quiz
Completed
Why does RFC 6528 compute the Initial Sequence Number as a time-based counter plus a keyed hash of the 4-tuple, rather than starting from zero?
Heads-up ISN randomisation is not encryption — TCP carries cleartext. It only stops sequence-number prediction; confidentiality is TLS's job, a layer above.
Heads-up ISN selection has nothing to do with core steering (that is RSS/RPS on the NIC). RFC 6528 is purely an anti-injection defence.
Heads-up Every connection still needs all three steps. The ACK proves liveness regardless of how the ISN is chosen; randomisation changes the value, not the step count.
Quiz
Completed
During a SYN flood your public listener stays up with tcp_syncookies=1, but legitimate clients on a 200 ms transcontinental path report throughput stuck near a trickle. Why?
Heads-up Cookies trade CPU for memory — they allocate no request_sock at all. The throughput hit comes from losing Window Scaling/SACK/Timestamps in the cookie, not from memory pressure.
Heads-up A SYN flood is tiny packets that exhaust the half-open queue, not link bandwidth. The per-connection throughput cap comes from the dropped scaling option on cookie-validated handshakes.
Heads-up Cookies do not change the congestion-control algorithm. They drop TCP options carried in the SYN; the 64 KiB window cap is the throughput limiter.
Quiz
Completed
A 4K-video service over cellular (150 ms RTT, ~1% random loss) sees CUBIC throughput collapse to a fraction of link capacity. Switching to BBR restores near-line-rate. What is the underlying reason?
Heads-up Both can start at IW=10. The durable difference is BBR's loss-agnostic bandwidth/RTT model versus CUBIC's loss-triggered window cuts — not a one-time initial-window edge.
Heads-up BBR still retransmits lost data — reliability is unchanged. It simply does not interpret loss as a congestion signal, so it does not collapse its rate on random drops.
Heads-up Congestion control does not change MSS, and jumbo frames do not survive cellular paths. The win is purely the loss-versus-congestion modelling difference.
Quiz
Completed
A Redis client on the same datacenter host shows a steady ~40–200 ms p99 on small pipelined commands, with no loss and no CPU pressure. Root cause?
Heads-up An established connection is past slow start, and tiny commands do not stress cwnd. The stall is the Nagle plus delayed-ACK deadlock, cured by TCP_NODELAY.
Heads-up TIME-WAIT affects opening new connections (port reuse), not the latency of commands on an already-established socket. The 40 ms quantum points squarely at delayed ACK.
Heads-up ISN choice has no bearing on per-command latency. The 40 ms figure is the delayed-ACK timer interacting with Nagle.
Quiz
Completed
A load balancer returns EADDRNOTAVAIL on outbound connect() to one backend; ss shows ~30k TIME-WAIT sockets to that origin. A teammate proposes lowering MSL to drain TIME-WAIT faster. What is the correct read?
Heads-up TIME-WAIT exists to absorb delayed retransmissions on the same 4-tuple; shortening it invites stale-segment corruption. The safe levers are tcp_tw_reuse plus connection pooling.
Heads-up tcp_tw_recycle was removed in Linux 4.12 because it dropped legitimate SYNs from clients behind NAT. Never enable it; use tcp_tw_reuse instead.
Heads-up SYN cookies defend the inbound half-open SYN queue; they do nothing for outbound ephemeral-port exhaustion in TIME-WAIT. Wrong layer entirely.
Recap
The unit’s through-line is one decision chain: the handshake costs a round-trip you amortise with connection reuse, ISN randomisation secures it, SYN cookies defend it under flood (at the cost of dropped options), congestion control decides how fast it fills the pipe (CUBIC reacts to loss, BBR models bandwidth and RTT), and the canonical production failures — Nagle plus delayed-ACK stalls, CLOSE-WAIT leaks, TIME-WAIT exhaustion — each have one correct lever and several plausible wrong ones. Knowing which lever, and why the others fail, is the synthesis.