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

Re: Stuck in a train -- reading HTTP/2 draft.

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 26 Jun 2014 07:11:50 +0200
To: Johnny Graettinger <jgraettinger@chromium.org>
Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Martin Thomson <martin.thomson@gmail.com>, Jason Greene <jason.greene@redhat.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20140626051150.GA11680@1wt.eu>
Hi Johnny,

On Wed, Jun 25, 2014 at 06:49:08PM -0400, Johnny Graettinger wrote:
> >
> > Please consider this simple use case :
> >
> >    - requests for /img /css /js /static go to server 1
> >    - requests for /video go to server 2
> >    - requests for other paths go to server 3
> >
> > Clients send their requests over the same connection.
> Just thinking about how I'd manage this: it seems that the load balancer
> would need to have special knowledge as to whether a backend connection is
> likely to send a large frame or not.
> If they are, and you're not terminating SSL on either side (probably
> uncommon), then you could issue read()s of just the frame header and
> temporarily splice() the connections for payload-size bytes.

That's the expected principle, except that splice() over 16kB is highly

> In all other cases though, you're better off issuing larger fixed-size
> read()s, and aggregating frames to write() in user-space.
> What this probably means is that you'll want to segregate your large-asset
> servers from small-asset servers, and you'll want to inform your LB's pool
> configuration as to which heuristic is appropriate.
> But since you've now segregated your servers anyway, another option is to
> have large-asset servers terminate SSL & HTTP/2, and configure a
> large-asset pool in tcp-mode, distinguished by proxy IP or SNI.

Not really because you still need to follow the request/response stream to
continue to route future requests appropriately based on the path for the
same host header.

> This seems a whole lot simpler, allows the load balancer to splice(), and
> works with SSL.

Sure but this is layer3-based routing, not l7-based as customers want today.
And HTTP/2 will make this even more important because by avoiding a new
connection to retrieve videos, we'll save one RTT and videos will start

Received on Thursday, 26 June 2014 05:12:25 UTC

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