The common belief is that encryption is expensive. It has not been for a long time — modern processors handle symmetric encryption at a rate where it is effectively free relative to everything else a request does. What costs is establishing the connection, and specifically the round trips required before any application data can flow.
On a fast local network that is a few milliseconds. On a mobile connection to a distant server it can be a substantial fraction of the total response time.
What changed in 2026
- QUIC adoption made setup cheaper. Folding the cryptographic handshake into transport establishment reduced round trips before data flows, as covered in HTTP/3 adoption.
- Connection reuse improved in clients. Better default keep-alive behaviour in HTTP clients meant fewer applications paying handshake cost repeatedly.
- Post-quantum key exchange rolled out. Hybrid key exchange increased handshake message sizes somewhat, which mattered mainly on constrained networks.
- Resumption support broadened. Session resumption became reliably available across the stack rather than something to verify carefully.
Where the cost is
| Scenario |
Round trips before data |
Relative cost |
| Reused warm connection |
None |
Free |
| Session resumption |
Reduced |
Low |
| Full handshake over TCP |
Several |
Noticeable |
| Full handshake with an unnecessary redirect |
More |
Worse |
| Handshake on a high-latency mobile link |
Same count, longer each |
Highest |
The pattern is that round trip count multiplied by network latency is the whole story. A handshake costing three round trips is fifteen milliseconds on a fast connection and hundreds on a poor mobile link. Reducing round trips is what helps; making encryption faster is not.
Avoiding the cost
Reuse connections. A connection kept alive and reused pays no handshake at all. Most HTTP clients support this and some default to it poorly — creating a new client per request, a surprisingly common bug, means a new handshake every time and it is worth auditing for specifically.
Enable session resumption. When a new connection is genuinely needed, resumption uses previously established parameters to shorten the handshake. This requires configuration on both ends and is usually a matter of confirming rather than implementing.
Reduce redirects. A redirect from an unsecured to a secured origin, or between hostnames, can mean an additional connection and an additional handshake. Preloading and consistent canonical hostnames avoid it.
Consider zero-round-trip resumption carefully. It allows data on the first message of a resumed connection, eliminating a round trip, at the cost of replay protection for that data. Appropriate for idempotent requests, not for state changes.
Adopt QUIC where it helps. Its combined transport and cryptographic setup reduces round trips before data flows, which matters most on exactly the high-latency connections where handshakes hurt.
For service-to-service traffic, mutual authentication adds certificate exchange in both directions, which makes connection reuse considerably more valuable — see mTLS in a service mesh.
Common mistakes
- A new HTTP client per request. New handshake every time; a common and invisible bug.
- Optimizing cipher selection for CPU. Not where the cost is.
- Unnecessary redirects. Each may add a connection.
- Zero-round-trip resumption on state-changing requests. Replay risk.
- Testing only on a fast network. The cost is invisible there and dominant elsewhere.
- Short keep-alive timeouts. Forces reconnection during normal traffic patterns.
FAQ
Does the encryption itself cost anything measurable?
Very little on modern hardware with hardware acceleration. The cost is connection establishment.
How long should keep-alive be?
Long enough to cover the gap between a client's typical requests, short enough not to hold idle connections indefinitely. Both ends matter; the shorter wins.
Does post-quantum key exchange make handshakes slower?
It increases message sizes, which can add a round trip on constrained links. The effect is modest for most connections.
Is connection pooling the same as keep-alive?
Related. Keep-alive keeps a connection open; pooling manages a set of them for reuse — see connection pooling explained.
Where to go next
For the transport change, read HTTP/3 adoption. For service-to-service encryption, mTLS in a service mesh, and for timeout settings around connections, connection timeout tuning.