4 ms·

I'm currently adding https (TLS) support to my blog, using LibTLS (part of LibreSSL). My initial impressions are that TLS handshake is very computationally exp

I'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 ago
The 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 ago
How 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 ago
  I 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 ago
    wrk[1] does appear to reuse a connection for each request. [1] https://github.com/wg/wrk https://github.com/wg/wrk
- hirsin 11y ago
  Any 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.
  - Zr40 11y ago
    That's probably because the response to this particular https URL is larger; http on this server simply redirects to https and is therefore a smaller response. Not that this matters here; the top level comment measured requests per second, not bytes per second. If anything, the smaller response for http would give http an advantage in this comparison.
geofft 11y ago
What key size and cipher suite are you using? (If you're willing to post the URL, we can have a much more informed discussion, but a sanitized copy of an SSL Labs test or even of `openssl s_client -connect localhost:443` is also workable.) Also, what hardware are you using? This site is aimed more at companies who fear of losing business because their site is slow, than people hosting a blog on a home server; if you don't have hardware-accelerated crypto (like most server-class machines have, whether or not you explicitly looked for it) its argument is less valid.
- Ono-Sendai 11y ago
  I'm using all the defaults, as provided by LibTLS, so I'm not sure. I'll have a poke round and tell you later. The TLS support is not deployed to the internet so posting a URL wouldn't be very helpful. Hardware is my Ivy bridge i7 with 4 physical cores.
  - geofft 11y ago
    Yeah, Ivy Bridge is new enough. Are you negotiating an AES-GCM suite? Also, are you using a 2048-bit key if you're doing RSA? (A larger key almost certainly provides no more security, since your intermediate is almost certainly 2048-bit, and will noticeably slow down handshakes.)
- Ono-Sendai 11y ago
  LibTLS tells me what was negotiated was 'ECDHE-RSA-CHACHA20-POLY1305' Edit: some more output: New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-CHACHA20-POLY1305
babuskov 11y ago
Yep. Keep-alive is your friend. If you use Apache or similar web server where keep alive means using a lot of RAM, you can place HAProxy or similar load balancer in front of it. HAProxy keeps the connections with browser alive, while connections between HAProxy and backend web server are closed and re-established all the time. Of course, this means that SSL is terminated on the load balancer and not the webserver.
seiji 11y ago
One problem is "TLS" isn't just one thing to understand and test against. TLS involves dozens of optional cypher suites and each one has a unique performance profile. Just for fun, add !kEDH to your server's list of allowed cyphers then see how your performance changes. Another performance impact some people overlook: your key size is also computationally expensive. There's not much reason to have a key larger than 2048 bits, so if you made a 4096 bit key just for fun, roll it back to a 2048 bit key for better performance too (plus, your mobile viewers will thank you for not burning their battery life needlessly).

detaro 11y ago

The 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 ago

How 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 ago
I 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 ago
  wrk[1] does appear to reuse a connection for each request. [1] https://github.com/wg/wrk https://github.com/wg/wrk
hirsin 11y ago
Any 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.
- Zr40 11y ago
  That's probably because the response to this particular https URL is larger; http on this server simply redirects to https and is therefore a smaller response. Not that this matters here; the top level comment measured requests per second, not bytes per second. If anything, the smaller response for http would give http an advantage in this comparison.

geofft 11y ago

What key size and cipher suite are you using? (If you're willing to post the URL, we can have a much more informed discussion, but a sanitized copy of an SSL Labs test or even of `openssl s_client -connect localhost:443` is also workable.) Also, what hardware are you using? This site is aimed more at companies who fear of losing business because their site is slow, than people hosting a blog on a home server; if you don't have hardware-accelerated crypto (like most server-class machines have, whether or not you explicitly looked for it) its argument is less valid.

Ono-Sendai 11y ago
I'm using all the defaults, as provided by LibTLS, so I'm not sure. I'll have a poke round and tell you later. The TLS support is not deployed to the internet so posting a URL wouldn't be very helpful. Hardware is my Ivy bridge i7 with 4 physical cores.
- geofft 11y ago
  Yeah, Ivy Bridge is new enough. Are you negotiating an AES-GCM suite? Also, are you using a 2048-bit key if you're doing RSA? (A larger key almost certainly provides no more security, since your intermediate is almost certainly 2048-bit, and will noticeably slow down handshakes.)
Ono-Sendai 11y ago
LibTLS tells me what was negotiated was 'ECDHE-RSA-CHACHA20-POLY1305' Edit: some more output: New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-CHACHA20-POLY1305

babuskov 11y ago

Yep. Keep-alive is your friend. If you use Apache or similar web server where keep alive means using a lot of RAM, you can place HAProxy or similar load balancer in front of it. HAProxy keeps the connections with browser alive, while connections between HAProxy and backend web server are closed and re-established all the time. Of course, this means that SSL is terminated on the load balancer and not the webserver.

seiji 11y ago

One problem is "TLS" isn't just one thing to understand and test against. TLS involves dozens of optional cypher suites and each one has a unique performance profile. Just for fun, add !kEDH to your server's list of allowed cyphers then see how your performance changes. Another performance impact some people overlook: your key size is also computationally expensive. There's not much reason to have a key larger than 2048 bits, so if you made a 4096 bit key just for fun, roll it back to a 2048 bit key for better performance too (plus, your mobile viewers will thank you for not burning their battery life needlessly).