Skip to main content

Command Palette

Search for a command to run...

The Invisible Handshake: How TCP Ensures Reliable Communication

Updated
7 min read
R

I am a developer from India.

1. The Chaos Without Rules: Why Do We Need TCP?

Imagine you are sending a 10-page letter to a friend, but you tear the pages out and mail them individually in separate envelopes.

  • Envelope 1 arrives on Monday.

  • Envelope 2 gets lost in the mail.

  • Envelope 3 arrives on Tuesday.

  • Envelope 4 arrives before Envelope 1 because it took a faster route.

When your friend tries to read the letter, they have pages 1, 3, and 4, but page 2 is missing, and the order is wrong. They have no idea if page 4 is actually the end or if there are more pages coming.

This is what happens when data is sent over the internet without rules (like UDP). Packets can get lost, duplicated, or arrive out of order. For a video stream, this might just mean a pixelated frame. But for loading a webpage, downloading a file, or sending an email, this chaos is unacceptable. You need every byte, in the exact right order.

TCP (Transmission Control Protocol). TCP is the protocol that acts as the "registered mail" service of the Internet. It ensures that:

  1. Reliability: Every piece of data arrives.

  2. Order: Data is reassembled in the correct sequence.

  3. Correctness: Data is not corrupted during transit.


2. The TCP 3-Way Handshake: Establishing Trust

Before any data can be exchanged, the Client (your browser) and the Server (the website) must agree to talk. They need to synchronize their "sequence numbers" so they can track which data has been sent and received. This process is called the 3-Way Handshake.

The Analogy: The Phone Call

Think of the handshake like starting a phone call where the line is noisy:

  1. You: "Can you hear me?" (SYN)

  2. Friend: "I hear you. Can you hear me?" (SYN-ACK)

  3. You: "I hear you." (ACK)

Now, the connection is established, and you can talk.

Step-by-Step Technical Breakdown

Step 1: SYN (Synchronize)

  • Who: Client → Server

  • What Happens: The client wants to initiate a connection. It sends a segment with the SYN flag set to 1.

  • Key Detail: The client picks a random starting Sequence Number (SEQ = x). This number tells the server, "My first byte of data will be labeled x."

  • State: The client enters SYN_SENT state.

Step 2: SYN-ACK (Synchronize-Acknowledge)

  • Who: Server → Client

  • What Happens: The server receives the SYN. It acknowledges the client’s request and sends its own synchronization request.

  • Key Details:

    • It sets the ACK flag to 1 and the SYN flag to 1.

    • It sets the Acknowledgment Number (ACK = x + 1). This tells the client, "I received your sequence x, and I’m ready for x+1 next."

    • The server picks its own random Sequence Number (SEQ = y).

  • State: The server enters SYN_RECEIVED state.

Step 3: ACK (Acknowledge)

  • Who: Client → Server

  • What Happens: The client receives the SYN-ACK. It acknowledges the server’s sequence number.

  • Key Details:

    • It sets the ACK flag to 1.

    • It sets the Acknowledgment Number (ACK = y + 1). This tells the server, "I received your sequence y, and I’m ready for y+1 next."

    • The client’s Sequence Number is now SEQ = x + 1.

  • State: Both sides enter ESTABLISHED state. Data transfer can now begin.

Visual Diagram


3. How Data Transfer Works: Sequence Numbers & ACKs

Once the handshake is done, TCP treats data like a numbered book. Every byte of data sent is assigned a Sequence Number.

The Mechanism

  1. Segmentation: If you send a 1MB file, TCP breaks it into smaller chunks called segments (usually around 1460 bytes of data per segment, depending on the Maximum Segment Size).

  2. Numbering: Each segment gets a sequence number.

    • Segment 1: Seq 1–1460

    • Segment 2: Seq 1461–2920

    • Segment 3: Seq 2921–4380

  3. Acknowledgment (ACK): The receiver doesn’t ACK every single packet immediately. Instead, it uses Cumulative Acknowledgment.

    • If the receiver gets Segment 1 and 2, it sends back an ACK = 2921.

    • This means: "I have received everything up to byte 2920. I am expecting byte 2921 next."

Example Scenario

  • Client sends: "Hello" (5 bytes). Seq = 100.

  • Server receives: "Hello".

  • Server replies: ACK = 105. (100 + 5 bytes = 105).

  • Meaning: "I got bytes 100-104. Send me byte 105 next."


4. Reliability, Order, and Correctness

How does TCP guarantee that the data is perfect? It uses three main mechanisms.

A. Handling Packet Loss (Retransmission)

What if Segment 2 gets lost on the internet?

  1. The client sends Segment 1, 2, and 3.

  2. The server receives 1 and 3, but 2 is missing.

  3. The server cannot ACK 3 yet because it’s waiting for 2. It keeps sending ACK = Start_of_Segment_2 (duplicate ACKs).

  4. The client notices it hasn’t received an ACK for Segment 2 after a certain time (Timeout) or sees multiple duplicate ACKs.

  5. The client retransmits Segment 2.

  6. Once the server gets Segment 2, it sends a new ACK for the next expected byte.

Key Concept: Sliding Window. TCP doesn’t wait for an ACK for every single packet before sending the next one. It sends a "window" of packets (e.g., 10 packets) at once. As ACKs come back, the window "slides" forward, allowing more data to be sent. This maximizes speed while maintaining reliability.

B. Ensuring Order

Because packets can take different routes, Segment 3 might arrive before Segment 2.

  • TCP places incoming segments into a buffer based on their Sequence Numbers.

  • It holds Segment 3 in the buffer until Segment 2 arrives.

  • Only when the sequence is complete does it pass the data up to the application (e.g., your web browser).

C. Ensuring Correctness (Checksums)

Every TCP segment includes a Checksum.

  • The sender calculates a mathematical value based on the data.

  • The receiver recalculates the checksum.

  • If the values don’t match, the data was corrupted (bit flip). The receiver discards the packet and does not send an ACK. The sender eventually times out and retransmits.


5. Closing the Connection: The 4-Way Wavehand

Unlike the handshake, closing a TCP connection usually takes 4 steps. This is because TCP is full-duplex (data can flow both ways simultaneously). Each direction must be closed independently.

The Analogy: Hanging Up

  1. You: "I’m done talking." (FIN)

  2. Friend: "Okay, I heard you." (ACK)

  3. (Friend finishes sending their last thoughts)

  4. Friend: "I’m also done talking." (FIN)

  5. You: "Okay, goodbye." (ACK)

Step-by-Step Termination

  1. FIN (Client → Server): The client sends a FIN flag, indicating it has no more data to send. It enters FIN_WAIT_1.

  2. ACK (Server → Client): The server acknowledges the FIN. It enters CLOSE_WAIT. The connection is now half-closed. The server can still send data to the client.

  3. FIN (Server → Client): When the server is also done sending data, it sends its own FIN. It enters LAST_ACK.

  4. ACK (Client → Server): The client acknowledges the server’s FIN. It enters TIME_WAIT (a short timer to ensure the final ACK arrives). The server enters CLOSED. After the timer expires, the client also closes.

Visual Diagram


6. Summary

  • TCP vs. UDP: TCP is reliable/ordered (email, web); UDP is fast/unreliable (video calls, gaming).

  • Handshake: SYN → SYN-ACK → ACK. Establishes sequence numbers.

  • Data Transfer uses sequence numbers for ordering and ACKs for confirmation.

  • Reliability: Achieved via Retransmission (on loss), Buffering (for order), and Checksums (for correctness).

  • Termination: FIN → ACK → FIN → ACK. Closes both directions of communication.