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

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
inefficient.

> 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
faster.

Willy

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