Why resumption matters
A full TLS handshake costs round trips and expensive public key operations. When a client reconnects to a server it has talked to recently, session resumption lets both sides reuse previously negotiated secrets, cutting latency and CPU cost.
Two mechanisms
- Session IDs have the server store the session state and hand the client a short identifier. On return the client presents the ID and the server looks up the cached secrets. This requires server side memory.
- Session tickets push the state to the client instead. The server encrypts the session state with a key only it knows and gives the client the resulting ticket. On return the client sends the ticket back and the server decrypts it, holding no per client memory.
In the current TLS version, resumption uses a pre shared key derived from the prior session, and tickets enable zero round trip early data, where the client sends application data in its first flight. That speed comes with a replay risk, since early data can be captured and replayed, so servers restrict it to idempotent requests.
Key idea
Session IDs and session tickets reuse prior TLS secrets to skip the expensive handshake, with tickets keeping the state on the client instead of the server.