"The TCP Three-Way Handshake and Latency: Why Pages Stay Slow Despite High Bandwidth"

A counterintuitive fact — upgrading your broadband from 100M to 500M may change nothing about how fast pages feel. What usually decides "fast or slow" is not bandwidth but round-trip latency (RTT) and the number of round trips.

The TCP Three-Way Handshake: The Ritual Before Every Connection

HTTP runs on top of TCP, and TCP establishes a connection through a fixed three-way handshake:

1. Client → server: SYN (I want to connect)
2. Server → client: SYN+ACK (Sure — you still there?)
3. Client → server: ACK (I am)

All three legs are indispensable, because TCP must confirm both sides can send and receive properly. Note one detail — the first data packet can only leave after the handshake completes, so merely establishing the connection already costs one RTT.

Add HTTPS and the Ritual Gets Longer

On top of the TCP handshake, HTTPS adds a TLS handshake. The older TLS 1.2 needs two more RTTs; modern TLS 1.3 compresses it to one, and session resumption can even reach 0-RTT.

So the minimum cost of opening an HTTPS site:

Phase	Cost
TCP handshake	1 × RTT
TLS 1.3 handshake	1 × RTT
Request + first response byte	1 × RTT

The first byte arrives only after three RTTs. A same-city site with RTT = 20ms responds in just over 60ms; a transcontinental site with RTT = 300ms burns nearly a second on handshakes alone — no amount of bandwidth can fix that, because the bottleneck is "number of round trips × waiting time per trip".

Why Bandwidth Cannot Rescue Latency

Bandwidth decides "how wide the pipe is" — how much data you can push per trip; latency decides "how long each round trip takes". They are orthogonal dimensions:

• 4K video — mostly bandwidth-hungry (sustained heavy traffic) and latency-insensitive (buffering ahead of time is enough)
• Browsing / API calls / gaming — mostly latency-bound (many small requests, each waiting for a round trip); 50M of bandwidth is already more than enough

A helpful analogy — bandwidth is the number of highway lanes, latency is your commute from home to the office. Widen the road from 4 lanes to 20 and your commute still takes 40 minutes.

Why CDNs Make Things Faster

A CDN's essence is shortening RTT — content is cached at nodes physically close to you, turning a 300ms transcontinental round trip into a 30ms local one, and the 3 × RTT for the three handshake legs plus first byte drops from 900ms to 90ms.

HTTP/2 and HTTP/3 help along another dimension — reducing the number of round trips:

• HTTP/2 — many requests run in parallel over one connection, with no separate handshake per resource
• HTTP/3 (QUIC) — replaces TCP with UDP-based QUIC, merging the transport and TLS handshakes for 0/1-RTT connection setup
• Keep-Alive — reuses established connections, eliminating every handshake for subsequent requests

Measure Your Real RTT

To see your actual round-trip latency to a target:

• Ping latency probe — measured from this site's servers (Singapore), well suited to judging datacenter route quality
• Speed test — reports download speed and latency together, so you can see the health of both dimensions at a glance

Note that ping's RTT is network-layer; the TTFB (time to first byte) you actually experience in a browser ≈ 3 × RTT + server processing time. For a site 300ms away, TTFB will struggle to come in under 1 second.

Summary

• An HTTPS connection needs at least 3 RTTs before the first byte arrives
• Bandwidth governs bulk transfer (video); latency governs interactive experience (pages, games)
• Faster means shorter RTT (CDN edge access) plus fewer handshakes (HTTP/3, connection reuse)
• To find the bottleneck, measure latency and bandwidth separately

What are your latency and bandwidth to a Singapore datacenter? Test them.