Nagesh K

When you type a URL like https://youtube.com into Chrome, a fascinating sequence of events unfolds behind the scenes. Let’s break it down step by step.

🔑 Step 1: Chrome Asks the OS to Connect

  • Chrome tells the operating system: “I want to connect to YouTube on port 443.”
  • The OS assigns a temporary source port (e.g., 52341) and sets the destination port (443 for HTTPS).

🤝 Step 2: The Three‑Way Handshake

Laptop → SYN → YouTube
👉 Client requests to establish a TCP connection.

YouTube → SYN + ACK → Laptop
👉 Server acknowledges the request and agrees to establish the connection.

Laptop → ACK → YouTube
👉 Client acknowledges the server’s response.

✅ TCP connection is now established!

📩 Step 3: Application Data Begins

Now Chrome can send the actual HTTP request:

GET / HTTP/1.1
Host: youtube.com

Enter fullscreen mode Exit fullscreen mode

This is the first packet of application data.

  • Laptop → Packet 1 → YouTube
  • YouTube → ACK → Laptop

ACK means: “I received Packet 1 successfully.”

🔄 Step 4: Continuous Data Transfer

The process repeats:

  • Packet 2 → ACK
  • Packet 3 → ACK
  • Packet 4 → ACK

This continues until all data is exchanged.

🧩 Step 5: Important Distinction

  • Handshake ACK happens once (to establish the connection).
  • Data ACKs happen for every packet of application data.

These serve different purposes: one ensures readiness, the other ensures reliability.

✅ Answering Key Questions

  1. After the handshake, where does ACK happen?

    → Right after data transfer begins, for each packet.

  2. Does TCP send application data immediately after the handshake?

    → Yes! Once the handshake is complete, Chrome sends the HTTP request, and YouTube responds with the webpage or video data.

🏦 Analogy: Visiting a Bank

  • Handshake: You: Hello. Employee: Hello. You: Can I talk to you? Employee: Yes.

No banking work yet — just establishing readiness.

  • Application Data: You: I want to transfer ₹1,00,000. Employee: Transaction accepted.

Now the real communication begins.

🚀 One More Thing: Sliding Window

In our simplified model, it looks like TCP waits for each ACK before sending the next packet.

But in reality, modern TCP uses a sliding window:

  • Multiple packets can be sent before ACKs arrive.
  • This improves speed while still ensuring reliability.

Advanced TCP concepts include:

  • Sequence Numbers
  • Sliding Window
  • Flow Control
  • Congestion Control

The sequence is actually:

Step 1: Chrome asks the OS to connect.
↓
Step 2: TCP Three-Way Handshake.
↓
Step 3: Connection Established.
↓
Step 4: Laptop sends HTTP GET request

→ This is application data being sent from client to server.

Step 5: Server sends ACK

→ This ACK means: “I received your GET request successfully.”

It’s not yet the response data — just confirmation that the request packet arrived intact.

Step 6: Server processes the GET request

→ The server now interprets the request (e.g., fetches the YouTube homepage or video stream).

Step 7: Server sends the requested data (HTML, video, etc.)

→ This is the actual payload (application data) being delivered.

Step 8: Laptop sends ACK

→ This ACK means: “I received your response data successfully.”

It confirms delivery of the server’s packets.

🎯 Takeaway

TCP ensures that data travels reliably across the internet.

  • Handshake establishes the connection.
  • ACKs guarantee delivery.
  • Sliding window keeps performance high.

Next time you stream a YouTube video, remember — every frame is backed by this invisible dance of packets and acknowledgments.