TLS Handshake Performance: RTT Impact and Termination Strategies

The TLS handshake represents a significant portion of connection establishment latency, and its impact scales linearly with round trip time between client and server. A cold TLS 1.2 connection requires approximately 3 total RTTs (1 for TCP three way handshake plus 2 for TLS negotiation) before any application data flows. For a user in India connecting to a US East origin with 200 to 250 ms RTT, this translates to 600 to 750 ms just for connection setup. TLS 1.3 reduces the TLS portion to 1 RTT, saving 200 to 250 ms in this scenario. QUIC (the transport underlying HTTP/3) integrates transport and crypto layers to achieve 1 RTT handshakes from cold start and enables zero RTT resumption for returning clients, potentially eliminating all handshake overhead.

Terminating TLS as close to users as possible is a fundamental performance optimization deployed by all major content delivery networks and cloud providers. When Amazon terminates TLS at an edge location in Mumbai for that same Indian user, the handshake RTT drops from 200 to 250 ms to perhaps 20 to 40 ms locally, removing 150 to 200 ms of setup latency. This edge termination also offloads cryptographic computation from origin servers, allowing them to scale more efficiently. However, this creates a trust boundary: the path from edge to origin must be secured separately, often using hop by hop TLS or mutual TLS with workload identity systems for internal service meshes.

Session resumption is the other critical performance lever at scale. Production CDNs and large services target resumption rates above 80 percent, meaning four out of five returning connections skip the full handshake and resume with just session ticket validation. Without proper ticket key sharing across edge nodes or geographic points of presence, users who return but hit a different edge location cannot resume, and resumption rates can fall below 10 percent. This dramatically increases both CPU cost (full handshakes are 5 to 10 times more expensive than resumptions) and user perceived latency. Achieving high resumption requires secure, synchronized distribution of session ticket encryption keys across all edge locations with rotation intervals measured in hours to maintain forward secrecy.

💡 Key Takeaways

•Handshake latency scales linearly with RTT: 3 RTTs for TLS 1.2 means 600 to 750 ms on a 200 to 250 ms path, reduced to 400 to 500 ms with TLS 1.3, and potentially 200 to 250 ms with QUIC plus zero RTT

•Edge TLS termination reduces handshake RTT from hundreds of milliseconds (origin distance) to tens of milliseconds (edge distance), saving 150 to 200 ms for intercontinental connections

•Session resumption above 80 percent is a production target; falling to 10 percent resumption increases handshake CPU cost by 5 to 8x and adds full RTT overhead for every returning user

•Session ticket keys must rotate every few hours to 1 day for forward secrecy while being synchronized across all edge nodes; failure to sync causes resumption misses and latency spikes

•Full handshakes consume 5 to 10 times more CPU than resumed sessions due to asymmetric crypto operations (ECDHE key generation and signature verification)

📌 Examples

AWS terminates TLS at CloudFront edge locations globally, reducing handshake latency from origin distance (200+ ms) to edge distance (20 to 50 ms) for most users

A CDN serving 100,000 requests per second with 20 percent resumption rate performs 80,000 full handshakes per second; increasing resumption to 80 percent drops this to 20,000, reducing CPU cost by 75 percent

Google deployed TLS 1.3 and QUIC across YouTube, reducing time to first frame by approximately 100 ms on mobile networks by eliminating handshake round trips

← Back to TLS/SSL & Encryption Overview