# TCP Working: 3-Way Handshake & Reliable Communication

Before we talk about **TCP**, let’s imagine something.

## What If Data Was Sent Without Any Rules?

Suppose you send a long message to a friend:

> “HELLO HOW ARE YOU DOING”

But it reaches them like this:

* Some letters missing
    
* Some letters duplicated
    
* Some letters out of order
    

Now imagine this happening with:

* Bank transactions
    
* Login requests
    
* API responses
    

It would be a chaos, right.

This is exactly what the internet would look like **without protocols** (rules).

And that’s why **TCP exists**.

## What is TCP?

**TCP (Transmission Control Protocol)** is a communication rulebook.

It ensures that:

* Data reaches the correct destination
    
* Data arrives **in order**
    
* Missing data is resent
    
* Nothing is silently lost
    

In short:

> “TCP makes sure communication is reliable.”

Most of the things that you care about uses TCP:

* Websites (HTTP/HTTPS)
    
* APIs
    
* Emails
    
* File downloads
    
* etc.
    

## Problems That TCP Solves

The internet is unreliable by nature (so as the client).

Packets can:

* Get lost
    
* Arrive late
    
* Arrive out of order
    
* Get duplicated
    

TCP solves:

* Data loss
    
* Wrong order
    
* Partial delivery
    
* Silent failures
    

It turns an unreliable network into a **reliable connection**.

## The TCP 3-Way Handshake

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769762081684/2704b3c0-b8c1-4008-93e6-a7aec092b616.jpeg align="left")

Before sending actual data, TCP does something important.

It **sets up a connection**.

This setup process is called the **3-Way Handshake**.

Think of it like starting a phone call.

You don’t just start talking.  
You first make sure the other person is ready.

Let’s say **Client** wants to talk to **Server**.

### Step 1: SYN - “Can we talk?”

Client → Server

> “Hey, I want to start a connection.”

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

Client is saying:

* I want to talk
    
* Here’s my starting sequence number
    

### Step 2: SYN-ACK - “Yes, and I hear you”

Server → Client

> “Yes, I’m ready, and I got your message.”

This message is **SYN + ACK**.

Server is saying:

* I accept your request
    
* I acknowledge your sequence number
    
* Here’s my own sequence number
    

### Step 3: ACK - “Cool, let’s talk”

Client → Server

> “Got it. Let’s start.”

This final **ACK** confirms:

* Both sides are ready
    
* Both sides agree on sequence numbers
    

**Connection established 👍**

Now real data can flow.

## Why 3 Steps? Why Not Just One?

Because TCP wants to be ensure that:

* Client can reach server
    
* Server can reach client
    
* Both sides agree on starting points
    

Skipping steps could mean:

* Talking to a server that isn’t ready
    
* Sending data into the void
    

TCP prefers certainty over speed.

## How Data Transfer Works in TCP

Once the connection is established, data starts flowing.

But TCP doesn’t send data as one big chunk.

It:

* Breaks data into **segments**
    
* Numbers each segment
    
* Tracks what was received
    

This is where **sequence numbers** comes in.

## Sequence Numbers & Acknowledgements

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769762215133/9813fd37-fd2e-4f9d-9305-d51ce9d23161.jpeg align="left")

Think of sending pages of a book.

* Page 1
    
* Page 2
    
* Page 3
    

TCP does the same:

* Each data segment has a number
    
* Receiver sends back **ACKs** saying:
    
    > “I received everything up to this number”
    

This helps TCP:

* Detect missing data
    
* Maintain correct order
    

## What If a Packet Is Lost?

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769762407118/6e68df94-620e-4d5d-bae3-4c7eb3e8c127.jpeg align="left")

Let’s say:

* Segment 3 never arrives
    

Receiver sends ACK saying:

> “I’m still waiting for segment 3”

TCP on the sender side:

* Notices missing acknowledgement
    
* **Resends the lost segment**
    

This happens automatically.

You don’t see it.  
Your app doesn’t handle it.  
TCP does.

## How TCP Ensures Reliability, Order, and Correctness

TCP guarantees:

### Reliability

Lost data is retransmitted.

### Order

Out-of-order segments are rearranged.

### Correctness

Checksums ensure data isn’t corrupted.

All of this happens **below your application**.

That’s why HTTP is reliable.

## How a TCP Connection Is Closed

Just like starting a connection needs rules,  
ending it also needs rules.

TCP doesn’t just disappear.

## Connection Termination (FIN & ACK)

### Step 1: FIN - “I’m done sending”

One side sends **FIN**:

> “I have no more data to send.”

### Step 2: ACK - “I got that”

Other side acknowledges.

### Step 3: FIN (from the other side)

> “I’m also done.”

### Step 4: ACK

Final acknowledgement.

Connection closed cleanly.

This ensures:

* No data is cut off
    
* Both sides agree the conversation is over
    

## TCP Connection Lifecycle

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769762487104/88989d53-f64f-419b-a9e8-5d02e597f55d.jpeg align="left")

1. **Establish**
    
    * 3-Way Handshake (SYN → SYN-ACK → ACK)
        
2. **Transfer**
    
    * Data + Sequence Numbers + ACKs
        
    * Retransmissions if needed
        
3. **Close**
    
    * FIN → ACK → FIN → ACK
        

Order. Discipline. Reliability.

## Final Mental Model

Think of TCP like a **courier service**:

* Confirms pickup
    
* Numbers packages
    
* Tracks delivery
    
* Resends lost packages
    
* Confirms completion
    

Without TCP, the internet would be:

* Fast
    
* Unreliable
    
* Dangerous
    

With TCP, it’s:

* Slightly slower
    
* Predictable
    
* Trustworthy
    

You don’t need to memorize TCP.

Just remember **why it exists**.