next up previous contents
Next: Implementation: Super Sparrow Up: Directing Traffic Previous: DNS

   
HTTP


  
Figure 4: Redirecting Connections Using HTTP
\includegraphics[width=13cm]{abc_apache.eps}

As an alternative to using DNS to communicate load balancing information to clients HTTP[3][7]7 redirects may be used. The advantage of this is that as the redirection is done by an HTTP server much finer granularity may be achieved. Whereas DNS has a granularity of per-hostname, HTTP may have a per URL8 granularity. For instance all .jpeg, .jpg and .png URLs may be redirected while all other URL may be handled locally. That is, images are load balanced while HTML pages are handled by a central server.

The key disadvantage of using HTTP redirection is that once a client is redirected to a site there may be no way of directing the client to another site. This may be a problem if all URLs are directed to another site and this site fails. Except by than manually going back or reloading the initial URL, the client has no way to access an active site.

Suppose once again that www.slarken.org.au is mirrored between POP X and Y and that HTTP redirects are being used to distribute traffic between these two POPs. A sample request may work as follows:

1.
Web servers or farms in POP X and Y are both listed as IP addresses for www.slarken.org.au. The client happens to send an HTTP request to POP X this time around. POP Y would do equally well.

2.
The HTTP server in POP X is able to redirect clients to the network-wise closest POP. Note that the IP address of the Client is used here, whereas when using DNS the IP address of the Client's DNS server is used. The HTTP server then sends an HTTP redirect to a URL that resolves to the IP address of a web server or farm in POP Y, www.y.slarken.org.au.

If POP X had been down then the client would most likely have stalled. A reload would probably have cased an HTTP request to be sent to the other IP address for www.slarken.org.au and POP Y would handle the request from there.

If POP Y was down then the query to the route server in POP X would have shown that POP X was the closest POP to the Client and the Apache server would send an HTTP redirect to a URL that resolves to the IP address of a web server or farm in POP X, www.x.slarken.org.au.

If both POPs were down then the connection would fail, as would a reload.

3.
The Client has www.y.slarken.org.au, the URL of a server in POP Y and makes an HTTP request to this server.

4.
The server responds to the Client's HTTP request.

next up previous contents
Next: Implementation: Super Sparrow Up: Directing Traffic Previous: DNS
Horms
2000-12-02