This is looking very promising! I created a simple page which loads a large image (~1.5MB), then onload fires, and after about 5s of wait, another image is fetched. All the assets are fetched over the same TCP connection.
- Sample WPT run: http://www.webpagetest.org/result/140206_R2_0eab5be9abebd600c17f199158782114/3/details/ - tcpdump trace: http://cloudshark.org/captures/5092d680b992?filter=tcp.stream%3D%3D4 All requests begin with a 1440 byte records (configured as: tune.ssl.maxrecord=1400), and then get bumped to 16KB - awesome. A couple of questions: (a) It's not clear to me how the threshold upgrade is determined? What triggers the record size bump internally? (b) If I understood your earlier comment correctly, HAProxy will automatically begin each new request with small record size... when it detects that it's a new request. This works great if we're talking to a backend in "http" mode: we parse the HTTP/1.x protocol and detect when a new request is being processed, etc. However, what if I'm using HAProxy to terminate TLS (+alpn negotiate) and then route the data to a "tcp" mode backend.. which is my spdy / http/2 server talking over a non-encrypted channel. In this instance this logic wouldn't work, since HAProxy doesn't have any knowledge or understanding of spdy / http/2 streams -- we'd start the entire connection with small records, but then eventually upgrade it to 16KB and keep it there, correct? Any clever solutions for this? And on that note, are there future plans to add "http/2" smarts to HAProxy, such that we can pick apart different streams within a session, etc? ig On Sun, Feb 2, 2014 at 12:32 AM, Willy Tarreau <w...@1wt.eu> wrote: > Hi Ilya, > > On Sat, Feb 01, 2014 at 11:33:50AM -0800, Ilya Grigorik wrote: > > Hi Eric. > > > > 0001-MINOR-ssl-handshake-optimz-for-long-certificate-chai: works great! > > After applying this patch the full cert is sent in one RTT and without > any > > extra pauses. [1] > > Cool, I'm impressed to see that the SSL time has been divided by 3! Great > suggestion from you on this, thank you! I'll merge this one now. > > > 0002-MINOR-ssl-Set-openssl-max_send_fragment-using-tune.s: I'm testing > with > > / against openssl 1.0.1e, and it seems to work. Looking at the tcpdump, > the > > packets look identical to previous runs without this patch. [2] > > > > Any thoughts on dynamic sizing? ;) > > OK I've implemented it and tested it with good success. I'm seeing several > small packets at the beginning, then large ones. > > However in order to do this I am not using Emeric's 0002 patch, because we > certainly don't want to change the fragment size from the SSL stack upon > every ssl_write() in dynamic mode, so I'm back to the initial principle of > just moderating the buffer size. By using tune.ssl.maxrecord 2859, I'm > seeing a few series of two segments of 1448 and 1437 bytes respectively, > then larger ones up to 14-15kB that are coalesced by TSO on the NIC. > > It seems to do what we want :-) > > I'm attaching the patches if you're interested in trying it. However you'll > have to revert patch 0002. > > Thanks for your tests and suggestions! > Willy > >
