Naval Kishor Upadhyay

Posted on Sep 1

# The TCP 3-Way Handshake: How Connections Begin Their Life

Before your browser loads a webpage or your app connects to a server, something fundamental happens first: the devices must agree to talk.

That agreement is called the TCP 3-Way Handshake — a short but powerful exchange that ensures both sides are ready for reliable communication.

It happens so fast you don’t notice it, yet every time you open Google, send an email, or log into your bank, the handshake is there. Let’s unpack it fully.

Why a Handshake?

TCP (Transmission Control Protocol) is connection-oriented. Unlike UDP, which just fires data into the network, TCP sets up a reliable channel first.

The handshake ensures:

Reachability → Both client and server are alive
Synchronization → Each side chooses a starting sequence number (so every byte of data can be tracked)
Agreement → Both sides confirm they are ready before exchanging real data

Think of it as two people shaking hands before a conversation — it’s the ritual that confirms both are present and paying attention.

Step-by-Step: The 3-Way Handshake

Imagine your laptop (the client) connecting to example.com (the server) over TCP port 443 (HTTPS).

Step 1: SYN — Client to Server

The client sends a packet with the SYN flag set.
It also generates a random Initial Sequence Number (ISN), say 1000.
This ISN tells the server: “When I start sending data, number the bytes starting from 1000.”

📦 Example packet:

Flags: SYN
Seq: 1000
Ack: 0 (not used yet)

Step 2: SYN-ACK — Server to Client

The server receives the SYN and replies with a SYN-ACK.
It chooses its own ISN, say 5000.
It sets the ACK field to 1001 (the client’s ISN + 1).
This means: “I acknowledge your sequence number, and here’s mine.”

📦 Example packet:

Flags: SYN, ACK
Seq: 5000
Ack: 1001

Step 3: ACK — Client to Server

The client receives the SYN-ACK and sends a final ACK back.
It sets the ACK field to 5001 (server’s ISN + 1).
Now both sides know each other’s sequence numbers and are in sync.

📦 Example packet:

Flags: ACK
Seq: 1001
Ack: 5001

✅ Connection established — the client can now send an HTTP request, and the server can respond with the webpage.

Visualizing the Handshake

Client → Server: SYN, Seq = 1000
Server → Client: SYN-ACK, Seq = 5000, Ack = 1001
Client → Server: ACK, Seq = 1001, Ack = 5001

At the end of this process:

Client knows server’s ISN (5000)
Server knows client’s ISN (1000)
Both are ready to exchange reliable, ordered data

Why Three Steps (and Not Two)?

A 2-step handshake (SYN, then ACK) might seem simpler. But the third step is critical:

It prevents half-open connections (where one side thinks a connection exists but the other doesn’t)
It ensures bidirectional synchronization — both sides explicitly agree on sequence numbers
It makes the protocol robust in unreliable networks with packet loss or duplicates

Without the third step, old duplicate SYN packets could cause “phantom” connections.

Example: Loading a Webpage

Let’s tie it together with a practical example:

You type google.com in your browser.
Browser → Client TCP stack sends a SYN to Google’s server IP on port 443.
Google’s server replies with SYN-ACK.
Browser responds with ACK.
Only now does your browser send the HTTP GET request:

GET / HTTP/1.1
Host: google.com

The server responds with the webpage data, segment by segment, each acknowledged by TCP.

Without the handshake, the browser would never know if the server was listening — your request might disappear into the void.

Real-World Analogy

Think of making a phone call:

You dial (SYN) → “Hello, are you there?”
They pick up (SYN-ACK) → “Yes, I hear you. Can you hear me?”
You confirm (ACK) → “Yes, I hear you too.”

Now both sides are synchronized and can start the real conversation.

What Happens if the Handshake Fails?

Sometimes, the 3-Way Handshake doesn’t complete properly. Here’s what can happen:

No SYN-ACK Response

The client sends SYN, but the server doesn’t reply.
The client waits, then retransmits SYN after a timeout.
If still no reply, the connection attempt fails.

Half-Open Connections

The client thinks a connection exists (after sending SYN), but the server never confirmed.
Resources remain stuck until they time out.

SYN Flood Attack (DoS)

An attacker sends thousands of SYNs but never completes the handshake.
The server holds resources for each half-open connection.
This can overwhelm the server, preventing real users from connecting.

TCP includes safeguards like timeouts and SYN cookies to defend against these issues.

Beyond the Handshake: What Happens Next

After the 3-Way Handshake, TCP manages:

Reliable delivery (retransmitting lost packets)
Ordering (reassembling packets correctly)
Flow control (ensuring neither side is overwhelmed)
Connection teardown (a 4-step process with FIN and ACK)

But it all starts with the handshake — the foundation for everything else.

Final Thoughts

The TCP 3-Way Handshake may seem like a small detail, but it’s the reason the internet feels reliable.

Without it, packets could be lost, duplicated, or misaligned.
With it, every connection starts on a clear, synchronized foundation.

So the next time you click a link, remember: before a single byte of the webpage arrives, your device and the server have already exchanged a digital handshake to say:

“I’m ready, are you ready? Great, let’s begin.”

DEV Community