# TCP: 3-Way Handshake & Reliable Data Transfer

Imagine sending data across the internet with no rules.

You send some data, but how does the receiver know where it came from? What if some data is lost? What if it arrives in the wrong order? How does the sender know that the receiver is ready to communicate?

These are some of the problems **TCP (Transmission Control Protocol)** is designed to solve.

TCP is a **connection-oriented transport-layer protocol** that provides reliable, ordered, and error-checked delivery of data between applications.

## What Problems Does TCP Solve?

Networks are not perfectly reliable. Data can be delayed, lost, duplicated, or arrive out of order.

TCP handles these problems by providing mechanisms such as:

*   **Connection establishment**
    
*   **Sequence numbers**
    
*   **Acknowledgements**
    
*   **Retransmission**
    
*   **Ordered delivery**
    
*   **Flow control**
    
*   **Congestion control**
    
*   **Connection termination**
    

Before TCP transfers application data, it first establishes a connection using the **3-way handshake**.

## TCP 3-Way Handshake

The handshake allows both sides to establish communication and synchronize their initial sequence numbers.

Think of it like a conversation:

> **Client:** "Can we communicate?"

> **Server:** "Yes, I can communicate. Can you hear me?"

> **Client:** "Yes, I can hear you."

Now both sides are ready to exchange data.

The actual process uses three TCP messages: **SYN, SYN-ACK, and ACK**.

### Step 1: SYN

The client sends a **SYN (Synchronize)** segment to the server.

It basically says:

> "I want to establish a TCP connection."

The client also includes an **initial sequence number**. Sequence numbers help TCP keep track of the position of data in the communication stream.

```text
Client                         Server
   |                             |
   | -------- SYN -------------> |
   |                             |
```

### Step 2: SYN-ACK

The server receives the SYN and responds with **SYN-ACK**.

This message does two things:

1.  **SYN:** The server provides its own initial sequence number.
    
2.  **ACK:** The server acknowledges the client's SYN.
    

In simple terms:

> "I received your request, and I also want to communicate."

```text
Client                         Server
   |                             |
   | -------- SYN -------------> |
   | <------ SYN + ACK ---------- |
   |                             |
```

### Step 3: ACK

Finally, the client sends an **ACK (Acknowledgement)** back to the server.

This confirms that the client's side has received the server's response.

```text
Client                         Server
   |                             |
   | -------- SYN -------------> |
   | <------ SYN + ACK ---------- |
   | -------- ACK -------------> |
   |                             |
```

The connection is now established, and application data can be transferred.

## How Does TCP Transfer Data?

Once the connection exists, the application passes data to TCP.

TCP assigns **sequence numbers** to the data so that the receiver can determine its correct order.

The receiver sends **ACKs** to confirm that data has been received.

For example:

```text
Client                         Server

Data: Seq 1000  ------------->

              <------------- ACK 1500
```

The exact numbers depend on the amount of data being transmitted, but the basic idea is simple:

**Sequence numbers identify data; acknowledgements confirm received data.**

### What If Data Gets Lost?

Suppose the sender transmits three pieces of data, but one never reaches the receiver.

TCP can detect the missing data through its acknowledgement and retransmission mechanisms.

```text
Client                         Server

Segment 1 ------------------->
Segment 2 --------X (lost)

Segment 3 ------------------->

        <-------------------- ACK

Segment 2 ------------------->
```

TCP can then retransmit the missing data.

This is one of the main reasons TCP is considered **reliable**.

TCP also makes sure data is delivered to the application in the correct order, even if network packets arrive out of order.

## How Does TCP Know When to Retransmit?

TCP does not wait forever for a missing acknowledgement.

It uses **timers** and other mechanisms to determine when data may need to be retransmitted.

TCP also uses a process called **flow control** to prevent a sender from overwhelming the receiver and **congestion control** to adjust transmission when the network itself becomes congested.

These mechanisms allow TCP to provide reliable communication while adapting to changing network conditions.

## How Does TCP Connection Closing Work?

TCP also has a controlled process for ending a connection.

Unlike the 3-way handshake used for establishing a connection, normal TCP termination commonly involves **FIN and ACK messages in both directions** because TCP communication is full-duplex: each side can send data independently.

A simplified flow looks like this:

```text
Client                         Server

   | -------- FIN ------------> |
   | <--------- ACK ----------- |
   | <--------- FIN ----------- |
   | -------- ACK ------------> |
```

**FIN** means a side has finished sending data.

**ACK** confirms that the FIN was received.

After both directions have been closed, the TCP connection is terminated.

## TCP Connection Lifecycle

The complete lifecycle can be simplified as:

```text
Connection Establishment
        ↓
   SYN → SYN-ACK → ACK
        ↓
     Data Transfer
        ↓
Sequence Numbers + ACKs
        ↓
     Connection Close
        ↓
    FIN → ACK → FIN → ACK
```

## Final Takeaway

TCP is more than simply "sending data reliably."

It first **establishes a connection**, then uses **sequence numbers, acknowledgements, retransmission, flow control, and congestion control** to manage data transfer. Finally, it uses **FIN and ACK messages** to close the connection properly.

The easiest mental model is:

> **Handshake before communication, sequence and acknowledgement during communication, and FIN/ACK when communication ends.**

That process is what allows applications to communicate reliably even though the underlying network can lose, delay, or reorder data.