# TCP Internals; Handshake, Delivery, and Goodbye

**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**.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769855837870/12838390-6769-42e1-abc7-451910866063.png align="center")

### 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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769856357616/44cb1b93-7f4c-4867-affa-35aae0391466.png align="center")

### 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**.

1. **You:** "I'm done talking." (**FIN**)
    
2. **Server:** "Okay, I heard you." (**ACK**)
    
    * *(The Server might still have some final data to send to you. You wait.)*
        
3. **Server:** "Okay, I'm done too. Bye." (**FIN**)
    
4. **You:** "Bye." (**ACK**)
    

The connection is now closed.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769857118297/a143a735-f5d4-4778-bf18-c3601ad908fe.png align="center")

### 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**.