TCP and TLS Handshakes

The Cost of Saying Hello

After DNS gives your browser an IP address, you might think data starts flowing immediately. It doesn't. Before a single byte of your HTML can travel across the wire, your browser and the server need to have two separate conversations — one to establish a reliable connection (TCP), and another to encrypt it (TLS).

These conversations are called handshakes, and they cost you real time. A TCP handshake is 1 round trip. A TLS 1.2 handshake adds 2 more. That's 3 round trips before any data moves. At 50ms per round trip, you just burned 150ms staring at a blank screen.

TLS 1.3 changed the game. But to appreciate why, you need to understand what came before.

The Mental Model

TCP: The Three-Way Handshake

TCP (Transmission Control Protocol) provides reliable, ordered delivery of data. Unlike UDP, which is fire-and-forget, TCP guarantees that every byte arrives in order and retransmits anything that gets lost.

But reliability has a cost: the three-way handshake.

This takes exactly 1 RTT (round-trip time). The client sends SYN, waits for SYN-ACK, then sends ACK. The ACK packet can carry the first data payload (the HTTP request), so the actual overhead is 1 RTT.

Why Not Just Start Sending Data?

The three-way handshake exists to:

1. Verify both parties are alive — the server confirms it can receive, the client confirms it can receive
2. Synchronize sequence numbers — both sides agree on numbering so packets can be reordered if they arrive out of sequence
3. Prevent ghost connections — without SYN-ACK, old duplicate packets could open fake connections (called SYN flood attacks exploit this)

TLS: Encrypting the Connection

Once TCP is established, HTTPS sites add another handshake layer: TLS (Transport Layer Security). This negotiates encryption so nobody between your browser and the server can read or tamper with the data.

TLS 1.2: The Two-Round-Trip Handshake

TLS 1.2 was the standard for over a decade. Its handshake works like this:

That's 2 additional RTTs on top of TCP's 1 RTT. For a new HTTPS connection with TLS 1.2:

TCP handshake:   1 RTT
TLS 1.2:         2 RTTs
─────────────────────────
Total:           3 RTTs before data

At 100ms RTT (typical for cross-continent), that's 300ms of handshaking before a single byte of HTML arrives.

TLS 1.3: The One-Round-Trip Revolution

TLS 1.3 (finalized in 2018, RFC 8446) made a fundamental change: the client sends its key share in the very first message, alongside the ClientHello. The server can compute the shared secret immediately and start sending encrypted data back in the first response.

1 RTT for TLS 1.3 vs 2 RTTs for TLS 1.2. For a new HTTPS connection:

TCP handshake:   1 RTT
TLS 1.3:         1 RTT
─────────────────────────
Total:           2 RTTs before data

That's saving 100ms at 100ms RTT — a massive win for every new HTTPS connection.

0-RTT Resumption: The Speed Cheat Code

TLS 1.3 has one more trick: if you've connected to a server before, you can resume with zero additional round trips. The previous session generates a PSK (Pre-Shared Key) that both sides remember. On reconnection, the client sends the PSK and encrypted application data in the very first packet.

Returning visitor with 0-RTT:
TCP handshake:   1 RTT
TLS 1.3 0-RTT:  0 RTTs  (data sent with ClientHello)
─────────────────────────
Total:           1 RTT before data

TCP Slow Start: Why New Connections Are Slow

Even after the handshakes complete, TCP doesn't let data flow at full speed immediately. It uses an algorithm called slow start to probe for available bandwidth.

Here's how it works: TCP starts with a small congestion window (typically 10 TCP segments, about 14KB). For each acknowledged segment, the window grows. It roughly doubles every round trip:

RTT 1:   14 KB (10 segments)
RTT 2:   28 KB
RTT 3:   56 KB
RTT 4:  112 KB
RTT 5:  224 KB
...continues until packet loss occurs

This means your first 14KB of HTML arrives after 1 RTT of data transfer, but delivering 100KB requires several round trips as the window grows.

This is why the first 14KB of your HTML matters so much. If your critical CSS and initial HTML fit within 14KB (compressed), they arrive in the first data round trip. If they exceed 14KB, you're waiting for slow start to ramp up.

Congestion Control: What Happens When the Pipe Is Full

Slow start keeps doubling the congestion window until one of two things happens:

1. Packet loss is detected — the window drops dramatically (TCP Reno halves it, TCP CUBIC uses a cubic function to recover)
2. The slow start threshold is reached — growth switches from exponential to linear (congestion avoidance mode)

Modern operating systems use TCP CUBIC (Linux default) or TCP BBR (Google's algorithm). BBR is notable because it doesn't wait for packet loss to detect congestion — it measures RTT and bandwidth to find the optimal sending rate. Google reported 2-25% throughput improvements when they deployed BBR on YouTube.

Connection Reuse: Avoiding Handshake Costs

Since handshakes are expensive, reusing connections is critical:

• HTTP/1.1 Keep-Alive — connections stay open for multiple requests (default behavior)
• HTTP/2 multiplexing — a single connection carries all requests to an origin
• HTTP/3 — uses QUIC, which has its own connection migration (survives network changes)
• preconnect — completes TCP + TLS before resources are needed

<!-- Complete DNS + TCP + TLS for critical origins early -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

The single most impactful thing you can do for connection performance is reduce the number of unique origins your page depends on. Each new origin means a new TCP + TLS handshake.

Common Mistakes

Key Takeaways