TLS Handshake Latency: The Critical Path Tax Across Protocol Versions
The TLS Handshake Cost
The TLS handshake is one of the largest contributors to TTFB (Time To First Byte, the delay before the first byte of response arrives). Before any application data flows, client and server must exchange certificates and derive encryption keys. Traditional TCP with TLS 1.2 requires approximately 3 RTT (round-trip times) of handshake overhead: 1 RTT for TCP's SYN/SYN-ACK/ACK three-way handshake, then 2 RTT for the TLS handshake including certificate exchange and key derivation. On a mobile network with 80ms RTT, this translates to 240ms of pure handshake overhead before a single HTTP byte is transmitted.
TLS 1.3 Improvements
TLS 1.3 reduced handshake latency by condensing the cryptographic negotiation. The client sends its key share in the first message, allowing the server to derive the encryption key immediately and respond with encrypted data. This reduces the handshake to 2 RTT total (1 RTT TCP plus 1 RTT TLS), saving 80ms on that 80ms RTT connection. TLS 1.3 also introduced 0-RTT resumption (Zero Round Trip Time): when a client reconnects to a server it has visited before, it can include encrypted application data in the very first packet, effectively eliminating handshake latency for that request. The server stores enough state from the previous session to decrypt immediately.
Session Resumption at Scale
Session resumption (reusing cryptographic parameters from a previous connection) dramatically reduces handshake overhead at scale. Production deployments target resumption rates above 80%, meaning only 20% of connections pay full handshake cost. Large-scale operators achieve 82-88% resumption in practice. At millions of requests per second, reducing the full handshake rate from 30% to 15% saves hundreds of CPU cores because cryptographic operations (particularly RSA and ECDSA signatures) are computationally expensive. Session tickets (encrypted blobs containing session state that the client stores and presents on reconnection) are the mechanism enabling this, but require careful key rotation to maintain forward secrecy.
Edge TLS Termination
Edge TLS termination (decrypting TLS at a server geographically close to the user) removes long-distance RTT from the handshake path. If a client is 20ms from the nearest edge server but 100ms from the origin, terminating TLS at the edge saves 160-240ms on the handshake critical path (the difference between 2 RTT at 20ms vs 2 RTT at 100ms). This is why CDNs (Content Delivery Networks, globally distributed server networks) terminate TLS at the edge and maintain separate backend connections to origins. The edge-to-origin connection can use long-lived keepalives to amortize its handshake cost across many client requests.
0-RTT Security Considerations
0-RTT data carries replay risk: an attacker who captures the first packet can replay it to the server, potentially causing duplicate side effects. Servers must either implement replay detection (tracking recently seen tickets) or applications must only send idempotent requests (requests with no side effects, like GET) in 0-RTT early data. POST requests that create resources or modify state should never be sent as 0-RTT because replaying them could create duplicate orders, charges, or data. Clients indicate which requests are safe for 0-RTT, and servers can reject early data if they cannot guarantee replay protection.