Hi Ilya, On Fri, Jan 17, 2014 at 09:36:51AM -0800, Ilya Grigorik wrote: > The 4K+ case is a fairly common occurrence, so it would definitely be worth > the effort.
Yes clearly, and you got Emeric curious so he already started to take a look at it. > Firefox telemetry data for "plaintext bytes read before a server > certificate authenticated": > http://telemetry.mozilla.org/#aurora/28/SSL_BYTES_BEFORE_CERT_CALLBACK > > The median is hovering right around 4K, which tells me that there would be > a lot of instances where we'd hit the extra RTT (ouch). > > Older data (from 2010) from Qualys points to similar distribution (see > slide 27): > http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf > > The other gotcha here is that Windows users get a double whammy (as can be > seen in the WPT trace), due to the delayed-ACK penalty (another 200ms) on > the client. Long story short, definitely worth fixing. :) Yes good point. > > > ----- > > > > > > (2) HA allows you to tune max_record_size - yay. That said, using a (...) > > The principle is quite simple : it counts the number of consecutive times > > it > > sees full buffer reads and writes to determine that it's forwarding a > > streaming > > content. Thus I think we could use that information to decide to enlarge > > the > > SSL buffers. I have no idea how these buffers are enlarged nor how much it > > costs to do that operation in the middle of traffic, but this is probably > > something we could experiment with. > > > > I'll discuss this with Emeric who knows SSL much better than me. > > > > Yup, that sounds like an interesting strategy. The only thing to note is > that you should consider resetting the record size after some idle timeout > -- same logic as slow-start after idle. We wouldn't even need this because the only reason for observing an idle period is that there's a new request/response cycle, and buffer flags are reset upon each new request so the "streamer" flag will automatically disappear. > For changing the actual record > size, I don't believe there is much more to it than just changing how much > you write into the record vs. number of records you emit: last patch for > tuning record size accomplishes this by setting a max on "try" byte count. Indeed, but Emeric has found something interesting. It seems there's a tunable in recent OpenSSL versions ("mtu" or something like this) with which you can adjust how many bytes are sent over the wire in a single record. So it might end up being even more precise than playing with the max on "try". We'll see. Anyway your suggestion is very interesting and merits some experimentation! Lowering time to first byte is always something useful to get users happy! Cheers, Willy
