An important function commonly found in load balancers is session stickiness, which makes it possible for a web application to remember user preferences, keep users authenticated, etc. But how do sticky sessions work exactly, and when should you implement them?
What are sticky sessions?
Sticky sessions — also known as session persistence — is the method that makes it possible for the load balancer to identify requests coming from the same client and to always send those requests to the same server. In sticky sessions, all user information is stored on the server side, and this method is commonly used in stateful services. This functionality is primarily available for HTTP load balancers.
How do sticky sessions work?
In client-server protocols, like HTTP, a session is a group of client interactions with a server within a given time span — for example, viewing multiple pages on a website or performing multiple actions on a web application. During a session, data is stored on the server, and this method utilizes features that would not be possible otherwise, for example, keeping the client authenticated.
Without sticky sessions, requests coming from the same client would be routed to a different server each time. The following diagram illustrates how requests are routed with and without sticky sessions.
The different approaches to session stickiness
Cookie-based session stickiness
The primary approach to implementing sticky sessions is using session cookies which constitutes a storage solution — the cookie is stored on the client side and sent along every request to the server. Session cookies are either duration-based or application-controlled.
Duration-based: the load balancer issues a cookie that remains valid for a specific amount of time. Session stickiness is applied for the duration of the session cookie. When the specified time expires, sessions are no longer sticky.
Application-controlled: the application issues a cookie that remains valid for a specific amount of time. Even though the load balancer often issues its own cookie, it complies with the duration specified by the application. Application-controlled sticky sessions require a more complex configuration between the application and the load balancer.
Consistent hashing
While sticky sessions with session cookies is a feature available only for HTTP load balancers, it is possible to extend this functionality to other protocols, for example, TCP and UDP load balancers. Session cookies constitute a storage solution; session stickiness is made possible by storing the cookie on the client side and sending it along every request to the server.. An alternative to this method is consistent hashing, a computation solution.
Consistent hashing collects user data from the original client request (e.g., the client IP), and uses a deterministic algorithm to compute and determine to which server the request is routed. Based on the user data, the algorithm is able to identify requests coming from the same client and routes them to the same server.
Why should you use sticky sessions?
The need to use sticky sessions is determined by the architecture of your application. Sticky sessions are the preferred solution for stateful applications that cannot afford to share sessions across multiple servers. Stateful applications store data locally or on a remote server. The operation of sending all needed session data from the client each time it's reaching the server can be costly. With sticky sessions, you take advantage of the cached information, instead of performing the same costly operation every time the same request is made by the client.
Why should you avoid using sticky sessions?
Just as sticky sessions are needed in certain architectures, they can be irrelevant in others. It is not a question of whether you should avoid implementing session stickiness or not, but rather if your application needs it. A few things to keep in mind:
Stateless applications: In stateless applications, sticky sessions are unnecessary, since user data is part of the client request itself and are not stored on the server.
Scalability: Scalability is also a key consideration for implementing sticky sessions. Session persistence can cause uneven load balancing, which in turn has a negative impact on scalability.
Single-server applications: Naturally, if your application utilizes a single server, there is no need to implement session persistence since all requests are routed to this one server.
Security risks: Although there are no major security risks involved in implementing sticky sessions, the risk of a Distributed Denial-of-Service (DDoS) attack, in particular, is higher in an architecture that uses session persistence. With DDoS, an attacker attempts to cause an outage by overwhelming a server with user traffic. Since sticky sessions route requests coming from the same client to the same server — instead of distributing the requests across multiple servers — it is easier for the attacker to overwhelm that targeted server, possibly resulting in an outage.
Try sticky sessions with Traefik Proxy
If you are looking into implementing sticky sessions to your application, why not try it with Traefik Proxy? Traefik Proxy is a modern reverse proxy and load balancer that integrates with your existing infrastructure components and configures itself automatically and dynamically.
Configuring sticky sessions in Traefik Proxy is straightforward and simple. Once you enable sticky sessions, Traefik Proxy sets a `Set-Cookie` header on the initial response to let the client know which server handles the first response. For the following requests, the client sends the cookie with the value set, keeping the session active on the same server.
Here is a basic example of configuring sticky sessions in Traefik Proxy:
## Dynamic configuration
http:
services:
my-service:
loadBalancer:
sticky:
cookie: {}
You can also configure session stickiness with custom options and on all required levels. If you want to dig deeper into this and other features of Traefik Proxy, check out the official documentation.
