Re: [hybi] #1: HTTP Compliance

[Willy Tarreau <[e-mail]>]

Hi Jamie,

On Thu, Jul 22, 2010 at 12:38:34AM +0100, Jamie Lokier wrote:
> Willy Tarreau wrote:
> > On Wed, Jul 21, 2010 at 08:22:11AM -0700, Roberto Peon wrote:
> > > I believe Mike quoted numbers in an earlier thread.
> > > 
> > > Just to be sure we're talking about the same thing, I'm talking about the
> > > UPGRADE feature of HTTP generically, and not as it applies to the current
> > > draft Websocket spec.
> > 
> > I thought they were related to the current version since it also uses
> > Upgrade. Anyway, even if some don't support it yet, it will be easy
> > to detect bypass them based on simple rules.
> 
> Um, will it?  How would that work?


Basically at some (many?) ISPs, you can find such an architecture :

  [ ISP's clients ]
      \  |  /
        POP
         |
         |
      routers
         |               / cache
    L7 load balancer ---<- cache
         |               \ cache
         |
      routers
         |
     (internet)


The clients connect to somesite.com:80. At least they believe they do
so. The first layer of routers see "port 80" and decide to forward to
the load balancers, otherwise they forward everything to the internet.
Obviously there are variants, it is possible that everything is sent
to the LBs too, that's just an example. The LBs have to support 3 main
features :

  - check if the URL has to be handled by the cache farm or not. If
    not, let's simply route it to the internet.

  - bypass the caches if too many are dead so that the remaining ones
    can't handle the load.

  - apply a load balancing algorithm on the request (eg: URL hash)
    to select a working cache, and forward the request to that cache.
    The request is sent unmodified and the cache receives the packets
    with the original destination IP address (sometimes they just rely
    on the Host header though).

The first point is crucial. If the LB sends everything to caches, it
costs a lot in terms of hardware, especially if the hardware is not
suited to the type of application (imagine streaming video over a
classical cache for instance, it would eat long-lived connections
and CPU for zero added value). Also, there are always some cases
where a bug or incompatibility will be discovered on the caches and
they will have to be bypassed for some sites or request types. Last,
they can degrade quality of service without bringing anything (eg:
when dealing with XMLHttpRequest or interactive applications).

This is the reason why the LBs in front of the cache are said to be
Layer7, they're HTTP-aware. Alteon was already doing a lot of business
with their products 10 years ago on this precise feature. Thus, the
ISP has the ability to add rules which check the HTTP requests and
decide whether or not it makes sense to send it to the cache farm
or if it's easier to forward it to the server.

The only prerequisite is that the L7 LB is HTTP-compliant, or at
least understands HTTP enough so that everything that it decides
to forward without passing through the caches will be unmodified.

The goal of the ISP is not to *control* what passes there, but to
*save bandwidth*. That means that rules can be very coarse. Some
will simply decide that any URL containing a question mark will
bypass the caches. Others will decide that youtube has too much
data to store locally and that it's better to bypass the cache
than thrashing it with youtube-only contents.

And others will simply say that any connection containing
"Upgrade: WebSocket" will bypass the caches. But for that to work,
the HTTP-like protocol has to be HTTP-compatible ;-)

Hoping this clarifies the things a bit,
Willy