DEV Community

Pratham
Pratham

Posted on

TCP Explained: The Invisible Handshake Governing the Internet

#webdev #networking #tcp #chaicode

Prerequisites: Basic understanding that computers send "packets" of data.

Audience: Developers who want to understand how the internet ensures data actually arrives.

The Roots: The Problem with Shouting (Why We Need Rules)

Imagine you are in a crowded, noisy restaurant. You want to tell your friend a specifically ordered list of 10 movie recommendations.

If you just start shouting the names immediately ("UDP style"):

  1. Scenario: You shout all 10 names at once.
  2. The Problem:
    • The waiter drops a tray (Noise/Packet Loss) -> Your friend misses name #3.
    • You talk faster than they can write (Flow Control) -> They miss names #7, #8, #9.
    • You say "The Matrix" then "Inception," but they hear "Inception" then "The Matrix" (Out of Order).
    • Worst of all: You have no idea if they heard you. You just shouted and hoped for the best.

This is how the internet works by default (IP/UDP). It's fast, but it's chaotic.

The Solution: We need a strict set of rules—a Protocol—to ensure that:

  1. We know the other person is ready to listen.
  2. We know they heard exactly what we said.
  3. If they missed something, we say it again.

Enter TCP (Transmission Control Protocol). Think of TCP not as a technology, but as a Reliable Project Manager for your data.

The Trunk: The 3-Way Handshake (Starting the Conversation)

Before any data (movie names) is exchanged, TCP requires a formal introduction. You don't just walk up to a stranger and whisper data. You establish a Connection.

This process is famous. It is called the 3-Way Handshake.

The Conceptual Analogy: The Phone Call

  1. You: Dial the number. "Hello? Can you hear me?"
  2. Friend: "Yes, I hear you. Can you hear me?"
  3. You: "Yes, I hear you too. I'm going to start listing the movies now."

If any of these 3 steps fails, the conversation does not begin.

The Technical Reality: SYN, SYN-ACK, ACK

In the computer world, we use "Flags" (tiny distinct bits in the packet header) to indicate these states.

Step 1: The SYN (Synchronize)

  • Actor: Client (Your Browser)
  • Action: Sends a packet with the SYN flag turned on.
  • Meaning: "I want to synchronize numbers with you. Let's start a connection. My random ID (Sequence Number) is 100."
  • State: The Client is now in SYN_SENT state.

Step 2: The SYN-ACK (Synchronize-Acknowledge)

  • Actor: Server (Google/Facebook)
  • Action: Receives the SYN. Sends a packet with SYN AND ACK flags.
  • Meaning:
    • ACK: "I Acknowledge your ID 100. The next one I expect is 101."
    • SYN: "And I also need to synchronize my numbers. My random ID is 5000."
  • State: The Server is in SYN_RECEIVED state.

Step 3: The ACK (Acknowledge)

  • Actor: Client
  • Action: Receives the SYN-ACK. Sends a packet with just the ACK flag.
  • Meaning: "I Acknowledge your ID 5000. The next one I expect is 5001. The connection is established."
  • Result: ESTABLISHED. The "pipe" is now open. real data can flow.

Visual: The 3-Way Handshake 

      CLIENT                                      SERVER
        |                                           |
        |--- SYN (Seq=100) ------------------------>|  (1. Client asks to connect)
        |                                           |
        |<-- SYN-ACK (Seq=5000, Ack=101) -----------|  (2. Server accepts & asks back)
        |                                           |
        |--- ACK (Ack=5001) ----------------------->|  (3. Client accepts Server)
        |                                           |
   ESTABLISHED                                 ESTABLISHED
Enter fullscreen mode Exit fullscreen mode

The Branches: Reliability & Ordering (The Smart Part)

Now that the connection is open, how does TCP solve the problems of the "Shouting" method?

1. Verification (Sequence Numbers & ACKs)

Every single byte of data sent over TCP is numbered.

  • You send: "Here are bytes 1 to 100."
  • Receiver says: "ACK 101" (Meaning: "I got everything up to 100. I am ready for byte 101").

This is the Receipt. If you don't get a receipt, you assume the package was stolen/lost.

Visual: Normal Data Transfer 

      CLIENT                                      SERVER
        |                                           |
        |--- Seq=101 ("Data: Hello") -------------->|
        |                                           |
        |<-- ACK=106 ("Got 5 bytes. Next?") --------|
        |                                           |
        |--- Seq=106 ("Data: World") -------------->|
        |                                           |
        |<-- ACK=111 ("Got 5 bytes. Next?") --------|
Enter fullscreen mode Exit fullscreen mode

2. Retransmission (Handling Packet Loss)

This is TCP's superpower.

  • Scenario: You send bytes 1-100.
  • Event: A router crashes. The packet is destroyed.
  • Result: You (the Sender) start a stopwatch (Retransmission Timer).
  • Observation: "Hmm. I've been waiting 200ms and haven't received an ACK for those bytes."
  • Action: Retransmit! You send the exact same data again.

This ensures Reliability. The application (e.g., your web browser) never knows packet loss happened. TCP handled it silently in the background.

Visual: Packet Loss & Retransmission 

      CLIENT                                      SERVER
        |                                           |
        |--- Packet A (Seq=100) ------------------->| (Arrives OK)
        |                                           |
        |--- Packet B (Seq=200) --X                 | (LOST IN TRANSIT!)
        |                         X                 |
        |<-- ACK=200 ("Got A. Expecting 200") ------|
        |                                           |
        | [Timer Ticking...]                        |
        | [Timer Ticking...]                        | (Client waits...)
        | [TIMEOUT!]                                |
        |                                           |
        |--- RETRANSMIT Packet B (Seq=200) -------->| (Sent Again)
        |                                           |
        |<-- ACK=300 ("Got B! Expecting 300") ------|
Enter fullscreen mode Exit fullscreen mode

3. Ordering (Fixing the Timeline)

The internet is a web. Packet A might take a route via London, and Packet B might take a route via Tokyo. Packet B might arrive before Packet A.

  • UDP application: Plays the video frames out of order (Glitch).
  • TCP application: Looks at the Sequence Numbers. "I have packet 1 and packet 3. I am missing 2. I will hold packet 3 in a 'Buffer' (Waiting Room) until packet 2 arrives. Then I will give them to the user in order: 1, 2, 3."

The Leaves: Closing the Connection (The Polite Goodbye)

When the data transfer is done, we don't just walk away (which would leave the server waiting, wasting memory). We perform a 4-Way Handshake to close.

  1. Client: Sends FIN (Finish). "I am done talking."
  2. Server: Sends ACK. "Message received. Let me finish my work."
    • (Server finishes sending any remaining data)
  3. Server: Sends FIN. "Okay, I'm done talking too."
  4. Client: Sends ACK. "Understood. Goodbye."

It takes 4 steps because TCP is a Full Duplex protocol—meaning connection can be closed in one direction while still open in the other (like hanging up the phone but still listening).

Visual: Connection Lifecycle 

   CLOSED                                       CLOSED
     |                                            |
     | (1) 3-WAY HANDSHAKE                        |
     | <========================================> |
     |                                            |
   ESTABLISHED                                  ESTABLISHED
     |                                            |
     | (2) DATA TRANSFER                          |
     | =========================================> |
     |                                            |
     | (3) 4-WAY CLOSURE (Fin)                    |
     | <========================================> |
     |                                            |
   CLOSED                                       CLOSED
Enter fullscreen mode Exit fullscreen mode

Summary: Why Developers Care

You generally don't touch TCP implementation in your code (Node.js or Python handles it). But understanding it explains "Why":

  1. Why is http slower than udp? Because of the overhead: The 3-Way Handshake + Waiting for ACKs.
  2. Why do WebSockets exist? To keep that expensive TCP connection open, instead of doing the 3-Way Handshake over and over for every message.
  3. Why does my game lag? Because TCP is waiting for a lost packet to be retransmitted before showing you the current state (Head-of-Line Blocking).

Quick Recap Visual

  • SYN: "Hello?"
  • SYN-ACK: "Hello! I hear you."
  • ACK: "Great. Let's go."
  • SEQ/ACK: "Here is data 1." -> "Got 1, send 2."
  • FIN: "Bye."

TCP is the unsung hero that turns the chaotic wilderness of the internet into a reliable conversation.

Top comments (0)