6 ms·
Optimizing HTTPS performance
- smackfu 11y agoIf I go to a site called IsTLSFastYet.com, I expect a huge bit of text that says "yes" or "no". Otherwise why use that format?
- piyushco 11y agothanks for sharing. useful.
- mattiemass 11y agoLove stuff like this. There's so much momentum around TLS lately, so great to see.
- nickpsecurity 11y agoGood points. The author focuses on (a) have server do everything itself or (b) use SSL accelerator hardware. There's a middle ground which has other benefits depending on your use-case: I/O offloading hardware that also handles SSL. These are often PCI networking cards that handle the packet processing, firewall, IDS, maybe management, SSL/VPN, etc. The host CPU works at a high level where it's only interrupted upon significant events or with most work done. The load on an I/O-bound server is so small that cheap, embedded CPU's can handle it. A CPU-bound server gets a great boost in performance for not worrying about massive I/O load. So, there's still potential with that model. Use host CPU if that's all you need, though. Just remember that a few $200-300 networking cards might be a better deal than whatever HSM vendors charge these days.
- Ono-Sendai 11y agoI'm currently adding https (TLS) support to my blog, using LibTLS (part of LibreSSL). My initial impressions are that TLS handshake is very computationally expensive. Stress testing my webserver with plain HTTP connections: 7980.2744 queries/s With HTTPS (TLS) connections: 23.059916 queries/s The slowdown is due to high CPU usage. I certainly wouldn't classify that as fast! I've only done a bit of work on this so it's possible I'm misusing the LibTLS API however.
- detaro 11y agoThe site and the linked resources talk about handshakes: only a small percentage of your traffic should actually require a full handshake, since most of your users are going to request multiple files. Basic benchmarks don't do that and therefore provoke a worst-case you are unlikely to see in real usage. Might be relevant for APIs, ad servers or similar though.
- Zr40 11y agoHow did you measure this? When measuring on one of my servers that exposes both HTTP and HTTPS, there doesn't appear to be any significant difference. HTTP: % wrk http://hostname Running 10s test @ http://hostname 2 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 5.11ms 5.42ms 62.85ms 96.08% Req/Sec 1.10k 224.03 1.31k 87.04% 17703 requests in 10.01s, 6.89MB read Requests/sec: 1768.57 Transfer/sec: 704.58KB HTTPS: % wrk https://hostname Running 10s test @ https://hostname 2 threads and 10 connections Thread Stats Avg Stdev Max +/- Stdev Latency 4.75ms 4.09ms 50.37ms 96.48% Req/Sec 1.10k 228.86 1.34k 79.35% 17014 requests in 10.01s, 8.39MB read Requests/sec: 1700.32 Transfer/sec: 858.38KB
- Ono-Sendai 11y agoI tested it with some of my own code, 8 threads making requests to my server at localhost. Does this program 'wrk' re-establish a connection for each request, or is it re-using them?
- Zr40 11y agowrk[1] does appear to reuse a connection for each request. [1] https://github.com/wg/wrk https://github.com/wg/wrk
- hirsin 11y agoAny idea how HTTPS manages to have a significantly higher throughput? At first blush this doesn't quite pass the sniff test - it looks like there's another factor in play here.
- raimue 11y agoThey probably need to automate the "upgrade to latest" box, current version would be OpenSSL 1.0.2f 28 Jan 2016. Anyway, I am not convinced the `openssl speed` benchmark output conveys anything to the people addressed by the site.
- jsingleton 11y agoYou could always fix it and submit a pull request. Then automate that. https://github.com/igrigorik/istlsfastyet.com/pulls https://github.com/igrigorik/istlsfastyet.com/pulls
- raimue 11y agoThanks for the hint, I did not realize it was on GitHub. Pull request sent. https://github.com/igrigorik/istlsfastyet.com/pull/97 https://github.com/igrigorik/istlsfastyet.com/pull/97
- scarmig 11y agoStupid question: A lot of HTTPS's value comes from authentication, not encryption. Has anyone investigated using something like the TLS_RSA_WITH_NULL_SHA cipher suite for HTTPS, to provide auth and integrity without the computational cost of symmetric encryption? Would that even provide a meaningful performance benefit? I'm guessing that it's disabled by default in most browsers, and figuring out a sane user experience to allow users to differentiate between encrypted and non-encrypted secure traffic seems like a very hard problem.
- deleted 11y ago[deleted]
- realityking 11y agoAsymetric message authentication without encryption is certainly a thing. The most common example is probably code signing as required by Windows and OS X for certain software.
- jkire 11y agoA similar idea is to allow pages to download static content over HTTP if they include the hashes of the content. Things like CSS and javascript need authentication so you know they haven't been tampered with, but don't necessarily require encryption. (The authentication here is from the fact you would download the page containing the hashes via HTTPS). Using this to download the global static content for a site doesn't even leak which individual page you were looking at. On the other hand, it complicates things a lot without really giving much advantages. The only time I can think of where it might be useful is for using CDNs from a HTTPS site, without having to set up HTTPS with your CDN.
- theandrewbailey 11y agoIf you're concerned about things getting tampered with, encryption guarantees that it won't. With your suggestion of hashes + HTTP, if it is tampered with, the page silently won't work as intended. With hashes + HTTPS, loud errors happen when things are tampered with. And because it's static content, deliver over HTTPS once and cache the hell out of it.
- ranrub 11y agoTLS is still slow, for users on 3G phones, remote areas, and 3rd world countries. But who cares about them? They're poor! They can cope with a slow web.