Sticky sessions on load balancers with HTTP and HTTPS

Question

How does sticky sessions relate to HTTP and HTTPS;

If I place a load balancer in front of some web app servers that run a front end that supports HTTPS, will the sessions remain "sticky" on a typical load balancer that lists "stick sessions" as one of it's supported features?

I understand that question is partly open ended; To clarify, would I require a load balancer that supports sticky HTTPS session specifical or is "sticky sessions" a principal that functions agnostic of the HTTP payload, be it encrypted or not?

Thank you.

Solution 1

Loadbalancers can identify sessions with cookies, parameters in the url, etc. If you use https on your loadbalancer, the loadbalancer has to do all the SSL handling itself, so it can have a look into the session.

So, yes, you need a loadbalancer which terminates the SSL to the client, so it can access the session data. (no Linux Virtual Server or HAProxy for you then)

Solution 2

Generally sticky is the default for HTTPS and non-sticky is the default for HTTP.

For HTTP you need to enable sticky sessions if part of the session state data is held locally on the server side (either only in RAM or only on local storage). For example, once a connection is authenticated to server A, it needs to continue being routed to server A because server B will require reauthentication.

If subsequent requests will succeed regardless of which server they are routed to then you should not be using sticky.

Non-sticky, if your application supports it, is usually preferred.

Comments

[Hrvoje Špoljar]

HAProxy supports both native SSL termination or you can use another software like NGiNX to terminate SSL and proxy through HTTP back to HAProxy. Sticky can be achieved directly with HAProxy sticky-table or emulated with inserting cookies.

[BigSack]

@HrvojeŠpoljar , right :)