Understanding Sticky Session

The sticky session is done with the help of load balancers. When your website is served by only one web server, for each client-server pair, a session object is created and remains in the memory of the web server. All the requests from the client go to this web server and update this session object. If some data needs to be stored in the session object over the period of interaction, it is stored in this session object and stays there as long as the session exists.

However, if your website is served by multiple web servers which sit behind a load balancer, the load balancer decides which actual (physical) web-server should each request go to. For example, if there are three web servers A, B and C behind the load balancer, it is possible that www.mywebsite.com/index.jsp is served from server A, www.mywebsite.com/login.jsp is served from server B, and www.mywebsite.com/accoutdetails.php are served from server C.

Now, if the requests are being served from (physically) 3 different servers, each server has created a session object for you, and because these session objects sit on three independent boxes, there's no direct way of one knowing what is there in the session object of the other. To synchronise between these server sessions, you may have to write/read the session data into a layer which is common to all - like a DB. Now writing and reading data to/from a DB for this use-case may not be a good idea. Now, here comes the role of sticky-session.

If the load balancer is instructed to use sticky sessions, all of your interactions will happen with the same physical server, even though other servers are present. Thus, your session object will be the same throughout your entire interaction with this website.

Sticky Sessions and HTTPS

Sticky sessions will not work with HTTPS (SSL) if the server ID is based on the HTTP session. This is because the contents of the requests cannot be investigated due to the encryption. In this case, there are 3 options:

• Web server proxies. An initial web server decodes the SSL requests, and forwards the request onto one of the servers in the cluster. Fairly simple to set up, but causes increased load on the proxy. Also the proxy is a single point of failure, which is more likely to fail considering the amount of work it has to perform.
• Hardware SSL decoders. Hardware in the router or load balancer that is capable of decoding the HTTPS requests, and determining the session information stored in them. These are fast and less likely to fail than a web server proxy, but often more difficult to set up and with pricing based on their power.
• IP address-based server allocation. All requests from a given IP address or range are sent to the same server. This is by far the easiest and cheapest method, and allows the router or load-balancer to do all the work. However, their may be more chance of an unevenly distributed load with this method if most of the load comes from a single IP/range. For example, all requests are coming from the same university, will all be sent to the same server.

IP-based Sticky Sessions Considerations

When using IP addressing, it is important to base the decisions on an entire Class B or Class C IP address range. For example 100.101.nnn.nnn (Class B) or 100.101.102.nnn (Class C). The reason for this is that many universities or large companies use proxies between their users and the outside world. The proxies are often assigned multiple IP addresses, meaning requests from these organisations can come from multiple similar IP addresses, even though they are the same user. If the router was to assign a server based on one IP address, then assign a different server for another address from the same proxy, the user's requests would be alternately sent between the two different servers, causing a loss of server-affinity.