# TCP Working: 3-Way Handshake & Reliable Communication

## What if data was sent without any rules?

Imagine you want to send an important message to your friend.  
You shout it from one building to another and hope they hear it.

What could go wrong?

* Message may not reach
    
* Parts may be missed
    
* Words may arrive in wrong order
    
* You don’t even know if the other person heard it
    

That’s exactly what would happen on the internet **without rules**.

The internet is not a single wire.  
Data travels through routers, cables, wireless signals, and multiple networks.  
Loss, delay, and disorder are **normal**, not exceptions.

So the big question becomes:

> How do two computers talk **reliably** on such an unreliable network?

That’s where **TCP** comes in.

---

## TCP: the protocol that brings order to chaos

**TCP (Transmission Control Protocol)** exists for one simple reason:

> “Make sure data reaches correctly, completely, and in the right order.”

TCP does not care about speed first.  
It cares about **correctness**.

Whenever you:

* Load a website
    
* Login to an app
    
* Download a file
    
* Make a payment
    

TCP is quietly working in the background, making sure nothing breaks.

---

## Before sending data, TCP wants a proper conversation

TCP is polite.

It does **not** start sending data immediately.  
First, it wants to make sure:

* The other side is alive
    
* The other side is ready
    
* Both sides agree to talk
    

This preparation phase is called the **3-Way Handshake**.

---

## The 3-Way Handshake (explained like a real conversation)

Think of TCP handshake like starting a phone call ☎️.

### Step 1: “Can you hear me?” (SYN)

The client starts by saying:

> “Hey, I want to talk to you. Are you available?”

This message is called **SYN** (Synchronize).

At this point:

* No data is sent
    
* Only intention is expressed
    

---

### Step 2: “Yes, I can hear you” (SYN + ACK)

The server replies:

> “Yes, I hear you. I’m ready too.”

This reply contains:

* **SYN** → “I also want to talk”
    
* **ACK** → “I heard your request”
    

Now both sides know:

* The connection path works
    
* Messages can travel both ways
    

---

### Step 3: “Great, let’s start” (ACK)

Finally, the client replies:

> “Perfect. Let’s begin.”

This **ACK** confirms everything.

Now the connection is **established**.

Only after this step does **actual data transfer begin**.

---

## Visual flow of the 3-Way Handshake

![Generated image](https://videos.openai.com/az/vg-assets/task_01kfzv737rf0ntqbxb95vrfp0y%2F1769521552_img_1.webp?se=2026-01-31T00%3A00%3A00Z&sp=r&sv=2024-08-04&sr=b&skoid=3d249c53-07fa-4ba4-9b65-0bf8eb4ea46a&sktid=a48cca56-e6da-484e-a814-9c849652bcb3&skt=2026-01-27T06%3A33%3A59Z&ske=2026-02-03T06%3A38%3A59Z&sks=b&skv=2024-08-04&sig=h6QQXJV8IFeJv0xFpErTTAruUCBhXJRQZWeMVwr0%2BF8%3D&ac=oaivgprodscus2 align="left")

```coffeescript
Client → SYN → Server
Client ← SYN + ACK ← Server
Client → ACK → Server
```

Once this finishes:  
👉 TCP connection is open  
👉 Data can flow safely

---

## Why does TCP use sequence numbers?

Now that the connection is open, data starts flowing.

But TCP doesn’t send data blindly.

Every chunk of data is tagged with a **sequence number**.

Think of sequence numbers like **page numbers in a book** 📖.

If pages arrive:

* Out of order → TCP rearranges them
    
* Missing → TCP asks again
    

This ensures:

* Data integrity
    
* Correct order
    
* No confusion
    

---

## What are acknowledgements (ACK)?

After receiving data, the receiver responds:

> “I got everything up to this point.”

This response is called an **ACK (Acknowledgement)**.

ACKs help TCP:

* Confirm delivery
    
* Detect loss
    
* Decide what to resend
    

TCP never assumes.  
It always waits for confirmation.

---

## What happens if data is lost?

Packet loss is normal on the internet.

TCP handles this calmly.

If:

* ACK doesn’t arrive
    
* Or data arrives incomplete
    

TCP says:

> “Okay, let me resend that part.”

This process is called **retransmission**.

To the application (browser, API, user):

* Everything still looks smooth
    
* Errors are hidden
    

That’s why TCP feels reliable.

---

## Reliable communication is TCP’s superpower

Because of:

* Handshake
    
* Sequence numbers
    
* Acknowledgements
    
* Retransmissions
    

TCP guarantees:

* No silent data loss
    
* No broken messages
    
* No corrupted transfers
    

This reliability is why TCP is used for:

* HTTP
    
* HTTPS
    
* APIs
    
* Emails
    
* File transfers
    

---

## Ending the conversation properly (FIN & ACK)

Just like TCP starts politely, it also **ends politely**.

When communication is done, one side says:

> “I’m done sending data.”

This message is called **FIN**.

The other side replies:

> “Okay, I acknowledge that.”

That’s **ACK**.

Both sides agree to close the connection cleanly.

No sudden hang-ups.  
No confusion.

---

## Why TCP may feel slower sometimes

TCP’s reliability comes at a cost:

* Extra checks
    
* Confirmations
    
* Retransmissions
    

But for most applications:

> **Correct data is more important than fast data.**

That tradeoff is intentional.

---

## Final thoughts

TCP is not just a protocol.  
It is a **discipline**.

It teaches the internet how to:

* Communicate clearly
    
* Recover from mistakes
    
* Maintain trust between machines
    

The 3-Way Handshake is TCP’s way of saying:

> “Let’s agree before we talk.”

Once you understand this, networking stops feeling mysterious and starts feeling logical.