The session persistence allows requests from the same IP to be forwarded to the same backend server. By default, the CLB will route each request to a different backend server instance. However, you can use the session persistence feature to route requests for a particular user to the same backend server instance, which allows certain applications that require session persistence (such as shopping carts) to work properly.
Layer-4 session persistence
The layer-4 protocol (TCP/UDP) supports session persistence based on source IP. The session persistence time can be set to any integer value between 30 and 3,600 seconds. If there is no new request in the session after the time threshold is exceeded, the connection is disconnected. Session persistence is related to the balancing method:
- When the balancing method is round-robin scheduling, requests are distributed according to the weights of the backend servers, and session persistence based on the source IP is supported.
- When the balancing method is weighted least connections, comprehensive scheduling is performed based on server load and weight, and session persistence is not supported.
Layer-7 session persistence
The layer-7 protocol (HTTP/HTTPS) supports session persistence based on cookie insertion (CLB inserts cookies into a client). The session persistence time setting supports 30 - 3,600 seconds. Session persistence is related to the balancing method:
- When the balancing method is round-robin scheduling, requests are distributed according to the weights of the backend servers, and session persistence based on cookie insertion is supported.
- When the balancing method is weighted least connections, comprehensive scheduling is performed based on server load and weight, and session persistence is not supported.
- When the balancing method is "IP Hash", session persistence based on source IP is supported, but session persistence based on cookie insertion is not supported.
Connection timeout
The current HTTP connection timeout (keepalive_timeout) defaults to 75 seconds. If there is no data transmission in the session after the time threshold is exceeded, the connection will be disconnected.
The current TCP connection timeout period cannot be adjusted yet and the default is 900 seconds. If there is no data transmission in the session after the time threshold is exceeded, the connection will be disconnected.
Configuring session persistence
- Log in to the CLB console and click the ID of the CLB instance for which session persistence needs to be configured, to enter the CLB details page.
- Select the Listener Management tab.
- Click Modify next to the CLB listener for which session persistence needs to be configured.
- Select whether to enable the session persistence feature, click the button to enable it, enter the persistence time, and click OK.
The relationship between persistent connection and session persistence
Scenario 1: HTTP layer-7 business
Assume that the client access is HTTP/1.1 protocol, and set Connection:keep-alive in the header information. Through CLB, I access the backend CVM again. If I do not enable session persistence at this time, can I access the same CVM the next time I access it?
Answer: cannot.
First, HTTP keep-alive means that the TCP connection will remain open after it is sent, so the browser can continue to send requests over the same connection. Keep-alives save the time required to establish a new connection for each request and also save bandwidth. The default timeout period of the CLB cluster is 75 seconds (if there is no new request refresh within 75 seconds, the TCP connection is disconnected by default).
HTTP keep-alive is established between the client and CLB. If the cookie session persistence is not enabled at this time, the next time you access, CLB will randomly select a CVM on the backend based on the round-robin scheduling policy, and the previous persistent connection will be wasted.
Therefore, it is recommended to enable session persistence.
When the cookie session duration is set to 1,000 seconds, the client initiates a request again. Since more than 75 seconds have passed since the last request, the TCP connection needs to be re-established. The application layer determines the cookie and finds the same CVM. The CVM accessed by the client is still the one accessed last time.
Scenario 2: TCP layer-4 business
Assume that the client initiates the access, the transport layer protocol is TCP, and persistent connection is enabled. However, session persistence based on source IP is not enabled. Can the same Client access the same machine next access,?
**Answer:**Uncertain.
First, according to the implementation mechanism of the layer-4, when TCP enables a persistent connection, if the persistent connection has not been disconnected, and the two previous and subsequent accesses are through the same connection, the same machine can be accessed. If the first connection is released due to other reasons (network restart, connection timeout) during the second access, the second access may be scheduled to other backend CVMs, and the default global timeout of the persistent connection is 900 seconds, that is, if there is no new request, it will be released.