# TCP Working: 3-Way Handshake & Reliable Communication

When you open a website, send a message, or upload a file, your data travels across many networks before reaching its destination. But the internet is messy - packets can get lost, arrive late, or show up out of order.

So how does your browser still load a complete webpage correctly?

The hero behind this reliability is **TCP - Transmission Control Protocol**.

Let’s break it down step by step.

## Why Do We Even Need Rules for Sending Data?

Imagine sending pages of a book to a friend using postcards.

Some postcards get lost. Some arrive out of order. Some arrive twice. Some get smudged and unreadable.

That’s exactly what can happen when data moves across the internet. Networks are not perfect. Devices crash, cables fail, routers drop traffic when busy.

If we just “send and hope,” we’d get:

* Broken downloads
    
* Corrupted images
    
* Half-loaded websites
    
* Duplicate messages
    

Clearly, we need **rules** to make communication dependable.

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

## What is TCP?

**TCP (Transmission Control Protocol)** is a communication protocol that ensures **reliable, ordered, and error-checked delivery of data** between two devices.

It works at the **Transport Layer** of the Internet model, sitting between applications (like browsers) and the network (IP).

Think of it as a **delivery manager** that:

* Tracks every piece of data
    
* Makes sure nothing is lost
    
* Re-sends missing pieces
    
* Puts everything back in the correct order
    

Without TCP, the modern web would be chaos.

## Problems TCP Is Designed to Solve

TCP was built to handle real-world network problems:

| Problem | What Can Go Wrong | How TCP Helps |
| --- | --- | --- |
| Packet Loss | Data disappears in transit | Retransmits missing data |
| Out-of-Order Delivery | Packets arrive shuffled | Reorders before delivery |
| Duplication | Same packet arrives twice | Detects and discards duplicates |
| Data Corruption | Bits flip due to errors | Uses checksums to detect errors |
| Network Overload | Too much data floods network | Uses congestion control |
| Receiver Overload | Receiver can't process fast enough | Uses flow control |

TCP doesn’t assume the network is reliable - it **creates reliability on top of an unreliable system**.

## What is the TCP 3-Way Handshake?

Before sending actual data, TCP needs to **establish a connection**. Both sides must agree to communicate and synchronize important information like sequence numbers.

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

Think of it like starting a phone call:

1. “Hello, can we talk?”
    
2. “Yes, I can hear you. Can you hear me?”
    
3. “Yes, great - let’s talk.”
    

Only after this exchange does real conversation begin.

## Step-by-Step: SYN → SYN-ACK → ACK

Here’s how two devices (Client and Server) start a TCP connection.

### Step 1 — SYN (Synchronize)

The client sends a packet with the **SYN flag** set.

It also sends an **initial sequence number (ISN)**.

Meaning:

> “Hi, I want to start a connection. My starting number is X.”

### Step 2 — SYN-ACK

The server responds with:

* **SYN flag** (to start its side)
    
* **ACK flag** (acknowledging the client)
    

Meaning:

> “Got your request. My starting number is Y. I acknowledge your X.”

### Step 3 — ACK

The client sends a final ACK.

Meaning:

> “I received your Y. We’re synced. Let’s start sending data.”

Connection established 🎉

### 3-Way Handshake Diagram

```mermaid
sequenceDiagram
    participant Client
    participant Server

    Client->>Server: SYN (Seq = X)
    Server->>Client: SYN-ACK (Seq = Y, Ack = X+1)
    Client->>Server: ACK (Ack = Y+1)
```

## How Data Transfer Works in TCP

Once the connection is established, data transfer begins.

TCP does **not** send everything blindly. It carefully tracks each byte.

### Sequence Numbers

Every byte of data has a **sequence number**. If a packet contains 500 bytes starting at sequence 1000, the next expected byte is 1500.

### Acknowledgements (ACKs)

The receiver sends ACKs saying:

> “I have received everything up to byte N.”

This is called a **cumulative acknowledgement**.

### Data Transfer Example

```mermaid
sequenceDiagram
    participant Client
    participant Server

    Client->>Server: Seq=1000 (500 bytes)
    Server->>Client: ACK=1500

    Client->>Server: Seq=1500 (500 bytes)
    Server->>Client: ACK=2000
```

## How TCP Ensures Reliability, Order, and Correctness

TCP uses several mechanisms:

### 1\. Retransmission

If the sender doesn’t receive an ACK in time, it assumes the packet was lost and sends it again.

### 2\. Ordering

Packets may arrive out of order, but TCP rearranges them using sequence numbers before passing them to the application.

### 3\. Duplicate Detection

If a packet is received twice, TCP recognizes the sequence number and discards the extra copy.

### 4\. Checksums

Each packet has a checksum. If data is corrupted, the receiver discards it and the sender retransmits.

## Packet Loss and Retransmission

Let’s say packet 2 is lost:

```mermaid
sequenceDiagram
    participant Client
    participant Server

    Client->>Server: Seq=1000
    Client->>Server: Seq=1500 (LOST)
    Client->>Server: Seq=2000

    Server->>Client: ACK=1500 (still waiting for missing data)

    Client->>Server: Retransmit Seq=1500
    Server->>Client: ACK=2500
```

The server keeps asking for the missing data by repeating the last ACK number it received successfully.

## How a TCP Connection is Closed

Ending a TCP connection is a **controlled process**, not a sudden stop.

It usually involves **four steps** and uses the **FIN flag**.

### Step-by-step Close

1. One side sends **FIN** → “I’m done sending data.”
    
2. Other side sends **ACK** → “Got it.”
    
3. Other side sends its own **FIN** → “I’m also done.”
    
4. First side sends **ACK** → “Connection closed.”
    

### Connection Termination Diagram

```mermaid
sequenceDiagram
    participant Client
    participant Server

    Client->>Server: FIN
    Server->>Client: ACK
    Server->>Client: FIN
    Client->>Server: ACK
```

This ensures both sides finish cleanly and no data is lost.

## TCP Connection Lifecycle

```mermaid
flowchart LR
    A[Connection Start] --> B[3-Way Handshake]
    B --> C[Data Transfer]
    C --> D[Reliability & Flow Control]
    D --> E[Connection Termination]
```

## Common Misconceptions

❌ **TCP and HTTP are the same** ✔ HTTP runs *on top of* TCP

❌ **TCP guarantees fast delivery** ✔ TCP guarantees **reliable** delivery, not always the fastest

❌ **Packets always arrive in order** ✔ TCP fixes the order — the network doesn’t

## Final Thoughts

TCP is the reason the internet feels reliable even though the underlying network is unpredictable.

It:

* Establishes a connection with a handshake
    
* Tracks every byte using sequence numbers
    
* Confirms delivery with acknowledgements
    
* Retransmits lost data
    
* Closes connections safely
    

Without TCP, loading a webpage would feel like assembling a puzzle with missing pieces.