TLS Handshake Performance: RTT Impact and Termination Strategies

Handshake Latency and RTT Impact
The TLS handshake represents a significant portion of connection establishment latency because it requires multiple round trips before any application data can flow. RTT (Round Trip Time) is the time for a packet to travel from client to server and back. A cold TLS 1.2 connection requires 3 total RTTs: 1 for the TCP three way handshake plus 2 for TLS negotiation. For a user in Asia connecting to a US server with 200 to 250ms RTT, this translates to 600 to 750ms just for connection setup before any content loads.
TLS 1.3 reduces the TLS portion to 1 RTT (2 RTTs total), saving 200 to 250ms on intercontinental connections. QUIC (the transport protocol underlying HTTP/3) integrates transport and cryptography layers to achieve 1 RTT handshakes from cold start and supports 0-RTT resumption for returning clients. HTTP/3 adoption means users on supporting browsers can benefit from QUIC automatically when servers enable it.
Edge Termination Strategy
Terminating TLS as close to users as possible is a fundamental performance optimization. CDNs (Content Delivery Networks, globally distributed servers that cache and serve content) and cloud providers deploy edge locations in major cities worldwide. When TLS terminates at an edge location near the user instead of at a distant origin server, the handshake RTT drops from hundreds of milliseconds to tens of milliseconds. A user in Mumbai connecting to an origin in US East with 250ms RTT saves 150 to 200ms per connection when TLS terminates locally at 20 to 40ms RTT.
Edge termination also offloads cryptographic computation from origin servers. However, this creates a trust boundary: the connection between edge and origin must be secured separately. Options include hop by hop TLS (the edge establishes a new TLS connection to the origin) or maintaining the original encrypted connection through the edge (TLS passthrough). Service mesh architectures often use mTLS (mutual TLS, where both client and server present certificates) for internal traffic.
Session Resumption
Session resumption allows returning clients to skip the expensive full handshake by reusing previously negotiated parameters. Session tickets are encrypted blobs containing session state that the server issues to clients after a successful handshake. On subsequent connections, the client presents the ticket, and if the server can decrypt it, both sides skip key exchange and resume with a abbreviated handshake. Production systems target above 80 percent resumption rates, meaning 4 of 5 returning connections avoid full handshakes.
Full handshakes consume 5 to 10x more CPU than resumed sessions due to expensive asymmetric cryptography operations (ECDHE key generation and signature verification). If resumption rates fall below 50 percent, CPU costs spike dramatically. Low resumption often indicates session ticket keys not synchronized across load balanced servers: when a user returns but hits a different server that cannot decrypt their ticket, resumption fails and triggers a full handshake.

💡 Key Takeaways

✓TLS 1.2 requires 3 RTTs total (1 TCP + 2 TLS); TLS 1.3 reduces to 2 RTTs; QUIC achieves 1 RTT cold start with 0-RTT resumption for returning clients

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

✓CDNs (Content Delivery Networks) distribute edge locations globally to terminate TLS close to users, reducing latency and offloading crypto from origins

✓Session resumption above 80 percent is a production target; full handshakes consume 5 to 10x more CPU than resumed sessions due to asymmetric crypto operations

✓Session ticket keys must be synchronized across all load balanced servers; failure to sync causes resumption misses when users return to different servers

✓mTLS (mutual TLS) secures edge to origin connections by requiring both parties to present certificates, used in service mesh architectures

📌 Interview Tips

1Explain the latency math: 3 RTTs at 200ms each equals 600ms connection setup with TLS 1.2, versus 400ms with TLS 1.3, versus 200ms with QUIC

2Discuss edge termination trade off: faster handshakes but creates trust boundary requiring secured edge to origin path

3Mention resumption as critical metric: dropping from 80 percent to 20 percent increases handshake CPU cost by roughly 4x

← Back to TLS/SSL & Encryption Overview