6 ms·
I thought that SSL latency (and additional server load) was due to encryption overhead, not the handshake.
by drivebyacct2 16y ago
I thought that SSL latency (and additional server load) was due to encryption overhead, not the handshake.
- dangrossman 16y agoCompared 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.
- smithian 16y agoWhere in the world are you getting 1000 ms rtt's? Sat link?
- rtomayko 16y agoBest 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.
- smithian 16y agoSure, 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.
- phillmv 16y agoOh, I would argue that latency often has no correlation to distance.
- InclinedPlane 16y agoNot everyone lives within a few hundred miles of the web server they're using.
- yuhong 16y agoNot to mention the WildBlue etc satellite Internet often used in rural areas.
- saranagati 16y agothe 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.
- rdl 16y agoThat'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.
- dangrossman 16y agoI 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.
- brown9-2 16y agoTake 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 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.