Hacker News Reader

Comment by hannob | Hacker News Reader

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

View on HN

Yep, 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-viewi...

Netflix 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.

Youtube 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.

> 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.

I 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?

Based 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...

And how much do those increase first byte latency? (which is the real problem)

Tough 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-...

And some other advice and links here: https://istlsfastyet.com/

Pretty much all of them matter for first byte latency. OCSP & the key exchange both happen before any data can be exchanged.

Reply on news.ycombinator.com