Session Affinity, sometimes also called Sticky Sessions, is one of the important and relatively complex problems to be solved in load balancing design.

Session persistence refers to a mechanism on a load balancer that distributes a series of related access requests to a server while completing load balancing tasks.

When a user sends a request to the server, the server creates a session and writes the session ID back to the client in the form of a cookie.

Here’s an example: When I access the SAP UI5 application,

In the header of the HTTP request, the client asks the server to return the request field that returns the session ID in the form of a cookie:

Sure enough, the header field in the server response returns the session ID:

These cookie information can be viewed in the Cookies area of the Application TAB of Chrome Developer Tools:

In this way, when a client accesses the server using a closed browser, the session ID is automatically attached to the access request. After detecting the session ID, the server uses the session corresponding to the ID in the memory to serve the client.

Let’s go back to our conversation maintenance. When is session persistence required? For example, when you shop on Taobao or JINGdong, you need to interact with the server for many times to complete the whole transaction, from completing user identity authentication to browsing the store, selecting the desired goods and adding them to the shopping cart, and finally placing an order and completing payment. Because these interaction processes are closely related sequentially and logically, the server needs a Context for each interaction step, that is, the output of the last interaction process. Therefore, all the related interaction processes must be completed by the same server.

In this case, assuming that the load balancer still scatters these related interaction sessions across different server instances, the user experience will be poor, such as a login page that pops up every time the customer clicks on the browser. Or even if the user enters the correct verification code, the verification code error is still displayed. It is also possible to lose items that customers put in their shopping carts because the server handles different instances.

This is why session persistence was introduced: to ensure that requests for a full session from the same client are forwarded to the same server in the background for processing.

So how does Cloud Foundry’s Session Affinity work?

The official document describes:

Docs.cloudfoundry.org/concepts/ht…

(1) To support sticky sessions, configure your app to return a JSESSIONID cookie in responses. The app generates a JSESSIONID as a long hash in the following format:

Your application will need to add a JSESSIONID field to the response result with the following length:

1A530637289A03B07199A44E8D531427

(2) If an app returns a JSESSIONID cookie to a client request, the CF routing tier generates a unique VCAP_ID for the app instance based on its GUID in the following format:

CF Routing tier Generates a VCAP_ID based on the JSESSIONID generated by app: 323F211E-feA3-4161-9bD1-615392327913

(3) The client must provide both JSESSIONID and VCAP_ID for each subsequent request. JSESSION_ID is given to the application for session adhesion. VCAP_ID is used to identify the application instance of the service. If the application fails, Gorouter will route the request to another application instance.

For more of Jerry’s original articles, please follow the public account “Wang Zixi “: