Sticky Sessions

A method used with Application Load Balancing, to achieve server-affinity.

A router or load balancer with sticky-session support can assign a single server to a particular user, based on their HTTP session or IP address. The assigned server is remembered by the router for a certain amount of time, ensuring that all future requests for the same session are sent to the same server.

To be effective, the router must remember the server selection for a time that is longer than the session timeout.


  • Reasonably simple to implement for experienced network administrators.
  • Reduces the need to implement session-failover, as users are only sent to other servers if one goes offline.
  • Load balancer/router is often responsible for detecting offline servers, providing faster request-failover than round robin DNS-based load balancing.


  • Difficult to set up for network administrators who are new to sticky sessions.
  • Problems can be difficult to diagnose. See the sections below for the main issues.
  • The load-balancer/router must be load-balanced itself, or it becomes a point of failure that will take down an entire cluster.
  • Cannot provide global load-balancing (whereas round-robin DNS can).
  • Session-failover is often not implemented, as there is reduced need. If a server goes offline, all users lose their session.

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.

See Also

metawerx specific

referring pages