# TCP Working: 3-Way Handshake & Reliable Communication

## TCP Explained Like You’re New To Networking

*A beginner-friendly guide (with some casual language mistakes on purpose)*

When you send a message over the internet, it doesn’t travel as one big chunk. It’s broken into lots of small **packets** that fly through different paths and can arrive:

* Late
    
* Out of order
    
* Duplicated
    
* Or not at all
    

If we just “throw packets into the network” with **no rules**, you’d get:

* Half-loaded web pages
    
* Corrupted files
    
* Messages missing parts in the middle
    

This is where **TCP (Transmission Control Protocol)** comes in.

TCP is a set of **rules** that makes sure your data:

* Arrives at the other side
    
* Arrives **in order**
    
* Arrives **without corruption**
    
* Or you at least know if something went wrong
    

Let’s walk through:

* What TCP is and why it’s needed
    
* Problems TCP is designed to solve
    
* What the **TCP 3-Way Handshake** is
    
* Step-by-step of **SYN → SYN-ACK → ACK**
    
* How data transfer works in TCP
    
* How TCP ensures **reliability, order, and correctness**
    
* How a TCP connection is **closed**
    

All in simple language, without too much packet-level overload.

## What is TCP, and Why Is It Needed?

### What happens without rules?

Imagine sending letters with a very broken postal system:

* Letters sometimes get lost
    
* Sometimes they arrive twice
    
* Sometimes letter #3 arrives before letter #1
    
* Sometimes they arrive damaged
    

If you had **no agreement** with the other person, you wouldn’t know:

* Which letters are missing
    
* Whether you should resend something
    
* Whether the other person even got your message
    

This is what sending raw packets over the internet would look like **without TCP**.

### TCP to the rescue

**TCP (Transmission Control Protocol)** is like a **smart mail system** on top of the basic delivery:

* Cuts data into **packets**
    
* Adds **numbers** to them so the order is known
    
* Makes the receiver **confirm** what it got
    
* Resends anything that seems lost
    
* Make sure both sides **agree** to start and end the conversation
    

TCP is used by things like:

* HTTP / HTTPS (websites)
    
* SMTP (email)
    
* FTP (file transfer)
    
* Many backend services and APIs
    

In short, **if you care about data being correct and ordered, you usually use TCP.**

## Problems TCP Is Designed To Solve

TCP mainly solves three big issues:

### Reliability

Problem: Packets can be **lost** on the network.

TCP solution:

* Every packet has a **sequence number**
    
* The receiver sends **ACKs (acknowledgements)** back
    
* If the sender doesn’t get an ACK in time → assumes the packet is lost → **retransmits**
    

### Ordering

Problem: Packets can arrive **out of order**.

TCP solution:

* Each packet has a **sequence number**
    
* The receiver uses numbers to **reorder** packets back into the right order
    
* Application (like your browser) only sees a **clean, ordered stream of bytes**
    

### Data Integrity / Correctness

Problem: Packets can get **corrupted** in transit.

TCP solution:

* Each packet contains a **checksum**
    
* Receiver verifies checksum
    
* If a mismatch → packet is considered bad → dropped → sender will resend
    

So TCP is like a careful, slightly paranoid friend that:

* Checks everything
    
* Confirms everything
    
* Retries when something looks wrong
    

## What Is the TCP 3-Way Handshake?

Before sending data, TCP needs both sides to **agree** to communicate. That’s the **3-Way Handshake**.

It’s called that because it uses **three messages**:

1. **SYN**
    
2. **SYN-ACK**
    
3. **ACK**
    

### Conversation Analogy

Imagine two people want to talk on the phone:

1. Person A: “Hey, can we talk?”
    
2. Person B: “Yes, we can talk. Can you hear me?”
    
3. Person A: “Yes, I can hear you. Let’s start.”
    

After this, both people know **the connection is active** and they can start sending real information.

In TCP terms:

* Person A = **Client**
    
* Person B = **Server**
    
* Those three lines = **SYN → SYN-ACK → ACK**
    

## Step-by-Step: SYN, SYN-ACK, and ACK

Let’s go through the handshake more slowly.

We’ll say:

* **Client** = the side that starts the connection (like your browser)
    

* **Server** = the side that accepts it (like a web server)
    

### Step 1: Client → Server (SYN)

The client sends a **SYN** packet:

* “I want to start a TCP connection.”
    

* “Here is my **initial sequence number** (ISN) for data I’ll send.”
    

```bash
Client                Server
  | ---- SYN ---->      |
```

### Step 2: Server → Client (SYN-ACK)

* The server receives the SYN
    
* Server sends back a **SYN-ACK** packet:
    

It means two things at once:

1. **SYN**:
    

“Okay, I also want to start a TCP connection. Here is **my** initial sequence number.”

1. **ACK**:
    

“And by the way, I **acknowledge** that I got your SYN.”

So SYN-ACK = “Yes, let’s talk, and I heard you.”

```bash
Client                Server
  | ---- SYN ---->      |
  | <--- SYN-ACK ---    |
```

### Step 3: Client → Server (ACK)

* Client receives the SYN-ACK
    
* Client sends an **ACK** back:
    

“I confirm I got your SYN-ACK. Now we’re both ready.”

At this point:

* **Connection is established**
    
* Both sides know:
    
* The other one exists
    
* The other one is ready
    
* The initial sequence numbers they will use
    

Now, **real data** (like HTTP requests) can start flowing.

### Text Diagram: 3-Way Handshake

Client (C) on left, Server (S) on right:

```bash
C                                   S

| ----------- SYN ------------>     |

|    "Can we talk? My seq = x"      |

|                                   |

| <-------- SYN-ACK ----------      |

|   "Yes, seq = y, I got x"         |

|                                   |

| ----------- ACK ------------>     |

|        "I got y, go!"             |
```

Connection established ✅

---

## How Data Transfer Works in TCP

Once the handshake is done, data transfer begins.

### TCP as a Byte Stream

* TCP sees data as a **stream of bytes**, not “messages”.
    
* It breaks your data into **segments** (packets) under the hood.
    
* Each byte in the stream has a **sequence number**.
    

Example:

* Client sends “HELLO WORLD.”
    
* TCP might split it into two packets:
    
* Packet 1: “HELLO ” (bytes 1000–1005)
    
* Packet 2: “WORLD” (bytes 1006–1010)
    

Receiver doesn’t care about the split; TCP reassembles them and gives “HELLO WORLD” to the app.

### Sequence Numbers and ACKs (High Level)

* Sender labels each byte with a **sequence number**
    
* The receiver sends back **ACKs** saying:
    

\&gt; “I have correctly received everything **up to byte #N**. Please send the next ones.”

For example:

* Sender sends bytes 1000–1499
    
* The receiver gets them and sends them back:
    

\&gt; “ACK 1500” (meaning: I got everything up to 1499, next expected is 1500)

This is called **cumulative acknowledgment**.

## How TCP Ensures Reliability, Order, and Correctness

### Reliability: Handling Packet Loss

Packets sometimes get lost. Here’s what TCP does:

1. Sender sends packets with sequence numbers
    
2. If the sender doesn’t receive an **ACK** for a packet within a timeout:
    

* It assumes the packet was lost
    
* It **retransmits** the missing packet
    

```bash
Sender: sends bytes 1000–1499 
        (lost on the network)
Sender waits... no ACK

Sender: "Hmm, no ACK..."
        → sends bytes 1000–1499 again

Receiver (this time gets it):
        → sends ACK 1500
```

The application usually never knows this happened. TCP hides all this retry logic.

### Ordering: Out-of-Order Packets

Sometimes packets arrive in weird order:

* Packet with bytes 1500–1999 arrives
    
* The packet with bytes 1000–1499 is late
    

Receiver behavior:

* It can **buffer** out-of-order packets
    
* It only passes data to the application **in order**
    
* It keeps sending ACKs for the highest continuous sequence it has
    

So if it got 1500–1999 but not 1000–1499 yet, it might still say:

“ACK 1000” (meaning: I’m still waiting, starting from 1000)

This encourages the sender to retransmit missing parts.

### Correctness: Checksums

Each TCP segment has a **checksum**:

* Sender calculates a checksum over the header + data
    
* The receiver recalculatesthe checksum when the packet arrives
    
* If they don’t match → packet corrupted → drop packet
    
* Loss will be handled by the **retransmission logic** (no ACK received)
    

So TCP ensures **data integrity**: what you send is what they get.

## How a TCP Connection Is Closed

Just like starting a conversation needs a handshake, **ending it** also has a process.

### Basic Idea: Graceful Shutdown

One side says:

“I’m done sending data, but I can still receive.”

The other side says:

“Got it, I’ll also finish, and then we’re done.”

### FIN and ACK

TCP uses:

* **FIN** (Finish) – “I’m done sending.”
    
* **ACK** – “I got your FI.N”
    

Typical simplified flow (client closes first):

1. **Client → Server: FIN**
    

“I’m done sending data.”

1. **Server → Client: ACK**
    

“Okay, I know you’re done. I can still send if needed.”

1. The server might still send the remaining data. When it’s done:
    
2. **Server → Client: FIN**
    

“I’m also done sending.”

1. **Client → Server: ACK**
    

“Got it. We’re both done.”

After this final ACK, the connection is closed.

### Text Diagram: TCP Close

```bash
Client                             Server

| ---- FIN ------------------>     |

|   "I'm done sending"            |

| <--- ACK -------------------     |

|   "Got it"                      |

|                                 |

| <--- FIN -------------------     |

|   "I'm also done sending"       |

| ---- ACK ------------------>     |

|   "Got it, bye"                 |
```

Connection closed ✅

There are more details (like TIME\_WAIT state), but at a beginner level, this flow is enough.

## TCP Connection Lifecycle Summary

You can think of a TCP connection as 3 big phases:

1. **Establish** – 3-Way Handshake
    

* SYN → SYN-ACK → ACK
    

1. **Transfer** – Data exchange
    

* Sequence numbers
    
* ACKs
    
* Retransmissions
    
* Reordering
    

1. **Close** – Graceful termination
    

* FIN → ACK → FIN → ACK
    

Diagram (high level):

```bash
[Establish]

SYN → SYN-ACK → ACK

[Transfer]

DATA ↔ DATA

(SEQ + ACK, retransmissions, ordering)

[Close]

FIN → ACK → FIN → ACK
```

## Why TCP Matters for Backend and System Design

As a software engineer, even if you don’t manually write TCP code, it affects you everywhere:

* **HTTP/HTTPS** runs on top of TCP
    
* **API latency** includes:
    
* TCP handshake time
    
* Possible retransmissions
    
* **Throughput & performance** depend on:
    
* How TCP handles congestion and windows
    
* **Connection limits**:
    
* Each TCP connection uses resources
    
* Too many connections = resource pressure on servers
    

## TCP Explained Like You’re New To Networking

When two computers talk over the internet, they send data in **packets**. But what happens if:

* Are some packets **lost**?
    
* Some arrive **twice**?
    
* Some arrive in the **wrong order**?
    
* Or the receiver gets **overwhelmed**?
    

If there are no rules, communication becomes messy and unreliable.

This is where **TCP (Transmission Control Protocol)** comes in. It’s one of the main protocols of the internet, and its job is to make communication between two machines **reliable, ordered, and correct**.

**Happy Learning! 🚀**

*Have questions about how browsers work? Drop them in the comments!*