> To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.
Google also has a proposal called Snap Start that reduces the handshake to zero round trips when the browser has performed a full handshake with the server in the past: http://tools.ietf.org/id/draft-agl-tls-snapstart-00.html. It's much more complex and requires adoption in both servers and browsers so I don't think they're working on it anymore, but maybe someday.
Certificate validation can be even more of a bottleneck than RTTs to the server; I worked on a paper that's in submission where we gathered OCSP response times in the wild, and median times for some responders were as high as 500ms.
Hah, when they say "only a handful of vendors" that includes load balancer vendors like F5 and A10, which truckloads of ecommerce sites rely on for ssl offload. Its a simple code update to fix, but I remember doing a 4am loadbalancer reboot when my CTO's chrome auto-updated and all of a sudden he couldn't get to our https stuff (the important stuff).
Interesting - we use F5 load balancers for SSL offload, as do a huge percentage of the interwebs. If F5 didn't support False Start, I suspect a good deal more than 0.4% of the SSL websites would be affected.
Do you think maybe it's something like an older version of F5 BigIP firmware that doesn't support False Start?
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.
This doesn't help adoption like the article suggests; what it does do is shave a few milliseconds and overhead off the initial connection which is great for thin or long pipes (low bandwidth or high latency). Otherwise, in contrast to the article's statement about SSL not being implemented because of the encryption overhead, false start doesn't change much.
The bigger picture is that false-start will make google's upcoming SPDY handshake faster too; then, because SPDY is a more aggressive with the initial connection (CWND, push support), the packets saved by false start are used to push content. Without false-start, an initial SPDY connection would be encumbered.
Quickly eyeballing that Internet-Draft, here's the core change:
> If certain conditions are met, application data can be sent when the handshake is only partially complete ...
I'm surprised this hasn't be done before -- spammers have used this idea with SMTP for years, for example. Well done Messrs Langley, Modadugu and Moeller.
I thought SSL pages/resources aren't cached like they would be normally under regular HTTP, so there would still be extra latency (for repeat visits) if you ever visited a website that required SSL everywhere (like say Github).
https content is generally only cached in memory by the browser.
But if the response contains a Cache-Control header that explicitly specifies that the content is public, it can be cached to disk, just like http content. Eg:
It's a browser configuration thing, but I think you're right about the default.
Maybe a more intelligent approach would be to use "don't cache" if the server doesn't specify any caching headers. Otherwise, follow the server's recommendation.
[+] [-] Matt_Cutts|15 years ago|reply
[+] [-] gwern|15 years ago|reply
It's nifty being a Googler.
[+] [-] emily37|15 years ago|reply
Certificate validation can be even more of a bottleneck than RTTs to the server; I worked on a paper that's in submission where we gathered OCSP response times in the wild, and median times for some responders were as high as 500ms.
[+] [-] cagenut|15 years ago|reply
[+] [-] illumin8|15 years ago|reply
Do you think maybe it's something like an older version of F5 BigIP firmware that doesn't support False Start?
[+] [-] StavrosK|15 years ago|reply
[+] [-] drivebyacct2|15 years ago|reply
[+] [-] nessence|15 years ago|reply
The bigger picture is that false-start will make google's upcoming SPDY handshake faster too; then, because SPDY is a more aggressive with the initial connection (CWND, push support), the packets saved by false start are used to push content. Without false-start, an initial SPDY connection would be encumbered.
[+] [-] JeffRodriguez|15 years ago|reply
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
SSL everywhere!
[+] [-] sbierwagen|15 years ago|reply
[+] [-] jacques_chester|15 years ago|reply
> If certain conditions are met, application data can be sent when the handshake is only partially complete ...
I'm surprised this hasn't be done before -- spammers have used this idea with SMTP for years, for example. Well done Messrs Langley, Modadugu and Moeller.
[+] [-] ivank|15 years ago|reply
[+] [-] wmf|15 years ago|reply
[+] [-] plasma|15 years ago|reply
Or is my assumption wrong here?
[+] [-] briansmith|15 years ago|reply
[+] [-] mike-cardwell|15 years ago|reply
But if the response contains a Cache-Control header that explicitly specifies that the content is public, it can be cached to disk, just like http content. Eg:
Cache-Control: public, max-age=86400
[+] [-] JeffRodriguez|15 years ago|reply
Maybe a more intelligent approach would be to use "don't cache" if the server doesn't specify any caching headers. Otherwise, follow the server's recommendation.
[+] [-] TeHCrAzY|15 years ago|reply
[+] [-] Joakal|15 years ago|reply
[0] http://wiki.nginx.org/HttpSslModule