The latest releases of Chrome now enable a feature called SSL False Start. False Start is a client-side change which makes your SSL connections faster. As of this writing, Chrome is the only browser implementing it. Here is what it does.
In order to establish a secure connection, SSL uses a special handshake where the client and server exchange basic information to establish the secure connection. The very last message exchanged has traditionally been implemented such that the client says, “doneâ€, waits for the server, and then the server says, “doneâ€. However, this waiting-for-done is unnecessary, and the SSL researchers have discovered that we can remove one round trip from the process and allow the client to start sending data immediately after it is done.
To visualize this, lets look at some packet traces during the handshake sequence, comparing two browsers:
|
Chrome |
Browser w/o FalseStart |
| 0ms SEND TCP SYN 83ms RECV TCP SYN ACK 83ms SEND TCP ACK 83ms SEND Client Hello 175ms RECV Server Hello Certificate Server Hello Done 176ms SEND Client Key Exchange Change Cipher Spec Enc Handshake Msg HTTP Request 274ms RECV Enc Handshake Msg Change Cipher Spec Enc Handshake Msg 275ms RECV HTTP Response |
0ms SEND TCP SYN 84ms RECV TCP SYN ACK 84ms SEND TCP ACK 84ms SEND Client Hello 173ms RECV Server Hello Certificate Server Hello Done 176ms SEND Client Key Exchange Change Cipher Spec Enc Handshake Msg 269ms RECV Enc Handshake Msg |
These two traces are almost identical. Highlighted in red is the subtle difference. Notice that Chrome sent the HTTP Request at time 176ms, which was a little more than one round-trip-time faster than the other browser could send it.
(Note- it is unclear why the HTTP response for the non-FalseStart browser was 250ms late; the savings here is, in theory, just 1 round trip, or 83ms. There is always variance on the net, and I’ll attribute this to bad luck)
Multiplicative Effect on Web Pages
Today, almost all web pages combine data from multiple sites. For SSL sites, this means that the handshake must be repeated to each server that is referenced by the page. In our tests, we see that there are often 2-3 “critical path†connections while loading a web page. If your round-trip-time is 83ms, as in this example, that’s 249ms of savings – just for getting started with your page. I hope to do a more thorough report on the effect of FalseStart on overall PLT in the future.
For more information on the topic, check out Adam Langley’s post on how Chrome deals with the very few sites that can’t handle FalseStart.
Hi Mike,
Good work!!!
Have you analyzed if this strategy will work even when ssl session resumption is enabled? How much gain will you get then?
Regards,
-Rohit
Hi Mike!
As Adam Langley’s post doesn’t allow to comment, I am asking here instead:
Is there a quick way to determine, if my site allows SSL false starts?
Kind Regards,
Markus