TCP Internals; Handshake, Delivery, and Goodbye
TCP is the "Safe Mode", But how does it actually guarantee safety?

Introduction
In the last blog, we learned that TCP is the "Safe Mode" of the internet (like driving a Thar carefully). But how does it actually guarantee safety?
If I send a meme to my friend, how does TCP make sure the top half doesn't arrive after the bottom half?
The answer lies in The Handshake and The Sequence.
1. The 3-Way Handshake
TCP is extremely polite. It never sends data without asking first. It uses a 3-step process called the 3-Way Handshake.
Imagine calling your friend:
Step 1: SYN (The Dial)
You (Client): "Hello? Can you hear me?"
Technical: You send a packet with the SYN flag (Synchronize, it’s just jargon) and a random number (e.g., 100). This is your ID.
Step 2: SYN-ACK (The Answer)
Friend (Server): "Yes, I hear you (ACK 101). Can you hear me? (SYN 5000)"
Technical: The server ACKs your number (100 + 1) and sends its own SYN number (5000). Now both have IDs.
Step 3: ACK (The Confirmation)
You (Client): "Yes, I hear you perfectly (ACK 5001). Let's talk."
Technical: You ACK the server's number (5000 + 1). The connection is ESTABLISHED.

2. Data Transfer
Now the connection is open. We need to send the data.
But the internet is chaotic. Packets can arrive late, out of order, or duplicate.
TCP solves this using Sequence Numbers.
Think of it like moving houses. You don't just throw boxes into a truck. You label them: "Box 1 of 10", "Box 2 of 10".
The Sender: Sends "Packet #1 (Bytes 0-100)".
The Receiver: Gets it and sends back "ACK 101".
- Translation: "I got everything up to 100. Send me byte 101 next."
The Sender: Sends "Packet #2 (Bytes 101-200)".
Ordering: If "Packet #3" arrives before "Packet #2", TCP holds it in a waiting room (Buffer). It waits for #2 to arrive, puts them in the right order (1 → 2 → 3), and then gives it to the application.

3. Handling Loss
What if a packet disappears?
Sender: "I sent Packet #2... waiting for confirmation..."
Receiver: (Silence)
Sender: "Okay, it's been 200ms. No ACK. It must be lost."
Action: The sender Retransmits Packet #2.
This is why TCP is "Reliable". It doesn't give up until the other side confirms receipt.
4. Closing the Connection
UDP just stops talking. But TCP is polite—it says goodbye properly.
This is a 4-Way Termination.
You: "I'm done talking." (FIN)
Server: "Okay, I heard you." (ACK)
- (The Server might still have some final data to send to you. You wait.)
Server: "Okay, I'm done too. Bye." (FIN)
You: "Bye." (ACK)
The connection is now closed.

Conclusion: The Unsung Hero
TCP is heavy. It has handshakes, acknowledgments, timers, and sequence numbers.
But this "heaviness" is exactly why you can load a webpage without missing words, or download a zip file without it being corrupted.
It works hard in the background so you don't have to.
We have built the road (Cables), found the address (DNS), and established a secure connection (TCP). The journey is complete. Now, we are standing at the server's front door. It's time to actually ask for the website.
In the final part of this series, we will stop using the browser and learn how to talk to the server manually using the command line tool cURL.





