Skip to main content

Command Palette

Search for a command to run...

TCP Internals; Handshake, Delivery, and Goodbye

TCP is the "Safe Mode", But how does it actually guarantee safety?

Updated
3 min read
TCP Internals; Handshake, Delivery, and Goodbye

Introduction

In the last blog, we learned that TCP is the "Safe Mode" of the internet (like driving a Thar carefully). But how does it actually guarantee safety?

If I send a meme to my friend, how does TCP make sure the top half doesn't arrive after the bottom half?

The answer lies in The Handshake and The Sequence.

1. The 3-Way Handshake

TCP is extremely polite. It never sends data without asking first. It uses a 3-step process called the 3-Way Handshake.

Imagine calling your friend:

Step 1: SYN (The Dial)

  • You (Client): "Hello? Can you hear me?"

  • Technical: You send a packet with the SYN flag (Synchronize, it’s just jargon) and a random number (e.g., 100). This is your ID.

Step 2: SYN-ACK (The Answer)

  • Friend (Server): "Yes, I hear you (ACK 101). Can you hear me? (SYN 5000)"

  • Technical: The server ACKs your number (100 + 1) and sends its own SYN number (5000). Now both have IDs.

Step 3: ACK (The Confirmation)

  • You (Client): "Yes, I hear you perfectly (ACK 5001). Let's talk."

  • Technical: You ACK the server's number (5000 + 1). The connection is ESTABLISHED.

2. Data Transfer

Now the connection is open. We need to send the data.

But the internet is chaotic. Packets can arrive late, out of order, or duplicate.

TCP solves this using Sequence Numbers.

Think of it like moving houses. You don't just throw boxes into a truck. You label them: "Box 1 of 10", "Box 2 of 10".

  • The Sender: Sends "Packet #1 (Bytes 0-100)".

  • The Receiver: Gets it and sends back "ACK 101".

    • Translation: "I got everything up to 100. Send me byte 101 next."
  • The Sender: Sends "Packet #2 (Bytes 101-200)".

Ordering: If "Packet #3" arrives before "Packet #2", TCP holds it in a waiting room (Buffer). It waits for #2 to arrive, puts them in the right order (1 → 2 → 3), and then gives it to the application.

3. Handling Loss

What if a packet disappears?

  • Sender: "I sent Packet #2... waiting for confirmation..."

  • Receiver: (Silence)

  • Sender: "Okay, it's been 200ms. No ACK. It must be lost."

  • Action: The sender Retransmits Packet #2.

This is why TCP is "Reliable". It doesn't give up until the other side confirms receipt.

4. Closing the Connection

UDP just stops talking. But TCP is polite—it says goodbye properly.

This is a 4-Way Termination.

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

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

    • (The Server might still have some final data to send to you. You wait.)
  3. Server: "Okay, I'm done too. Bye." (FIN)

  4. You: "Bye." (ACK)

The connection is now closed.

Conclusion: The Unsung Hero

TCP is heavy. It has handshakes, acknowledgments, timers, and sequence numbers.

But this "heaviness" is exactly why you can load a webpage without missing words, or download a zip file without it being corrupted.

It works hard in the background so you don't have to.

We have built the road (Cables), found the address (DNS), and established a secure connection (TCP). The journey is complete. Now, we are standing at the server's front door. It's time to actually ask for the website.

In the final part of this series, we will stop using the browser and learn how to talk to the server manually using the command line tool cURL.

More from this blog

T

The Engineering Log

18 posts

Documenting the journey from bits to architecture. A technical archive exploring internals, engineering, infrastructure, and the systems that power modern software. Written by Mayur Badgujar.