Re: HTTP/2 Expression of luke-warm interest: Varnish

In message <CAAbTgTs78uxYKuc0LFDLG1M+yq4xS2eL1UAL13dtO9g3rHsq2A@mail.gmail.com>
, Brian Pane writes:

>My key takeaway from your draft is that you're advocating for HTTP/2.0
>to have a wire format that can be parsed with efficiency much closer
>to TCP [...]

Yes, at least for the routing envelope.

The metadata and content should probably be squeezed as hard as we
reasonably can.

>Section 9.1 defines a very small set of message components that are
>available to the "HTTP router" in an efficient representation. 

This is one of the places where I've changed my mind a fair bit
since I wrote this, in particular with respect to URI, and cookies,
but the general idea still holds.

>e.g., routing traffic based on cookies that
>persisted across sessions, routing based on query parameters, and even
>routing based on custom headers inserted by a previous hop in a
>multi-tier hierarchy.

(Cookies are gone in my vision of HTTP/2.0 by now, instead you'll
have a client created and supplied session identifier.)

Yes, there are times and places where you need more detailed
routing, and if so, you'll have to pay the cost of taking it
all apart.

But a very large fraction of all HTTP-routing is by "Host:" header
only, and if you add URI and session-id to that, I wouldn't be
surprised if you have covered 90% of all HTTP routing based on the
request.  (Obviously a lot of routing happens on the basis of server
availability, but that is unaffected by the protocol.)

There is a significant gain to be had for all routing, also the
more complex kind you mention, if the multiplex-ID/stream-ID can
double as a flow-label for routing, so the router only have to
examine the first request on each stream, and let all subsequent
requests follow the same decision.

One further optimization from there, could be to only send the
envelope when you open a new stream/mux-channel, but I'm not
sure if that would be a net pessimization or optimization.

>I think it would be illuminating to hear from some people who have
>sites with 1) very high traffic (big enough to care about high-speed
>request parsing and routing), 

I'd much rather ask a VHDL/Verilog wizard: "How would you
route HTTP requests at 1Tbit/s in an FPGA ?"

The routable envelope is meant to be a hedge for the future: We
might be able to route 10 or even 40Gbit/s on todays silicon, but
if we want to do it to 1Tbit/s on tomorrows silicon, I am sure need
to make the task easier, because the silicon isn't getting faster,
it's just getting wider.

But as I hope is clear:  This was intended as food for long-range
thought, not as a concrete proposal.

-- 
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 Tuesday, 17 July 2012 07:08:32 UTC