Books
in black and white
Main menu
Home About us Share a book
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Load Balancing Servers, Firewalls and Caches - Kopparapu C.

Kopparapu C. Load Balancing Servers, Firewalls and Caches - Wiley Computer Publishing, 2002. - 123 p.
ISBN 0-471-41550-2
Download (direct link): networkadministration2002.pdf
Previous << 1 .. 22 23 24 25 26 27 < 28 > 29 30 31 32 33 34 .. 70 >> Next

The first method uses cookies to store the state so that the server application does not have to, as shown in Figure 3.20. When the first request is received to add bookl to the cart, the server sets a cookie called cart with the value, bookl. Once the client receives the cookie as part of the reply, the browser stores the cookie on the local computer and transmits the cookie again in the subsequent request to add book2. Let’s assume the client starts a new TCP connection. We have configured the load balancer to not perform any session persistence. Therefore, the load balancer simply distributes the new connection to RS3. The application on RS3 finds the cookie cart=book1 in the request and knows that the shopping cart for this user already has bookl. RS3 simply adds the second book and sets the cookie cart=book1;book2 as part of the reply to reflect the updated contents of the cart. The browser stores the cart cookie again and sends it as part of the next request. Thus, we have moved the state maintenance from the server application of the client’s browser using cookies. This process is transparent to the end user because the browser handles all of the cookie maintenance transparently.
Figure 3.20: Using cookies to carry the state.
The second method is to use the URL to keep track of the state. The URL can consist of data that needs to be passed to the application. When the client adds bookl to the shopping cart, the server must change the hyperlink for the “Click here to add this item to shopping cart” button on the subsequent Web page to http://www.bookstore.com/cgibin/buybooks?cart=book1&numitems=1 The string following the ? is actually passed as arguments to the application program called buybooks. The data in the string includes the information that the shopping cart for this user already has book1 included in it and that the total number of items in the cart so far is one.
40
HTTP to HTTPS Transition
The third method is to use a back-end shared storage that stores the shopping-cart information. Whenever an item is added to the shopping cart, the server writes the shopping cart on a shared storage that other servers can access as well. If the next TCP connection goes to a different server, that server can retrieve the cart from the shared storage. But this method is very expensive because the server has to update the shared storage any time the user state changes; therefore it is not used often in practice. However, this approach is useful if the number of updates to the shared storage can be minimized, as we see in the next section, which discusses the transition from HTTP to HTTP over SSL.
Of all the three methods just discussed, the cookie-based method appears to be the most commonly used in practice because it’s easy to implement. However, the cookie-based method is subject to manipulation. A user may change the cookie on the computer so that it cannot be used to track how much money the user has deposited in the bank. But it can be used to track things such as the shopping-cart contents. The disadvantage of using cookies to track state information is that if the state information is significant, we need to transport big cookies back and forth, wasting bandwidth and increasing latency. Further, the maximum HTTP header length limits the amount of state information that can be tracked using URLs or cookies.
Session persistence is required for those applications that are stateful. We discussed at the beginning of this chapter how session persistence violates load balancing. Stateless applications do not require any persistence so the load balancer can assign each new TCP connection to the server with the least amount of load. Therefore, we can get the best load balancing for stateless applications. Obviously, making an application stateless may or may not be entirely possible. And sometimes, making the application stateless by using methods such as back-end shared storage may impact the performance very negatively, defeating the purpose of load balancing, which is to increase scalability and provide a faster response time.
HTTP to HTTPS Transition
In shopping-cart applications, a shopper first adds the needed items to the shopping cart, then clicks the “Checkout” button to purchase them. The browser then transitions to HTTPS protocol, which is the HTTP over SSL protocol. If we leave the shopping-cart application as stateful (i.e., we do not use one of the methods described earlier to make this application stateless), then the application needs the state to be carried forward as the user transitions from HTTP to HTTPS requests. Therefore, we need to find a way to send all connections from a given user to the same server for both HTTP and HTTPS traffic. While the session-persistence methods just discussed allow us to get session persistence in HTTP or HTTPS traffic individually, the challenge here is to ensure persistence when transitioning from HTTP to HTTPS. When the first HTTPS connection request is received, the load balancer needs to find a way to associate it with the earlier HTTP requests from the same user. Normally the source IP address will be the same for a given user for both HTTP and HTTPS requests. So, we can use source IP-based persistence during the HTTP to HTTPS transition. But source IP-based persistence won’t work well when dealing with megaproxy issues, as discussed earlier in the chapter. Although we can use cookie switching to address the megaproxy problem, the moment the user transitions from HTTP to HTTPS, the load balancer can no longer read the cookie because it is encrypted. Since the source IP may change from one session to another, the load balancer has no way to tie the SSL session together with the HTTP session. Therefore, the load balancer may forward the SSL session to a different server that does not have the shopping-cart context, and thus break the shopping session. While there is no easy solution for this, let’s examine a few approaches to address this.
Previous << 1 .. 22 23 24 25 26 27 < 28 > 29 30 31 32 33 34 .. 70 >> Next