Reference guide · dns-ssl · Published 2026-08-16 · 4 min read
TLS session resumption and the handshake cost
TLS session resumption explained, tickets and session IDs, and how resumption reduces TLS handshake latency on repeat connections.
- ·Why handshakes repeat
- ·Tickets and caching
- ·Making sessions stick
A full TLS handshake needs several round trips and a couple of cryptographic operations before the first byte of a page can flow. For a single request that cost is tiny, but a page may open many secure connections, and every revisit repeats the handshake unless the connection is reused or the session resumes. TLS session resumption lets a client that already negotiated a session skip most of that work on the next connection, using a session ID cached server-side or a session ticket handed to the client. It is one of the quieter levers behind HTTPS being fast rather than only secure.
Why handshakes repeat
HTTP/1.1 can reuse one connection, but a browser still opens several connections for a page (main document, plus origins it can parallelise). HTTP/2 multiplexes many requests over one connection, which helps, but a fresh connection still needs a handshake. Every time a client and server reconnect, doing a full handshake again costs the same round trips. Resumption exists to amortise that.
The two mechanisms differ in where the state lives:
| Mechanism | Where state lives | Note |
|---|---|---|
| Session ID | Server-side cache keyed by ID | The client offers an ID it saw before |
| Session ticket | Client-side encrypted ticket | The ticket is presented to resume |
| 0-RTT (TLS 1.3) | Client ticket with early data | Resumes and may send data immediately |
The TLS 1.3 handshake article covers how the newer protocol reshaped the handshake itself; resumption is complementary to that and available across versions.
Tickets and session caching
The cleanest modern form is the stateless session ticket. When the client finishes a handshake, the server hands it a signed, encrypted ticket that encodes the session. On the next connection the client offers that ticket, and the server validates it and resumes, without the server needing to keep a table of every session. This scales across a fleet because any server that can validate the ticket can resume it, which is why ticket-based resumption suits load-balanced and CDN setups.
Session ID caching keeps state in the server's memory, indexed by a short ID the client offers back. It works well on a single server, but the cached state must travel with the request in a cluster, which makes it the less portable option. Tickets move the burden to the client and the key.
A note on TLS 1.3 0-RTT
TLS 1.3 introduced 0-RTT (zero round trip) resumption, in which a returning client can send encrypted application data (such as an HTTP request) in the same flight as its ticket, removing one round trip entirely. That speed comes with a replay risk: an attacker who captures a 0-RTT message could send it again, so 0-RTT is meant for idempotent, non-mutating requests, not for writes or anything that must happen exactly once. Deployment therefore weighs the latency win against what the request does.
Making sessions stick
From a server side, session resumption is largely tuning:
- Set a sane session or ticket lifetime so resumes help your real repeat traffic without holding state forever; hours to a day is typical, and TLS 1.3 allows shorter bounds.
- Rotate the ticket-keying material on some cadence so a compromised key does not expose a whole cluster's sessions, and accept that rotation invalidates existing tickets.
- Keep server clocks correct: ticket validation and resumption depend on time, and clock skew breaks the exchange, a symptom that also figures in certificate errors (see SSL errors).
None of this changes the security model of HTTPS; resumption only reuses an already-validated session. The ALPN and HTTP/2 article shows the neighbouring negotiation that improves HTTPS latency, and HTTP/3 reduces handshake cost at the transport layer. Put together, session resumption, HTTP/2 and quick handshakes are why a modern HTTPS page no longer feels slower than HTTP.