Back to Blog
4 min readBy Tanish Bhandari

TCP Working: 3-Way Handshake & Reliable Communication


TCP Working: 3-Way Handshake & Reliable Communication

A few months ago, I was debugging why a connection between two services kept failing silently. Packets were being sent, but nothing was getting through. Turns out, the handshake was never completing. That's when I realized — I'd been using TCP for years without truly understanding what happens before any data actually moves.

Let me walk you through what I learned.

The Problem TCP Solves

Imagine sending a letter to someone you've never met. You don't know if the address is valid, if they're home, or if they even want to hear from you. You just drop it in a mailbox and hope for the best.

That's what the internet looks like without TCP. Data gets sent into the void. Some of it arrives. Some gets lost. Some shows up twice. Some arrives in the wrong order. Chaos.

TCP was designed to fix this mess. But it doesn't just start sending data and pray. It establishes a connection first. Both sides agree to communicate before a single byte of actual data moves. That agreement is called the 3-way handshake.

The Handshake: A Conversation

I like to think of it as two strangers meeting at a coffee shop.

You: "Hey, can we talk?" (SYN)
Them: "Sure, I'm listening. Are you still there?" (SYN-ACK)
You: "Yep, I'm here. Let's start." (ACK)

Three messages. That's it. After this, both sides know the other is present, listening, and ready to communicate.

Here's what actually happens at the network level:

StepWho SendsFlagWhat It Means
1ClientSYN"I want to start a connection"
2ServerSYN-ACK"Got it. I'm ready too. Are you still there?"
3ClientACK"Confirmed. Connection established."

The SYN flag stands for "synchronize." It's the client saying, "Let's sync up and agree on some starting numbers." The server responds with SYN-ACK — acknowledging the request and sending its own sync request. Finally, the client sends ACK to confirm everything's aligned.

Now data can flow.

Why This Matters

Without the handshake, you'd have no idea if the server even received your request. You'd send data into the dark. Maybe it arrives. Maybe it doesn't. You'd never know.

The handshake guarantees both parties are online, listening, and synchronized. It's the foundation of reliable communication.

How TCP Keeps Data Safe

The handshake is just the beginning. Once connected, TCP doesn't just throw data and hope. It tracks everything obsessively.

Sequence Numbers — Every packet gets a number. If packet 5 arrives before packet 3, TCP holds onto it and waits. It reassembles everything in the correct order before handing it to the application.

Acknowledgements (ACKs) — After receiving a packet, the receiver sends back an ACK saying "got it, send the next one." If the sender doesn't hear back within a timeout, it assumes the packet was lost and resends it.

Checksums — Every packet includes a checksum — a mathematical fingerprint of the data. If the received checksum doesn't match, the packet is corrupted and gets discarded. TCP asks for it again.

This is why TCP is called "reliable." It doesn't just send data. It confirms delivery, verifies integrity, and reorders everything automatically.

Closing the Connection

Just like opening a connection requires a handshake, closing one does too. TCP doesn't just hang up abruptly. It uses a 4-way handshake to ensure both sides are done:

Client: "I'm finished sending." (FIN)
Server: "Got it." (ACK)
Server: "I'm finished too." (FIN)
Client: "Understood. Goodbye." (ACK)

Both sides explicitly confirm they have nothing left to send. No data gets cut off mid-transmission.

The Trade-off

All this reliability comes at a cost — speed. The handshake adds latency before any data moves. Acknowledgements create back-and-forth overhead. Retransmissions slow things down further.

That's why protocols like UDP exist for cases where speed matters more than perfection. But for anything where data integrity is critical — banking, file transfers, web pages — TCP's overhead is worth it.

What I Learned

That debugging session taught me something important. TCP isn't magic. It's a carefully designed system of confirmations, retries, and ordering. When it works, you don't notice it. When it breaks, understanding the handshake helps you figure out exactly where things went wrong.

Every time you load a webpage, send an email, or download a file, this dance happens behind the scenes. Now you know the steps.



Written by Tanish Bhandari