W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: HTTP/2 vs. proxies ?

From: Jason Greene <jason.greene@redhat.com>
Date: Mon, 23 Jun 2014 13:19:41 -0500
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <0716ED5F-09C2-46DF-B3B2-4E653C79A41E@redhat.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

On Jun 21, 2014, at 11:52 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> In message <CABkgnnX9+sf=1RmgyK498ZQwDX+tbAVinck4wpzUgTt4RyH4Cw@mail.gmail.com>
> , Martin Thomson writes:
> 
>> We killed it so that we could avoid having to talk about it any more.
>> That worked out well, didn't it?
> 
> I'm increasingly getting the feeling that we have people who like
> the HTTP/2.0 draft and people who work with proxies, and that those
> two sets are almost exclusive ?
> 
> I would be interesting to see what a straw-poll of these two
> questions would show:
> 
> A)  I think HTTP/2.0 is ready for last call		YES/NO
> 
> B)  My primary HTTP/2.0 interest is proxy technology	YES/NO

I have been concerned about the protocol cost in a load balancing / proxy perspective, and how that will impact throughput on commodity hardware. In particular, on top of the framing cost, I am a little concerned with the CPU cost of differential compression in a proxy setting (for reasons previously stated). However, since less physical bytes are required to be on the wire than in HTTP/1.1 it very well could be a wash. Commodity hardware is also getting quite powerful when you consider its not too expensive to get a system capable of 40 threads near 3ghz, so a ballpark of 96 clock cycles per byte if you have 40gb.

I wish I had the time to build an implementation to verify equivalent HTTP/1.1 throughput levels before the spec goes into last call, but unfortunately I was a late to the party. I am hopeful that any deficiencies in this area could be addressed in a followup HTTP/3 spec.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Monday, 23 June 2014 18:20:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC