5 ms·
What are the performance characteristics of HTTPS/TLS as compared to plain HTTP these days? (Serious question, I don't know.) You gloss over the overhead, but
by T-hawk 10y ago
What are the performance characteristics of HTTPS/TLS as compared to plain HTTP these days? (Serious question, I don't know.) You gloss over the overhead, but that may not be insignificant.
Every millisecond of latency counts for user engagement and bounce rate. Every round trip in the handshake hurts measurably. Particularly on slow cellular network connections, of course. It's quite possible that web sites exist where the performance penalty for TLS is worse for the business than simply running unsecured.
And anything with an ad network (or even other resources like web fonts) runs into the mixed-content problem. If the page is served over HTTPS, then so must every other asset be, or else the browser throws up warnings. And then you're dependent on every partner asset on the page to keep its own TLS certificates valid, or else you get browser warnings again and lose some amount of user engagement.
Security always has costs and tradeoffs.
- hannob 10y agoThe overhead is so small that it's basically irrelevant if you are not youtube or netflix. If you have a performance problem with https then either you have a flaw in your software or some serious configuration mistake. In practice in many situations you can even get better performance with HTTPS, because many modern features (for performance notably HTTP/2 and Brotli) aren't available over plain HTTP.
- umanwizard 10y agoI worked for junglee.com (a relatively unknown site owned by Amazon that used very little CPU) and extra latency on HTTPS was a massive, serious issue. What flaw in our software or serious configuration mistake do you think we had?
- hannob 10y agoBased on the current configuration: No OCSP stapling and no elliptic curve key exchange. Also your setup suffers from TLS version intolerance, which by itself isn't a performance issue, but it is a hint that you're using a badly written TLS stack. https://www.ssllabs.com/ssltest/analyze.html?d=junglee.com&s=178.236.6.99&latest https://www.ssllabs.com/ssltest/analyze.html?d=junglee.com&s...
- umanwizard 10y agoAnd how much do those increase first byte latency? (which is the real problem)
- konklone 10y agoTough to say without knowing more about the stack. But in terms of first byte latency, some things you can look at: * TLS False Start * HTTP/2 + ALPN * Optimizing TLS record size Some 2013-era advice for nginx here: https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-to-first-byte/ https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-... And some other advice and links here: https://istlsfastyet.com/ https://istlsfastyet.com/
- hannob 10y agoPretty much all of them matter for first byte latency. OCSP & the key exchange both happen before any data can be exchanged.
- jlgaddis 10y agoYep, Netflix even switched to 100% HTTPS for video streams (and the sky didn't fall) [0]. [0]: http://techblog.netflix.com/2016/08/protecting-netflix-viewing-privacy-at.html http://techblog.netflix.com/2016/08/protecting-netflix-viewi...
- umanwizard 10y agoNetflix has performance needs that are not representative of every site in the world. For example, first-byte latency probably doesn't matter much for them.
- vitus 10y agoYoutube uses QUIC for most of its comms (to Chrome and to the Android YT player; possibly to the iOS one too, I don't remember), which does implement TLS with 0-1 RTTs for connection setup (practically speaking, no additional delay). And IIRC, encryption overhead is pretty insignificant if you have a CPU with AES instructions, which is to say, pretty much anything from the past 5+ years.
- majewsky 10y ago> pretty much anything from the past 5+ years With a cave-at: Intel's low-cost CPUs didn't include AES-NI until pretty recently. Which is why, in 2014, I went for a cheap Athlon instead of a Celeron for my custom-built homeserver with full-disk encryption.
- tyingq 10y agoHTTP/2 significantly reduces the issue of repeated handshakes. See: https://www.httpvshttps.com/ https://www.httpvshttps.com/ Obviously, that site is picking a specific case to make a point, but the point is significant.
- notatoad 10y ago"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that." https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...
- umanwizard 10y agoThis is only server-side CPU. What about client-side latency? TLS involves extra hops to establish a connection.
- snuxoll 10y agoThe overhead can be minimized on subsequent connections if you pin a client to one server handling TLS termination for the session (you can either pin to one application server, or a specific load balancer) and your servers have enough memory to keep an adequate number of sessions in memory. You probably take up roughly 10KB of memory per TLS session that's active, so 100 active sessions per 1MB or so which isn't too bad.
- umanwizard 10y ago> subsequent connections What if most of your users are first-time visitors coming from google results?
- snuxoll 10y agoYou take an extra hit the first time a TLS session key is established, after that all subsequent HTTP requests can do a fast resume. This has nothing to do with users over a period of time.
- dstaten 10y agoThe existence of the request itself (for the handshake) is most of the cost. If a client is on the other side of the world, hundreds of ms. Otherwise if you have servers everywhere, still probably 50-70ms for the handshake. Edit: in my experience.
- maxt 10y ago"TLS has exactly one performance problem: it is not used widely enough" https://istlsfastyet.com/ https://istlsfastyet.com/
- umanwizard 10y agoDownvoted. The information in that site doesn't actually back up the headline. It handwaves away the extra-round-trip issue with "well, there are experimental ways in the works to eliminate one of those extra round trips" which is worlds away from saying there are "no performance problems" with TLS in practice.