Hey Willy. On Fri, Jan 17, 2014 at 2:49 AM, Willy Tarreau <w...@1wt.eu> wrote: > > > > > (1) Certificates that exceed 4KB require an extra RTT even with IW10: HA > > ships the first 4KB then pauses and waits for client ACK before > proceeding > > to send remainder of the certificate. At a minimum, this results in an > > extra handshake RTT. You can see this in action here: > > > > WPT run: * > http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/ > > < > http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/ > >* > > > > tcpdump: > > > http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2.cap > > > > > > I believe this is the same exact issue as fixed in nginx here: > > > https://github.com/nginx/nginx/commit/e52bddaaa90e64b2291f6e58ef1a2cff71604f6a#diff-0584d16332cf0d6dd9adb990a3c76a0cR539 > > Useful stuff, indeed with the larger certs these days, maybe we should try > to > improve things. >
The 4K+ case is a fairly common occurrence, so it would definitely be worth the effort. 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. :) > > ----- > > > > (2) HA allows you to tune max_record_size - yay. That said, using a > static > > value introduces an inherent tradeoff between latency and throughput -- > > smaller records are good for latency, but hurt server throughput by > adding > > bytes and CPU overhead. It would be great if we could implement a smarter > > strategy: > > > > http://mailman.nginx.org/pipermail/nginx-devel/2013-December/004703.html > > http://mailman.nginx.org/pipermail/nginx-devel/2014-January/004748.html > > > > Would love to hear any thoughts on this. The advantage of above strategy > is > > that it can give you good performance out-of-the-box and without > > sacrificing performance for different kinds of traffic (which is > especially > > relevant for a proxy...). > > I think we have an option here : haproxy already performs permanent > observation > of what the traffic looks like (streaming or interactive traffic). It uses > this > to decide to enable splicing or not. But it should be usable as well for > SSL. > 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. 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. ig
