Re:How a banner ad for H&R Block appeared on Apple.com witho...
by benjiweber on Monday April 08, 2013 @04:08PM
(#5514198)
Re-using HTTPs connections is only helpful when you have repeat requests from the same user. It's actually counter productive for tracking beacons or ad impressions, where you rarely see the same user twice in rapid succession.
For web applications the overhead is much less significant. Both because you can re-use connections, and because few web applications can manage 20k+ requests per second on low end hardware.
That's not true - or rather it conflates two unrelated problems.
1) HTTPS/SSL (even with larger certificates) isn't computationally expensive:
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.[1]
2) The HTTPS initial handshake is slow. However, this isn't because of the power of the machine, or the certificates size. It's cause by round-trip overheard (See [2]). The solution for that is to reuse HTTPS connections as much as possible (which both your server and the browser should try to do for you anyway. But doing things like using the same hostname can help)
[1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
[2] http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?to...