HTTP Header Load Balancing

Once it's clear that we can have access to the HTTP GET method and the data that follows it for load balancing decisions, it's easy to see that further inspection of other HTTP headers is also applicable and useful to solve a number of issues in scaling HTTP services. The HTTP RFCs 1945 and 2068 (for HTTP/1.0 and HTTP/1.1, respectively) define a large series of HTTP headers as standard, although it is possible for either the client- or server-side application to insert custom headers if required. Some of the more useful and commonly implemented of these standard headers are listed in Chapter 2, and the following example shows some of these from a HTTP packet capture:

 Hypertext Transfer Protocol GET /brochures/aboutus.html#whereweare HTTP/1.0\r\n  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg  \r\n  Accept-Language: en-gb  \r\n  User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)  \r\n  Host: www.foocorp.com  \r\n  Connection: Keep-Alive  \r\n \r\n 

In configurative terms, most content switches will require the definition of the header name (e.g., " User-Agent ") and the values per real server to match against.

Applications of HTTP Header Load Balancing

1. Virtual Hosting with the Host: Header

One of the most common implementations of HTTP header load balancing is through the use of the Host: header. When a user enters a URL into the client browser, the host portion ”the www.foocorp.com element ”is stripped out and included in the HTTP request as the Host: header. As the Host: header was only formally introduced into the HTTP/1.1 specifications, it is likely that some older browsers will not support the passing of this header. Many modern browsers will implement this and other newer header options even when forced to perform object and page retrievals using HTTP/1.0 after the method.

In considering why Host: header load balancing is useful, let's consider an example involving a shared hosting environment that houses a number of different Web sites. This implementation methodology has become increasingly popular during recent years , owing to the fact that it allows Web hosting businesses to offer increased value for money while keeping costs low by sharing hardware resources among larger numbers of customers. Prior to the ability to inspect the HTTP Host: header, each customer would have assigned an IP address per unique host or had to house content for all host-based Web sites on every object server. Figure 6-7 shows an example of this type of implementation. Here we see that each of the individual Web sites is separated by a unique IP address (10.10.10.100 and 10.10.10.101, respectively), which, given that registered Internet addresses are relatively expensive, does not provide cost-effective scalability.

Figure 6-7. Implementing a shared resource model using unique IP addresses per Web site.

A far more effective and scalable implementation model for these types of shared resource scenarios is to use the HTTP Host: header. This allows the provisioning of a system commonly referred to as virtual hosting , something that can also be implemented on Web servers directly. Virtual hosting basically means to use a single IP address to represent multiple hosts or Web sites. From a content switch perspective, this implies that we can use a single VIP to represent a series of sites, the host names of which are distinguished using the Host: header. Enabling Host: header load balancing on the content switch in our previous example gives us the scenario shown in Figure 6-8.

Figure 6-8. The shared resource model implemented using HTTP Host: headers for virtual hosting.

2. Optimizing Content for Browser Types

For any experienced user of the Internet, one thing is clear: not all browsers are created equal. Ask any site designer to name his or her top five technical issues when implementing new pages and styles, and the incompatibility between Web browsers will feature highly. This can be anything from the simple and subtle differences between Microsoft Internet Explorer and the Mozilla-based browsers such as Netscape, through to the challenges of not knowing whether the content viewer is using a WAP phone or PDA to view the site. Clearly, delivering the site content back to users in a form most suitable to their browser choice is a challenge that needs to be met.

Within the HTTP specifications, there is a standard header definition for User-Agent , which, as the name suggests, provides information about the browser type issuing the requests , along with supplementary information about the compatibility and operating system being used.

 Hypertext Transfer Protocol GET /brochures/aboutus.html#whereweare HTTP/1.0\r\n Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg\r\n Accept-Language: en-gb\r\n  User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)  \r\n Host: www.foocorp.com\r\n Connection: Keep-Alive\r\n 

In general terms the User-Agent header contains the base browser type first (as the most significant piece of information), followed by other comments that identify the browser and any subproducts that form a significant part of the user agent. The preceding example shows a User-Agent that is Mozilla 4.0 compatible and is in fact a Microsoft Internet Explorer product running on top of the Windows 2000 operating system (identified by the Windows NT 5.0 comment). (Mozilla is an open -source browser based on the Gecko browser engine. Using this as the User-Agent shows the Web server that the browser claims to be compatible with this layout engine. For more information, see www.mozilla.org.)

As we can see from Figure 6-9, the ability to read this header information allows us to implement a hosted solution where the same content is optimized for different browsers and recipient devices.

Figure 6-9. Using the User-Agent HTTP header means that content can be optimized for delivery to different user types.

So, what does this offer in terms of a usable solution? Well, for many Web sites, knowing the makeup of the clients before they view the content can be a real benefit. Many sites might implement a different URL for each different content optimization, such as:

• www.foocorp.com ” standard Web browsers

• mobile.foocorp.com ” mobile phones, WAP clients, and PDAs

• text.foocorp.com ” a text-only version of the site for light clients

or might have links from the main homepage to content optimized for these different browsers. Using the User-Agent string for sites that have large amounts of content for different subscribers can greatly enhance the overall user experience.

3. Delivering Content in the Correct Language

The final HTTP header type we'll look at is Accept-Language . This header identifies to the object server the language encodings that are supported and understood by the browser. Within the configuration of most modern browsers, the languages that are to be offered by this header can be configured, as shown for the Netscape browser in Figure 6-10.

Figure 6-10. Most modern browsers, such as Netscape Navigator, allow the user to select the languages to offer in the Accept-Language HTTP header.

The settings shown in the Netscape Navigator dialog boxes in Figure 6-10 would result in the following Accept-Language header being inserted into the HTTP request:

 Hypertext Transfer Protocol GET /brochures/aboutus.html#whereweare HTTP/1.0\r\n Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg\r\n  Accept-Language: en-us, en;q=0.66, af;q=0.33  \r\n User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)\r\n Host: www.foocorp.com\r\n Connection: Keep-Alive\r\n 

In the GET request we can see the Accept-Language header with the three language types: en-us, for U.S. English; en, for UK English; and af, for Afrikaans. Each of these parameters is described also using the "q" option, which indicates the preference specified by the browser. In this case, en-us is the preferred language with a q=1 (not shown as it is the default), followed by en with a quality of 0.66, and, finally, af with a quality of 0.33.

The inclusion of the Accept-Language header into content switching implementations has a very similar effect to that of the User-Agent header. Its use can improve the user experience of a Web site by eliminating the need to deliver only standard English language content or offering the user a manual choice.

In all, given the wide range of standard Request and Response HTTP headers included in the original specifications, the implementation of header-based load balancing offers the chance to solve numerous problems associated with Web site deployment. Some content switches will offer the ability to load balance based on commonly used headers such as those discussed previously, some will allow you to define any HTTP header to load balance on, and others will combine a mixture of both.