Networking & Protocols
TCP handshake: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick.
Reconstruct the unit’s core mechanisms — why three steps, why random ISNs, how SYN cookies and TIME-WAIT behave at scale, when BBR beats CUBIC, and how TCP relates to QUIC — without looking back at the lessons.
- 01Why does TCP need three messages and not two, and what does each step accomplish?
- 02Why are Initial Sequence Numbers randomised per connection, and how does RFC 6528 do it?
- 03What is TIME-WAIT, why does it exist, and what are the production fixes when it causes EADDRNOTAVAIL?
- 04Explain how a SYN cookie works, and what legitimate connections lose during a flood.
- 05Why does BBR sustain throughput on a path with ~1% random loss where CUBIC collapses?
- 06What is TCP's relationship to QUIC, and why did QUIC reinvent TCP's mechanisms over UDP instead of extending TCP?
If you could reconstruct each answer from memory, you hold the unit’s spine: three steps because both directions must acknowledge an ISN; randomised ISNs to stop injection; TIME-WAIT to absorb stragglers (fixed at scale with pooling and tcp_tw_reuse, never tw_recycle or a shorter MSL); SYN cookies to survive floods at the cost of dropped options; BBR over CUBIC where loss is random not congestive; and QUIC as the same ideas moved above UDP to escape protocol ossification.