TCP Working: 3-Way Handshake & Reliable Communication
TCP Explained Like You’re New To Networking
A beginner-friendly guide (with some casual language mistakes on purpose)
When you send a message over the internet, it doesn’t travel as one big chunk. It’s broken into lots of small packets that fly through different paths and can arrive:
Late
Out of order
Duplicated
Or not at all
If we just “throw packets into the network” with no rules, you’d get:
Half-loaded web pages
Corrupted files
Messages missing parts in the middle
This is where TCP (Transmission Control Protocol) comes in.
TCP is a set of rules that makes sure your data:
Arrives at the other side
Arrives in order
Arrives without corruption
Or you at least know if something went wrong
Let’s walk through:
What TCP is and why it’s needed
Problems TCP is designed to solve
What the TCP 3-Way Handshake is
Step-by-step of SYN → SYN-ACK → ACK
How data transfer works in TCP
How TCP ensures reliability, order, and correctness
How a TCP connection is closed
All in simple language, without too much packet-level overload.
What is TCP, and Why Is It Needed?
What happens without rules?
Imagine sending letters with a very broken postal system:
Letters sometimes get lost
Sometimes they arrive twice
Sometimes letter #3 arrives before letter #1
Sometimes they arrive damaged
If you had no agreement with the other person, you wouldn’t know:
Which letters are missing
Whether you should resend something
Whether the other person even got your message
This is what sending raw packets over the internet would look like without TCP.
TCP to the rescue
TCP (Transmission Control Protocol) is like a smart mail system on top of the basic delivery:
Cuts data into packets
Adds numbers to them so the order is known
Makes the receiver confirm what it got
Resends anything that seems lost
Make sure both sides agree to start and end the conversation
TCP is used by things like:
HTTP / HTTPS (websites)
SMTP (email)
FTP (file transfer)
Many backend services and APIs
In short, if you care about data being correct and ordered, you usually use TCP.
Problems TCP Is Designed To Solve
TCP mainly solves three big issues:
Reliability
Problem: Packets can be lost on the network.
TCP solution:
Every packet has a sequence number
The receiver sends ACKs (acknowledgements) back
If the sender doesn’t get an ACK in time → assumes the packet is lost → retransmits
Ordering
Problem: Packets can arrive out of order.
TCP solution:
Each packet has a sequence number
The receiver uses numbers to reorder packets back into the right order
Application (like your browser) only sees a clean, ordered stream of bytes
Data Integrity / Correctness
Problem: Packets can get corrupted in transit.
TCP solution:
Each packet contains a checksum
Receiver verifies checksum
If a mismatch → packet is considered bad → dropped → sender will resend
So TCP is like a careful, slightly paranoid friend that:
Checks everything
Confirms everything
Retries when something looks wrong
What Is the TCP 3-Way Handshake?
Before sending data, TCP needs both sides to agree to communicate. That’s the 3-Way Handshake.
It’s called that because it uses three messages:
SYN
SYN-ACK
ACK
Conversation Analogy
Imagine two people want to talk on the phone:
Person A: “Hey, can we talk?”
Person B: “Yes, we can talk. Can you hear me?”
Person A: “Yes, I can hear you. Let’s start.”
After this, both people know the connection is active and they can start sending real information.
In TCP terms:
Person A = Client
Person B = Server
Those three lines = SYN → SYN-ACK → ACK
Step-by-Step: SYN, SYN-ACK, and ACK
Let’s go through the handshake more slowly.
We’ll say:
- Client = the side that starts the connection (like your browser)
- Server = the side that accepts it (like a web server)
Step 1: Client → Server (SYN)
The client sends a SYN packet:
- “I want to start a TCP connection.”
- “Here is my initial sequence number (ISN) for data I’ll send.”
Client Server
| ---- SYN ----> |
Step 2: Server → Client (SYN-ACK)
The server receives the SYN
Server sends back a SYN-ACK packet:
It means two things at once:
- SYN:
“Okay, I also want to start a TCP connection. Here is my initial sequence number.”
- ACK:
“And by the way, I acknowledge that I got your SYN.”
So SYN-ACK = “Yes, let’s talk, and I heard you.”
Client Server
| ---- SYN ----> |
| <--- SYN-ACK --- |
Step 3: Client → Server (ACK)
Client receives the SYN-ACK
Client sends an ACK back:
“I confirm I got your SYN-ACK. Now we’re both ready.”
At this point:
Connection is established
Both sides know:
The other one exists
The other one is ready
The initial sequence numbers they will use
Now, real data (like HTTP requests) can start flowing.
Text Diagram: 3-Way Handshake
Client (C) on left, Server (S) on right:
C S
| ----------- SYN ------------> |
| "Can we talk? My seq = x" |
| |
| <-------- SYN-ACK ---------- |
| "Yes, seq = y, I got x" |
| |
| ----------- ACK ------------> |
| "I got y, go!" |
Connection established ✅
How Data Transfer Works in TCP
Once the handshake is done, data transfer begins.
TCP as a Byte Stream
TCP sees data as a stream of bytes, not “messages”.
It breaks your data into segments (packets) under the hood.
Each byte in the stream has a sequence number.
Example:
Client sends “HELLO WORLD.”
TCP might split it into two packets:
Packet 1: “HELLO ” (bytes 1000–1005)
Packet 2: “WORLD” (bytes 1006–1010)
Receiver doesn’t care about the split; TCP reassembles them and gives “HELLO WORLD” to the app.
Sequence Numbers and ACKs (High Level)
Sender labels each byte with a sequence number
The receiver sends back ACKs saying:
\> “I have correctly received everything up to byte #N. Please send the next ones.”
For example:
Sender sends bytes 1000–1499
The receiver gets them and sends them back:
\> “ACK 1500” (meaning: I got everything up to 1499, next expected is 1500)
This is called cumulative acknowledgment.
How TCP Ensures Reliability, Order, and Correctness
Reliability: Handling Packet Loss
Packets sometimes get lost. Here’s what TCP does:
Sender sends packets with sequence numbers
If the sender doesn’t receive an ACK for a packet within a timeout:
It assumes the packet was lost
It retransmits the missing packet
Sender: sends bytes 1000–1499
(lost on the network)
Sender waits... no ACK
Sender: "Hmm, no ACK..."
→ sends bytes 1000–1499 again
Receiver (this time gets it):
→ sends ACK 1500
The application usually never knows this happened. TCP hides all this retry logic.
Ordering: Out-of-Order Packets
Sometimes packets arrive in weird order:
Packet with bytes 1500–1999 arrives
The packet with bytes 1000–1499 is late
Receiver behavior:
It can buffer out-of-order packets
It only passes data to the application in order
It keeps sending ACKs for the highest continuous sequence it has
So if it got 1500–1999 but not 1000–1499 yet, it might still say:
“ACK 1000” (meaning: I’m still waiting, starting from 1000)
This encourages the sender to retransmit missing parts.
Correctness: Checksums
Each TCP segment has a checksum:
Sender calculates a checksum over the header + data
The receiver recalculatesthe checksum when the packet arrives
If they don’t match → packet corrupted → drop packet
Loss will be handled by the retransmission logic (no ACK received)
So TCP ensures data integrity: what you send is what they get.
How a TCP Connection Is Closed
Just like starting a conversation needs a handshake, ending it also has a process.
Basic Idea: Graceful Shutdown
One side says:
“I’m done sending data, but I can still receive.”
The other side says:
“Got it, I’ll also finish, and then we’re done.”
FIN and ACK
TCP uses:
FIN (Finish) – “I’m done sending.”
ACK – “I got your FI.N”
Typical simplified flow (client closes first):
- Client → Server: FIN
“I’m done sending data.”
- Server → Client: ACK
“Okay, I know you’re done. I can still send if needed.”
The server might still send the remaining data. When it’s done:
Server → Client: FIN
“I’m also done sending.”
- Client → Server: ACK
“Got it. We’re both done.”
After this final ACK, the connection is closed.
Text Diagram: TCP Close
Client Server
| ---- FIN ------------------> |
| "I'm done sending" |
| <--- ACK ------------------- |
| "Got it" |
| |
| <--- FIN ------------------- |
| "I'm also done sending" |
| ---- ACK ------------------> |
| "Got it, bye" |
Connection closed ✅
There are more details (like TIME_WAIT state), but at a beginner level, this flow is enough.
TCP Connection Lifecycle Summary
You can think of a TCP connection as 3 big phases:
- Establish – 3-Way Handshake
- SYN → SYN-ACK → ACK
- Transfer – Data exchange
Sequence numbers
ACKs
Retransmissions
Reordering
- Close – Graceful termination
- FIN → ACK → FIN → ACK
Diagram (high level):
[Establish]
SYN → SYN-ACK → ACK
[Transfer]
DATA ↔ DATA
(SEQ + ACK, retransmissions, ordering)
[Close]
FIN → ACK → FIN → ACK
Why TCP Matters for Backend and System Design
As a software engineer, even if you don’t manually write TCP code, it affects you everywhere:
HTTP/HTTPS runs on top of TCP
API latency includes:
TCP handshake time
Possible retransmissions
Throughput & performance depend on:
How TCP handles congestion and windows
Connection limits:
Each TCP connection uses resources
Too many connections = resource pressure on servers
TCP Explained Like You’re New To Networking
When two computers talk over the internet, they send data in packets. But what happens if:
Are some packets lost?
Some arrive twice?
Some arrive in the wrong order?
Or the receiver gets overwhelmed?
If there are no rules, communication becomes messy and unreliable.
This is where TCP (Transmission Control Protocol) comes in. It’s one of the main protocols of the internet, and its job is to make communication between two machines reliable, ordered, and correct.
Happy Learning! 🚀
Have questions about how browsers work? Drop them in the comments!
