TCP — 3-Way Handshake

NetworkingMidnetworking

The Question

Explain the TCP 3-way handshake.

What a Strong Answer Covers

• SYN → SYN-ACK → ACK
• "sequence numbers
• SACK or retransmission

Senior-Level Answer

The TCP three-way handshake establishes a reliable, ordered connection between a client and server before any application data is exchanged. It serves two purposes: confirming bidirectional connectivity and synchronizing the initial sequence numbers (ISNs) that TCP uses to order and acknowledge segments.

The three steps are: First, the client sends a SYN (synchronize) segment to the server with a randomly chosen initial sequence number — call it x. This signals the client's intent to open a connection and establishes the client's starting sequence number. Second, the server responds with a SYN-ACK segment: it acknowledges the client's SYN by sending ACK number x+1 (confirming it received x and expects x+1 next), and simultaneously sends its own SYN with its own randomly chosen sequence number y. Third, the client sends an ACK to the server with acknowledgment number y+1, confirming receipt of the server's SYN. After this, both sides have agreed on sequence numbers and the connection is established.

Why random initial sequence numbers? If ISNs were predictable or always started at 0, an attacker could forge packets in an existing connection by guessing the sequence number — a TCP sequence prediction attack. Randomization prevents this.

After the handshake, both sides maintain state: the client moves from SYN_SENT to ESTABLISHED, the server moves from SYN_RECEIVED to ESTABLISHED. Connection teardown is a separate four-way process using FIN and ACK segments, because each direction of the connection closes independently.

Performance implications: the handshake requires 1.5 round trips before any application data can be sent, adding latency. This is why HTTP/2 multiplexes streams over one TCP connection (avoiding repeated handshakes), and QUIC (used by HTTP/3) integrates the transport and cryptographic handshakes to achieve 0-RTT connection resumption for known servers.

SYN flood attacks exploit the handshake: an attacker sends many SYN segments without completing the handshake, exhausting the server's half-open connection table. SYN cookies are the primary mitigation — the server encodes connection state into the ISN rather than storing it, deferring allocation until the ACK arrives.

What Separates a 2/3 from a 3/3

Common Mistakes

• Describing the steps correctly but not explaining why they're needed — the ISN synchronization purpose is often skipped.
• Saying the connection is established after the SYN-ACK — the client's final ACK is required before either side is fully in ESTABLISHED state.
• Confusing the handshake with TLS negotiation — TCP handshake is transport-layer; TLS is a separate step on top.
• Not knowing about SYN flood attacks — this is a common follow-up that reveals whether the candidate understands practical implications.

Follow-Up Questions

• Why are initial sequence numbers random rather than always starting at 0? — Predictable ISNs enable TCP sequence prediction attacks where an attacker forges packets in an existing connection.
• What is a SYN flood attack and how do SYN cookies mitigate it? — SYN flood exhausts half-open connection state. SYN cookies encode state in the ISN, deferring allocation until the ACK proves the client is real.
• How does QUIC improve on TCP's connection establishment latency? — QUIC combines transport and TLS handshake, achieves 1-RTT on new connections and 0-RTT on resumption for known servers.
• Why does TCP use a four-way teardown instead of a three-way teardown? — Each direction of the connection closes independently — FIN from one side doesn't stop the other from sending. Two FIN+ACK pairs are needed.

Related Questions

• TLS — Certificate, DH, AES
• TCP vs UDP
• HTTP vs HTTPS
• WebSockets
• REST vs gRPC