3

I would like to plan a system and I am asking myself how is it going to influence my performance if I am not going to implement TLS session resumption.

Does anyone measure how often is the use of TLS session resumption?
Is it browser dependent?

Does someone have a link of worldwide statistics regarding what's the overall session created by abbreviated handshakes (out of the overall TLS/SSL sessions)?

  • A web server can be configured to keep sessions alive or not, and how many to keep alive, and for how long. So, it depends on the sites you visit. A modern browser will use this, but also has limitations on numbers and times, often configurable. – Ned64 Sep 11 '15 at 8:50
  • @amigal: What server? – StackzOfZtuff Sep 11 '15 at 9:04
  • 1
    Related reading: High Performance Browser Networking, Ilya Grigorik, O'Reilly, 2013, Section "TLS Session Resumption" – StackzOfZtuff Sep 11 '15 at 9:10
  • Related reading: Also by that author: Good overview: istlsfastyet.com (Also mentions resumption.) – StackzOfZtuff Sep 11 '15 at 9:16
  • 2
    Related reading: Nice blog post. Includes benchmark numbers. Zi Lin, CloudFlare.com, 24 Feb 2015, TLS Session Resumption: Full-speed and Secure – StackzOfZtuff Sep 11 '15 at 9:21
5

Session resumption really depends on what you are pushing through the SSL. Since you talk about a Web browser, then I assume that you are talking about some sort of Web server, serving pages written in HTML.

How things go typically looks like this:

  • The browser opens a first connection, with a full handshake.
  • The browser may open one or a few extra connections, so that several requests may be issued concurrently (to load images and scripts and other elements). The number depends on the browser version, OS, HTTP protocol version, and maybe other parameters (see this for a summary of how these things went in 2008). The new connections will use session resumption.
  • The browser will try to keep the connections "alive" for as long as possible. Usually, the server will close connections which have been inactive for one or two minutes, but this depends on the server type, load, and configuration. Also, the client may be behind some NAT router that will kill connections that have been inactive for some time (typically 20 minutes or so).
  • When opening new connections, browser will try session resumption. A browser will remember session parameters for hours, as long as its process was not terminated (i.e. the browser forgets all session parameters when all its windows are closed).
  • The server will typically remember SSL sessions for 5 to 20 minutes after closure of the last connection that was using that session. This can be configured; it depends on the server type, version, configuration, and (notably) its use of session tickets.

The bottom-line is that a typical client will perform a new handshake only when it opens a new connection, which normally occurs rarely; you will get a few connections at the start, and then whenever the client interacts with your server after having not-interacted with the server for a minute or two. Under normal conditions and typical servers, only the very first of these handshakes is a full handshake; all others are abbreviated handshakes (session resumption). From the description above, you see that new connections occur at a rate which is no more than a couple of times per minute, and less so if the client is "active" (i.e. clicks more than once per minute).

By forfeiting session resumption, you make all the handshakes full, with server certificate sending and asymmetric cryptography.


The other half of the question is how much these extra full handshake will cost you. A full handshake implies mostly three extra costs:

  • The latency is increased. A full handshake implies an extra round trip:

    • Client sends ClientHello
    • Server sends ServerHello, Certificate...
    • Client sends ClientKeyExchange, ChangeCipherSpec, Finished
    • Server sends ChangeCipherSpec, Finished
    • Client can begin to send the HTTP request

    To compare with what happens with a session resumption:

    • Client sends ClientHello
    • Server sends ServerHello, ChangeCipherSpec, Finished
    • Client sends ChangeCipherSpec, Finished
    • Client begins its HTTP request (crucially, this can be done over the same IP packets as the ChangeCipherSpec and Finished messages)

    Whether the extra latency is tolerable or not should be measured. Latency is usually what matters most for user experience.

  • The full handshake implies more network traffic, the bulk of which being the server's certificate chain (say, 2 to 5 kilobytes).

  • The asymmetric crypto involved in a full handshake requires a bit more juice from the server CPU. Note that a quad-core 3.1 GHz server from a few years ago (that's my server) can do more than 3000 RSA private key operations per second (for a very decent 2048-bit key).

Since we are talking about a couple handshakes per minute and per client, the extra network and CPU costs are probably negligible (although it should be measured, like all things related to performance). The extra latency, though, may be more problematic, because it is part of what the user sees, and it depends on how the user is connected to the Internet (in particular, people with satellite Internet access tend to have a high latency and dearly feel the cost of each extra round trip).


Summary: for a Web site, the influence of using or not using session resumption will mostly be a question of user experience with regards to latency. The most important parameter will be how long the server accepts to keep inactive client connections alive.

Since all of this depends a lot on how your site is organized (e.g. number of extra images, CSS and scripts to load; whether interactions are mostly in the client with Javascript, or imply client-server activity; how long a user is expected to stare at a page before clicking anywhere...), how the users behave (how many pages they look at, how often they come back...), and the expected peak load (how many users connected at the same time), statistics obtained on sites other than your own are unlikely to offer an accurate vision of what will happen for you.

  • at least one more roundtrip. IME server cert chain (plus smaller bits: ServerHello, stapled Status when used, ServerKeyX when used, CertReq when used, HelloDone) is usually larger than TCP's initial congestion window and waits for a TCP ACK to send completely, sometimes more than one. And if stapling isn't used, client often needs CRL or OCSP fetches with their own latencies. – dave_thompson_085 Sep 12 '15 at 14:43
  • Note that in case of repeated full handshakes with the same server, one may expect the client to locally cache the CRL and OCSP responses and reuse them -- both kind of objects have an explicit lifetime which is typically of a few hours or more. – Tom Leek Sep 12 '15 at 17:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.