# Understanding TCP

**Understanding TCP: The 3-Way Handshake and Reliable Communication**

Imagine you're sending a very important letter without any rules no confirmation if it arrived, no way to know if pages got lost or arrived out of order, and no guarantee the recipient even knows you're trying to communicate. Chaos, right? That's what happens when data travels over the internet without a reliable protocol. Packets can get lost, duplicated, arrive in the wrong order, or get corrupted. Applications like web browsing, email, or file transfers would break constantly.

This is why we need **TCP** (Transmission Control Protocol). TCP is a core part of the internet's transport layer (in the TCP/IP model). It works on top of IP (which is unreliable and just delivers packets best-effort) to provide **reliable, ordered, and error-checked** communication between applications on different devices.

### Why TCP is Needed and What Problems It Solves

Without TCP-like rules:

* Packets can be lost in the network.
    
* They can arrive out of order.
    
* Duplicates might show up.
    
* Data can get corrupted during transit.
    

TCP solves these by:

* Establishing a connection before sending data (no blind sending).
    
* Using **sequence numbers** to track and order bytes.
    
* Using **acknowledgments (ACKs)** to confirm receipt.
    
* Detecting and retransmitting lost packets.
    
* Checking for errors with checksums.
    
* Managing flow and congestion to avoid overwhelming the network.
    

TCP turns the unreliable IP network into a reliable byte stream for applications.

### The TCP 3-Way Handshake: Establishing a Connection

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1769668432218/4ac06142-9a9a-46df-9eaf-eccd2566dadc.png align="left")

Before any data flows, TCP uses a **3-way handshake** to set up the connection. Think of it like a polite phone conversation:

* **Client**: "Hello, are you there? (I'm ready to talk)"
    
* **Server**: "Hi! Yes, I'm here and ready too. (You start?)"
    
* **Client**: "Great, let's talk! (Acknowledged)"
    

This ensures both sides are ready, agree on initial sequence numbers, and can send/receive data in both directions.

Here's the step-by-step process:

1. **SYN** (Synchronize): The client sends a TCP segment with the **SYN** flag set and an initial **sequence number** (let's say Seq = X). This says: "I want to connect, my starting sequence is X."
    
2. **SYN-ACK** (Synchronize-Acknowledge): The server replies with **SYN** and **ACK** flags set. It sends its own initial sequence number (Seq = Y) and acknowledges the client's number by setting **Acknowledgment number = X + 1**. This says: "Got your request, my starting sequence is Y, and I acknowledge yours."
    
3. **ACK** (Acknowledge): The client sends a segment with the **ACK** flag set, Acknowledgment number = Y + 1. This confirms: "I got your SYN, connection is established."
    

After this, the connection is open and full-duplex (both sides can send data independently).

![File:Tcp state diagram fixed.svg - Wikimedia Commons](https://upload.wikimedia.org/wikipedia/commons/a/a2/Tcp_state_diagram_fixed.svg align="left")

(Example of TCP state diagram showing connection establishment and other states)

![File:TCP Protocol Diagram.png - Wikimedia Commons](https://upload.wikimedia.org/wikipedia/commons/4/4e/TCP_Protocol_Diagram.png align="left")

(Another common TCP 3-way handshake illustration)

### How Data Transfer Works in TCP

Once connected, data is sent in segments (chunks). Each byte gets a sequence number.

* Sender assigns a sequence number to each byte (or segment).
    
* Receiver sends back an **ACK** with the next expected sequence number (cumulative ACK: "I've received everything up to this point").
    

For example:

* Sender sends bytes 1000–2000 → Seq = 1000, length 1000 bytes.
    
* Receiver gets it → sends ACK = 2001 ("Next byte I expect is 2001").
    

This allows efficient pipelining (sending multiple segments before ACKs arrive) while ensuring order.

![System Design Notes - Samir Paul](https://samirpaulb.github.io/files/cdn-request-flow.webp align="left")

(Visual of TCP data flow with sequence and ACK numbers — note: actual diagrams often show arrows with Seq and Ack values)

### How TCP Ensures Reliability, Order, and Correctness

TCP guarantees:

* **Reliability** — via retransmissions. If no ACK arrives within a timeout (Retransmission Timeout or RTO), sender retransmits.
    
* **Order** — sequence numbers let receiver reorder segments if needed.
    
* **Correctness** — checksum detects corruption (bad segments discarded, triggering retransmission).
    

For packet loss:

* Sender transmits segment.
    
* If lost, receiver never ACKs it.
    
* Sender times out → retransmits.
    
* Or, fast retransmit: if receiver gets later segments, it sends duplicate ACKs → sender retransmits quickly.
    

![System Design Notes - Samir Paul](https://samirpaulb.github.io/files/load-balancer-architecture.webp align="left")

(Conceptual flow showing lost packet and retransmission — sender resends after timeout or duplicate ACKs)

### How a TCP Connection is Closed

TCP uses a **4-way handshake** (or sometimes combined) to close gracefully, as each side must close its half independently (half-close possible).

Typical flow:

1. One side (say client) sends **FIN** (Finish) → "I'm done sending."
    
2. Other side ACKs the FIN → "Got it, I acknowledge your close."
    
3. When ready, the other side sends its own **FIN** → "I'm done too."
    
4. First side ACKs the final FIN → connection fully closed.
    

This is often called 4-way because of the separate FINs and ACKs.

Understanding Modbus TCP-IP: An In depth Exploration

TCP is the foundation of reliable internet communication. Understanding the handshake and reliability mechanisms helps when building web apps, debugging network issues, or learning protocols.