TCP 3-Way Handshake: How Connections Are Established

By Rahul — Google Frontend Engineer

Why Frontend Engineers Should Care

Every HTTP request starts with a TCP handshake. It adds latency to every new connection. Understanding it helps you appreciate why HTTP/2 multiplexing, connection pooling, and preconnect matter.

The Three Steps

Step 1: SYN (Client → Server)

Client sends a SYN (synchronize) packet with a random sequence number. "Hey, I want to talk. My starting number is X."

Step 2: SYN-ACK (Server → Client)

Server responds with SYN-ACK: its own random sequence number AND acknowledges the client's number. "Got it. My starting number is Y. I acknowledge your X."

Step 3: ACK (Client → Server)

Client acknowledges the server's number. "Got your Y. Let's go." Now both sides have agreed on sequence numbers and data can flow.

Client                    Server
  |                         |
  |------- SYN (seq=X) ---->|     1 RTT
  |                         |
  |<--- SYN-ACK (seq=Y, ----|
  |      ack=X+1)           |     
  |                         |
  |------- ACK (ack=Y+1) -->|     1.5 RTT
  |                         |
  |=== Connection Ready ====|

Why Three Steps? Why Not Two?

Two steps would not confirm that the client received the server's sequence number. The third step proves both sides can send AND receive. Without it, the server could allocate resources for a connection the client never completes — this is actually how SYN flood attacks work.

SYN Flood Attack

Attacker sends thousands of SYN packets but never sends the ACK. The server keeps half-open connections, consuming memory until it cannot accept legitimate connections.

// Mitigation: SYN cookies
// Server encodes connection state in the sequence number
// No memory allocated until the 3rd step completes

Connection Termination: 4-Way Handshake

Client                    Server
  |--- FIN ----------------->|  "I am done sending"
  |<-- ACK ------------------|  "Got it"
  |<-- FIN ------------------|  "I am done too"
  |--- ACK ----------------->|  "Got it, goodbye"

Four steps because each side independently closes their sending channel.

Impact on Web Performance

• Each new TCP connection = 1 RTT overhead minimum
• With TLS: add another 1-2 RTTs
• On mobile (100ms RTT): a new HTTPS connection costs 200-300ms before data flows
• HTTP/2 uses a single TCP connection, amortizing the handshake cost
• HTTP/3 (QUIC) combines TCP + TLS handshake into 1 RTT total

What You Can Do

<!-- Preconnect to critical origins -->
<link rel="preconnect" href="https://api.example.com" />

<!-- This does DNS + TCP + TLS before you need the connection -->

Summary

The TCP 3-way handshake (SYN → SYN-ACK → ACK) establishes reliable connections. It costs 1 RTT of latency. HTTP/2 amortizes this with multiplexing, HTTP/3 reduces it further. Use preconnect to hide this latency.