308

I want to know the difference between sticky- and non-sticky sessions. What I understood after reading from internet:

Sticky : only single session object will be there.

Non-sticky session : session object for each server node

Lemmy
  • 2,437
  • 1
  • 22
  • 30
Sunny Gupta
  • 6,929
  • 15
  • 52
  • 80
  • Closely related: [Sticky Sessions and Session Replication](https://stackoverflow.com/questions/6367812/sticky-sessions-and-session-replication) – blackgreen May 23 '23 at 17:39

2 Answers2

701

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 3 web servers A, B and C behind the load balancer, it is possible that www.mywebsite.com is served from server A, www.mywebsite.com is served from server B and www.mywebsite.com/ 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. In order to synchronize 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.

To summarize, In case of Sticky Sessions, all your requests will be directed to the same physical web server while in case of a non-sticky load balancer may choose any webserver to serve your requests.

As an example, you may read about Amazon's Elastic Load Balancer and sticky sessions here : http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

Chaminda Bandara
  • 2,067
  • 2
  • 28
  • 31
TJ-
  • 14,085
  • 12
  • 59
  • 90
  • 9
    @TJ- what will happen if one node will unavailable? – gstackoverflow Nov 08 '15 at 15:25
  • 26
    In most of the cases, the session will be lost. In case of [AWS ESB](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html) _If an instance fails or becomes unhealthy, the load balancer stops routing request to that instance, instead chooses a new healthy instance based on the existing load balancing algorithm. The load balancer treats the session as now "stuck" to the new healthy instance, and continues routing requests to that instance even if the failed instance comes back._ – TJ- Nov 09 '15 at 02:22
  • 11
    According to what informations does the LoadBalancer make a HTTP session sticky? Especialy on HTTPS connections this issue becomes interesting. Do you feed the LB with the web servers private key, so that it is able to break up the SSL connection and fetch the HTTP session? Or does the LB simply make use of the client IP adress? In this case, what about proxy server where multiple clients use the same IP-address? Or even worse, mobile clients, where the IP-address changes frequently? Or is there even a better technique for that? Thanks – g000ze Feb 01 '16 at 14:12
  • 1
    Yes, there is - cookies :) For the first part - this is a preconfiguration. If you have configured the LB to create sticky sessions, it will help in doing so. – TJ- Feb 01 '16 at 16:32
  • 1
    If the LB is meant to read HTTP cookies, you need to feed it with the web servers private key and certificate in order to read encrypted traffic. This breaks the End-to-End security. Also, the LB's performance will never be the same anymore. Or do I see something wrong? – g000ze Feb 02 '16 at 14:39
  • 7
    Yes, you are absolutely correct. In order to make use of "x-forwarded-for" header or a sticky-cookie in this context, _SSL Termination_ needs to be used and hence, the request needs to be decrypted at the LB. – TJ- Feb 03 '16 at 03:51
  • 5
    @g000ze When dealing with applications that are not served directly to the internet, I believe it's common to enable TLS only on the outermost proxy server. (A load balancer can be regarded, perhaps over simplistically, as a special type of proxy server, that may pass the request on to any of multiple server.) Traffic between the load balancer and the other servers will occur on a local, secured network, and it is therefore often not necessary to encrypt it, or if it needs to be encrypted, a self signed certificate can be sufficient (since the proxy can be configured to trust it). – jpmc26 Feb 20 '16 at 01:34
  • 1
    Am I right in thinking you would almost always want sticky sessions enabled then? – Si-N Mar 16 '17 at 10:59
  • 2
    How are sticky sessions implemented internally? I can image a table that maps an IP address to a server name, but that can grow out of hand pretty quickly, no? – Maria Ines Parnisari Oct 17 '17 at 23:49
  • 4
    IP addresses may not be the right approach. For example, the requests may be routed via a proxy server. One of the approaches is cookies - the load balancer can read/write cookies that may be used to identify and forward the request to the intended server. – TJ- Oct 19 '17 at 15:04
  • @TJ- you said that "Now writing and reading data to/from a db for this use-case may not be a good idea". May I know why? – Gerald Nov 12 '19 at 03:17
  • @TJ- , is non-sticky session the same or equal to "distributed sessions"? – Artanis Zeratul Dec 18 '20 at 02:37
  • What about a session store like Redis to handle all the session's it's probably a good solution. – Snivio Aug 15 '21 at 18:48
2

Let's say the user sends a request to get its profile, there won't be anything in the memory of our web application instance. we get the user profile from DB nit before sending the response, we save the data in the memory of let's say Instance3. But the next request from the same user can go to any instance.

When the request first comes to Instance3, that time it will create a session that will have a session id. when the response is sent to the client, the client is supplied with a cookie. so next time this client makes a request, this cookie will be attached to the request, the load balancer will look at the cookie, and the load balancer will know that that request has to be forwarded to Instance3. This is sticky session solution. Its downside is what if Instance3 goes down? the load balancer will route the request to other instances but they do not have a cache. All the users stored in Instance3 will have high latency. This will impact the reliability of your system.

If you store sessions in all instances, now you would have memory issues. Let's say if an instance could store 100 user sessions and you have 3 instances, you would be able to store 300 sessions. But if each instance stores each session, you will be able to store only 100 sessions in all of your 3 instances. So this will impact the scalability of your application.

sticky and non-sticky sessions are components of stateful replication. If you want higher scalability you do not cache anything on your web application instance, your web instance will hit the DB with every request but this will cause high latency.

A better way is stateless replication where you do not store anything on your application instance but instead, you use server-side caching (memcached/redis)

TylerH
  • 20,799
  • 66
  • 75
  • 101
Yilmaz
  • 35,338
  • 10
  • 157
  • 202