Hacker News Reader

Comment by StavrosK | Hacker News Reader

This is potentially huge. SSL latency is a big issue when you want to make your site load faster, and this would basically eliminate the biggest reason to not turn SSL on. If this becomes standard, I can't see any of my sites, at least, using plain HTTP by default.

View on HN

I thought that SSL latency (and additional server load) was due to encryption overhead, not the handshake.

Compared to an extra 100-1000 millisecond trip each way to communicate between the browser and the server during the handshake, the CPU time to do the encryption is nothing.

Where in the world are you getting 1000 ms rtt's? Sat link?

Best case you have to do three RTs for a full SSL handshake (without false start anyway), so a RTT of 300ms will bring you pretty close to that 1000ms. We (github.com) certainly have average 1000ms SSL handshakes in Asia -- we're 5 RTs for an SSL handshake presently. It's extremely annoying.

Sure, I manage servers in the US, Japan and Australia so I'm well acquainted with how latency sucks. I was questioning the idea that there was a possibility of "an extra 100-1000 millisecond trip each way" - Taken literally, this would mean up to a 2000ms RTT (1000 ms each way). I get ~230ms RTT between Sydney and NYC, and 320 from Sydney to Hamburg going around the wrong way. for reference, 2000 ms is 74% of the RTT to the moon.

Oh, I would argue that latency often has no correlation to distance.

When you're talking about SSL handshakes, where else is the latency going to come from?

Poor hardware.

http://www.stuartcheshire.org/rants/Latency.html

Not everyone lives within a few hundred miles of the web server they're using.

Not to mention the WildBlue etc satellite Internet often used in rural areas.

the ssl handshake latency isn't why sysadmins don't want to implement everything over https. the reason (or at least 5 years ago when sysadmin was my primary role) is because the additional cpu power it takes to encrypt all the data is huge.

That's not really true now. CPUs have gotten faster, the speed of light has remained the same, and actually with users on crappy wireless/cell connections (and, increasingly, international), network latency is even more of an issue now.

I don't think that's really the case anymore. CPUs have just gotten that much faster. I run a node.js server with https on Linode's cheapest VPS that handles hundreds of requests per second. The server load is at ~0.00 most of the day.

Take a look at this article which measures handshake latency versus encryption latency, it's very well-written: http://www.semicomplete.com/blog/geekery/ssl-latency.html :

Anyway. The point is, no matter how fast your SSL accelerators (hardware loadbalancer, etc), if your SSL end points aren't near the user, then your first connect will be slow. As shown above, 22ms for the crypto piece of SSL handshake, which means 300ms of the SSL portion above was likely network latency and some other overhead.

Once SSL is established, though, it switches to a block cipher (3DES, etc) which is much faster and the resource (network, cpu) overhead is pretty tiny by comparison.

Summarizing from above: Using SSL incurs a 3.5x latency overhead for each handshake, but afterwards it's generally fast like plain TCP. If you accept this conclusion, let's examine how this can affect website performance.

Reply on news.ycombinator.com