- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 22 Jun 2012 15:02:10 +0000
- To: Rob Trace <Rob.Trace@microsoft.com>
- cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
In message <FF649A28BA27384396FD4F7BADF45DDF382957D8@TK5EX14MBXW602.wingroup.wi ndeploy.ntdev.microsoft.com>, Rob Trace writes: >A new version of I-D, draft-montenegro-httpbis-speed-mobility-02.txt I have read this draft, and I do like the thinking, even if not all the details. With one small tweak, this prosal has the potential to solve what I see as one of the really big high-performance issues: load-balancing at Tbit/s rates. The tweak I seek is: Once created, all requests on a given stream MUST have the same "Host:" header. This does not prevent a client (or proxy) from using multiple streams with same "Host:" header to get parallelism, but it means that load-balancers in front of hosting farms only need to examine the first request on any stream to find the "Host:" header, after that, it can just shift the stream through. Another way to think of this, is to make the stream-ID also work as a hop-to-hop flow-label. With that said... A lot of the benefit thus gained will be eaten up because taking a SPDY stream apart is a performance nightmare, particularly at Tbit/s rates, but at least the load-balancers will only need to take the first part of the SPDY streams apart. I seem to recall Willy and Adrien working on using serialization/encoding to save header transmission cost, instead of just blindly throwing things at gzip. Put something like that on top of Bobs draft instead of SPDY, and Tbit/sec starts to look realistic. Poul-Henning PS: I was happy to see that Guy didn't find any significant improvement from the gzip static dictionary, I thought I had done something wrong when I got that result. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 22 June 2012 15:02:42 UTC