HTTP Cookie Load Balancing

In Chapter 2, we saw that HTTP has its own client-side state mechanism commonly known as cookies. A cookie is simply a small piece of information implanted into the HTTP content by the server and used to identify the client on all future visits to the site. Cookies can be permanent, in which case they are stored on the hard disk of the client machine; or temporary, when they are stored temporarily in memory while the browser session is open . Later in Chapter 7, Persistence, Security, and the Internet , we'll see how cookies can be used to tackle issues of persistence on the Internet, but for now let's consider their use in cookie-based load balancing. When used for persistence, the cookie value is used to determine which object server the client's TCP connections should be spliced to in order to preserve a persistent user experience. When filling an online shopping cart, for example, many retail Web applications will require that all TCP connections for a given user transaction reside on the same physical server.

Cookie load balancing is similar in concept to using cookies for persistence, but offers the ability to provide a tailored user experience based on their cookie value. First, let's see how a user's browser comes to have an implanted cookie in the first place. Figure 6-11 shows a user visiting a Web site and receiving a temporary cookie.

Figure 6-11. A server-implanted cookie reaches the client browser and will be included in every HTTP GET to that domain.

When the client first visits the Web site, or in subsequent HTTP GET requests and responses, the site has the ability to insert the cookie into the user's browser to act as a reference point later during the transaction. In the case of a memory resident or temporary cookie, the information may only be interesting during the lifecycle of that particular user session. For example, a user purchasing items from a shopping site potentially need only be identified during each purchasing cycle. For cookies resident on the hard disk of a user, otherwise known as persistent cookies, the information may be used to identify the client on every subsequent visit to the site. In either scenario, the cookie value also contains information on the domain that implanted it and is presented by the user in every HTTP GET to the Web site. We'll see the persistence mechanisms that can be implemented with cookies later, but now let's see how they can be used for preferential services and other applications.

Applications of Cookie Load Balancing

Cookies can be used very effectively to improve the operation of many HTTP based applications. Now we've seen the types of cookies and how they operate , let's take a look at some examples of how cookies can be used in content switching applications.

1. Effecting Client Logon

The first scenario we'll look at is using cookie load balancing to enforce a strict login and authentication model for a Web site. Let's imagine that Foocorp.com wants to implement a partner-only Web site to provide certain premium, chargeable services for their partners . One of the main drivers of Internet commerce, or e-commerce , is the value of the content and services being offered . In being able to distinguish between different customer groups and enable a different charging model based on the quality of content to which the user groups will have access, the costs of implementing the types of infrastructures we've considered can be paid back far quicker. The first stage of this model is being able to identify users accessing the content. The first stage of the identification for access to the site will be a user logon through the browser. After a user has successfully identified and authenticated himself, the object server doing the logon can implant a temporary or permanent cookie so that the client can be identified on all subsequent visits and directed toward the content type he has paid for. There are other scenarios, even with the use of permanent or hard disk resident cookies, where the user might have to log on again in future visits. First, the client may be using a machine he has never used previously to access the site and, as cookies are local to each physical machine, the cookie will not be on the client's current machine. Second, most modern browsers offer users the ability to clear all cached files and cookies from their machines. In this instance also, the users would not have a previously implanted cookie to identify them.

Figure 6-12 shows this scenario in more detail. Implemented here are two groups of servers. Group 1 contains servers that are dedicated solely to performing logon and authentication for the site. Group 2, and subsequent other groups as we'll see, contain the actual content.

Figure 6-12. Using cookie load balancing, a user who does not have a cookie can be directed to a captive server group to authenticate.

Once the user's TCP connection has been completed by the content switch, the incoming HTTP GET request can be parsed and searched for cookies. If the correct cookie name with an associated value cannot be found, the content switch will splice the connection into the server group designated to handle "No Cookies." In some content switch configurations, this group may have the option of being explicitly defined as containing real servers to handle requests with no cookies. In other configurations, these servers might simply be defined to handle a cookie value of "any" and will receive the request based on the fact that this will be the least accurate match for any valid request. In either case, the client request will be directed toward the captive servers for logon. The complete session between the client and the site looks like:

1. The client establishes TCP session to content switch via delayed binding.

2. The client sends an HTTP GET request with no cookie value currently set.

3. The content switch parses the HTTP GET request and, seeing there is not a cookie set, establishes a new TCP connection to the "No Cookie" server group.

4. The recipient server receives the HTTP GET request and issues the client an HTTP 401 Authentication Required message to show the browser that a username and password are required.

5. The client provides the username and password in a subsequent HTTP response and the credentials are validated by the logon server.

6. Provided that the username and password combination are valid, the server will issue an HTTP 302 or 301 redirect to the correct URL for the main part of the site. This HTTP redirect will also contain a Set-Cookie header, which will implant the cookie into the client browser.

Once this process has completed, all subsequent GET requests from the client (which will contain the cookie) will be directed to the main content servers for the site. In our basic example, what we've achieved by the use of cookie load balancing is the capture of unauthorized user sessions and their consequent logon and authorization, thus ensuring that clients who have not identified themselves are never allowed IP access to the servers containing the real site content.

2. Preferential Services

As a second example, let's look at using the cookie value implanted in example 1 to determine the quality of service or content to which is a user is entitled. As the cookie value can effectively be any string value, many different service levels could be implemented using such a model; however, let's take a simplistic example using "Gold," "Silver," and "Standard" service levels. Based on our previous example, let's assume that the logon server has implanted a second cookie called UserGroup, which has these three possible settings. Once the user has successfully logged on and authenticated, this cookie will allow the content switch to direct the user requests to the appropriate user group based on the services the user has paid for. This premium charging model might be used for additional processing and availability of resource, such as larger numbers of servers or more processing power, or simply premium rate content such as enhanced information or better quality images, movies, or music files.

Figure 6-13 shows two users who have logged on being directed to the resource to which they are entitled based on the cookies' values inserted during the logon and authentication process described in example 1.

Figure 6-13. Users can be differentiated by services using cookie-based load balancing.