The three-way handshake

You opened this page and a stranger on another continent agreed to talk to you. Before any HTTP request, before TLS, before DNS resolved — TCP did three things: said hello, agreed on starting sequence numbers, and confirmed the agreement. That is the handshake.

What TCP does in one sentence

TCP turns two strangers on the network into a reliable two-way conversation: every byte arrives in order, every byte is acknowledged, and missing bytes are resent. The handshake is how the conversation starts.

The IP layer moved packets across networks, but it did not care if they arrived, arrived in order, or arrived at all. TCP adds a contract: every byte is numbered, every byte is acknowledged, and if one is missing it is retransmitted. That contract is negotiated in the handshake. Before the handshake, both sides are strangers. After it, both sides carry state: buffers, windows, and the agreement to talk until one of them says goodbye.

Why care

Without TCP every web request would have to manage its own retries and ordering. TCP gives every higher protocol (HTTP, IMAP, SSH, anything that runs over it) a clean reliable pipe for free.

The phone-call metaphor

Imagine two people on a phone call. Before they say anything important they exchange “hello — can you hear me? — yes, I can hear you, can you hear me? — yes.” That short three-step ritual is the TCP handshake.

• SYN = “hello, here is my counter”
• SYN-ACK = “I hear you, here is my counter, and I confirm I heard your counter”
• ACK = “I confirm your counter, let’s begin”

Now both phones agree they are on the same line and can start the real conversation.

The handshake in plain dialogue

Bea dials Sven and says “Hello, my counter starts at 42,000,000.” Sven picks up: “Got it, your next byte should be 42,000,001; my counter starts at 99,000,000.” Bea: “Got it, your next byte should be 99,000,001, let’s go.” From this moment every word both of them say is numbered so neither can lose track.

Why three steps and not two

TCP is bidirectional and both sides must agree on each other’s starting sequence numbers. A two-step handshake (SYN then data) would leave the server’s sequence number unacknowledged. The third step (ACK) proves the client is alive and has read the server’s reply. It also bounds half-open connections: if a SYN arrives but no ACK follows, the server times out the half-open entry and frees memory.

One scenario end to end

You click a link in your browser. Underneath, the browser already finished IP routing (it knows the server’s address) and DNS (it resolved the name). Now it does the TCP handshake you just learned. Once finished, the browser layers TLS on top to seal the connection, and only then does the actual HTTP request travel.