Download (direct link):
Of the three methods we discussed, the cookie-rewrite method is preferred because it provides the benefits of cookie switching without the burden that cookie-read places on the administrator and the performance impact that cookie-insert places on the load balancer.
Although cookie switching has evolved to solve the megaproxy problem, it can serve different purposes. For example, let’s take the case of a Web site for an online brokerage catering to three tiers of customers: silver, gold, and platinum, as shown in Figure 3.17. If we have some high-end and some low-end servers, we can reserve more of the high-end servers for platinum customers and ensure that a sudden surge of requests from silver users does not affect the quality of service or response time provided to the platinum users.
Figure 3.17: Using cookie switching to provide differentiated services.
We need to combine the servers into three groups such that one group has many high-end servers. When a platinum customer comes in for the first time, the server will set a cookie to indicate User-Group=1. If we configure the load balancer to send all requests with the cookie User-Group=1 to server group 1, all platinum customers can be served a more predictable response time regardless of the load from gold or silver users.
Cookie switching can also be applied to provide enhanced quality of service. The traditional Layer 2/3 switches can look at only IP headers. But a load balancer can examine higher layers and set, adjust, or honor the IP precedence or Type of Service (ToS) bits that indicate the priority for a packet. By looking at cookies, the load balancer can intelligently recognize the customer, user, or traffic type and make intelligent decisions about the data packets. Although many load balancers may not support this type of functionality today, it seems that the load balancer will soon evolve to provide this type of functionality.
Although cookie switching is a powerful way to solve load-balancing and session-persistence issues and provide sophisticated traffic control, there are some issues that we may need to consider. Cookie switching has caused concern to some people about user privacy, as cookies can be used by Web sites to track one’s Internet usage patterns. But there are two types of cookies: permanent and temporary. Permanent cookies are those that are stored on the user’s computer that may live forever. Temporary cookies are those that are only active for the current browsing session and are deleted at the end of the session. Most browsers today also offer the option to turn permanent or temporary cookies off. For example, we can configure Microsoft Internet Explorer version 5.0 to not accept temporary cookies or permanent cookies individually.
If a user turns off cookies, we cannot use cookie switching in the load balancer for this particular user. It is likely that the Web application may not be able to serve such a user. Many popular e-commerce sites require a user to not turn cookies off because these sites cannot function accurately otherwise. In practice, this probably is not a major problem, because most users do not turn cookies off If a user does turn it off, we can try to fall back to source IP-based persistence for that user.
SSL Session ID Switching
Secure Socket Layer (SSL) is a protocol to exchange data with privacy and security. With SSL, all the data is encrypted, transmitted to the other end, and then decrypted for processing. Originally developed by Netscape, SSL is extensively used by Web browsers to transmit credit card numbers or other sensitive data. HTTP runs on top of SSL when exchanging sensitive information in order to provide end-to-end security. HTTP over SSL is also referred to as HTTPS, as the URL for this traffic has HTTPS at the beginning. For example, https://www.foundrynet.com will trigger the browser to use HTTP over SSL to communicate with this Web site.
There are different versions of SSL protocol and we will be discussing SSL protocol version 3.0 in this section. The load balancer cannot see the session ID in SSL protocol versions earlier than 3.0 because session ID is also transmitted in encrypted form. Version 3.0 transmits the SSL session ID unencrypted. It’s important to note the distinction because the load balancer cannot read any encrypted information, only the real server can.