The Invisible Handshake: How TCP Ensures Reliable Communication
I am a developer from India.
1. The Chaos Without Rules: Why Do We Need TCP?
Imagine you are sending a 10-page letter to a friend, but you tear the pages out and mail them individually in separate envelopes.
Envelope 1 arrives on Monday.
Envelope 2 gets lost in the mail.
Envelope 3 arrives on Tuesday.
Envelope 4 arrives before Envelope 1 because it took a faster route.
When your friend tries to read the letter, they have pages 1, 3, and 4, but page 2 is missing, and the order is wrong. They have no idea if page 4 is actually the end or if there are more pages coming.
This is what happens when data is sent over the internet without rules (like UDP). Packets can get lost, duplicated, or arrive out of order. For a video stream, this might just mean a pixelated frame. But for loading a webpage, downloading a file, or sending an email, this chaos is unacceptable. You need every byte, in the exact right order.
TCP (Transmission Control Protocol). TCP is the protocol that acts as the "registered mail" service of the Internet. It ensures that:
Reliability: Every piece of data arrives.
Order: Data is reassembled in the correct sequence.
Correctness: Data is not corrupted during transit.
2. The TCP 3-Way Handshake: Establishing Trust
Before any data can be exchanged, the Client (your browser) and the Server (the website) must agree to talk. They need to synchronize their "sequence numbers" so they can track which data has been sent and received. This process is called the 3-Way Handshake.
The Analogy: The Phone Call
Think of the handshake like starting a phone call where the line is noisy:
You: "Can you hear me?" (SYN)
Friend: "I hear you. Can you hear me?" (SYN-ACK)
You: "I hear you." (ACK)
Now, the connection is established, and you can talk.
Step-by-Step Technical Breakdown
Step 1: SYN (Synchronize)
Who: Client → Server
What Happens: The client wants to initiate a connection. It sends a segment with the SYN flag set to 1.
Key Detail: The client picks a random starting Sequence Number (SEQ = x). This number tells the server, "My first byte of data will be labeled x."
State: The client enters
SYN_SENTstate.
Step 2: SYN-ACK (Synchronize-Acknowledge)
Who: Server → Client
What Happens: The server receives the SYN. It acknowledges the client’s request and sends its own synchronization request.
Key Details:
It sets the ACK flag to 1 and the SYN flag to 1.
It sets the Acknowledgment Number (ACK = x + 1). This tells the client, "I received your sequence x, and I’m ready for x+1 next."
The server picks its own random Sequence Number (SEQ = y).
State: The server enters
SYN_RECEIVEDstate.
Step 3: ACK (Acknowledge)
Who: Client → Server
What Happens: The client receives the SYN-ACK. It acknowledges the server’s sequence number.
Key Details:
It sets the ACK flag to 1.
It sets the Acknowledgment Number (ACK = y + 1). This tells the server, "I received your sequence y, and I’m ready for y+1 next."
The client’s Sequence Number is now SEQ = x + 1.
State: Both sides enter
ESTABLISHEDstate. Data transfer can now begin.
Visual Diagram
3. How Data Transfer Works: Sequence Numbers & ACKs
Once the handshake is done, TCP treats data like a numbered book. Every byte of data sent is assigned a Sequence Number.
The Mechanism
Segmentation: If you send a 1MB file, TCP breaks it into smaller chunks called segments (usually around 1460 bytes of data per segment, depending on the Maximum Segment Size).
Numbering: Each segment gets a sequence number.
Segment 1: Seq 1–1460
Segment 2: Seq 1461–2920
Segment 3: Seq 2921–4380
Acknowledgment (ACK): The receiver doesn’t ACK every single packet immediately. Instead, it uses Cumulative Acknowledgment.
If the receiver gets Segment 1 and 2, it sends back an ACK = 2921.
This means: "I have received everything up to byte 2920. I am expecting byte 2921 next."
Example Scenario
Client sends: "Hello" (5 bytes). Seq = 100.
Server receives: "Hello".
Server replies: ACK = 105. (100 + 5 bytes = 105).
Meaning: "I got bytes 100-104. Send me byte 105 next."
4. Reliability, Order, and Correctness
How does TCP guarantee that the data is perfect? It uses three main mechanisms.
A. Handling Packet Loss (Retransmission)
What if Segment 2 gets lost on the internet?
The client sends Segment 1, 2, and 3.
The server receives 1 and 3, but 2 is missing.
The server cannot ACK 3 yet because it’s waiting for 2. It keeps sending ACK = Start_of_Segment_2 (duplicate ACKs).
The client notices it hasn’t received an ACK for Segment 2 after a certain time (Timeout) or sees multiple duplicate ACKs.
The client retransmits Segment 2.
Once the server gets Segment 2, it sends a new ACK for the next expected byte.
Key Concept: Sliding Window. TCP doesn’t wait for an ACK for every single packet before sending the next one. It sends a "window" of packets (e.g., 10 packets) at once. As ACKs come back, the window "slides" forward, allowing more data to be sent. This maximizes speed while maintaining reliability.
B. Ensuring Order
Because packets can take different routes, Segment 3 might arrive before Segment 2.
TCP places incoming segments into a buffer based on their Sequence Numbers.
It holds Segment 3 in the buffer until Segment 2 arrives.
Only when the sequence is complete does it pass the data up to the application (e.g., your web browser).
C. Ensuring Correctness (Checksums)
Every TCP segment includes a Checksum.
The sender calculates a mathematical value based on the data.
The receiver recalculates the checksum.
If the values don’t match, the data was corrupted (bit flip). The receiver discards the packet and does not send an ACK. The sender eventually times out and retransmits.
5. Closing the Connection: The 4-Way Wavehand
Unlike the handshake, closing a TCP connection usually takes 4 steps. This is because TCP is full-duplex (data can flow both ways simultaneously). Each direction must be closed independently.
The Analogy: Hanging Up
You: "I’m done talking." (FIN)
Friend: "Okay, I heard you." (ACK)
(Friend finishes sending their last thoughts)
Friend: "I’m also done talking." (FIN)
You: "Okay, goodbye." (ACK)
Step-by-Step Termination
FIN (Client → Server): The client sends a FIN flag, indicating it has no more data to send. It enters
FIN_WAIT_1.ACK (Server → Client): The server acknowledges the FIN. It enters
CLOSE_WAIT. The connection is now half-closed. The server can still send data to the client.FIN (Server → Client): When the server is also done sending data, it sends its own FIN. It enters
LAST_ACK.ACK (Client → Server): The client acknowledges the server’s FIN. It enters
TIME_WAIT(a short timer to ensure the final ACK arrives). The server entersCLOSED. After the timer expires, the client also closes.
Visual Diagram
![]()
6. Summary
TCP vs. UDP: TCP is reliable/ordered (email, web); UDP is fast/unreliable (video calls, gaming).
Handshake: SYN → SYN-ACK → ACK. Establishes sequence numbers.
Data Transfer uses sequence numbers for ordering and ACKs for confirmation.
Reliability: Achieved via Retransmission (on loss), Buffering (for order), and Checksums (for correctness).
Termination: FIN → ACK → FIN → ACK. Closes both directions of communication.
