Sticky Session Capability Matrix of Huawei Cloud Dedicated Load Balancers

Source IP address-based sticky session uses the source IP address of a request as the hash key to locate the corresponding server from a statically allocated hash table. This allows requests from the same IP address to be forwarded to the same backend server.

• Common use cases
  • Layer 4 (TCP/UDP) scenarios that cookies cannot be used
  • Simple session scenarios where backend applications do not depend on cookies
  • Requests from the same client IP address must be routed to the same server.
• Working Principles
  1. When a client request reaches a load balancer for the first time, the load balancer extracts the source IP address to perform a hash calculation.
  2. The request is routed to a specific backend server based on the hash result, and the binding relationship is recorded.
  3. When a subsequent request from the same client reaches the load balancer, the load balancer extracts the source IP address and searches for the binding.
     • If the binding exists and does not time out, the request is routed to the same backend server.
     • If the binding times out or the source IP address changes, the route is recalculated.
• Parameter details

  Parameter	Value
  Default timeout duration	20 minutes
  Maximum timeout duration	60 minutes
  Value range	1 to 60 minutes

• Failure scenarios
  • The source IP address of the client is changed (for example, the client network is switched or the NAT mapping is changed).
  • The session stickiness duration has been reached.
• Supported protocols and load balancing algorithms

  Backend Server Group Protocol	Load Balancing Algorithm	Supported or Not
  TCP/UDP	Weighted round robin	Supported
  TCP/UDP	Weighted least connections	Supported
  TCP/UDP	Source IP hash	Configuration not supported (The source IP hash algorithm has same functions.)
  QUIC	Connection ID	Supported

• Constraints

  If you access a load balancer through Direct Connect or VPN, use the source IP hash algorithm (the load balancing algorithm) instead of sticky sessions. The source IP addresses may be concentrated in Direct Connect or VPN scenarios, resulting in poor sticky session performance.

The load balancer generates a cookie after it receives a request from a client for the first time. All the subsequent requests with the same cookie are distributed to the same backend server. Cookies are created and managed by the load balancer, and no modification is required for your applications.

• Common use cases
  • PHP web servers
  • Servers that maintain temporary session data, such as logs, shopping carts, and chat conversations
  • Scenarios where you do not want to modify application code to implement sticky sessions
  • Scenarios where the infrastructure layer needs to control the session duration
• Working principles
  1. When a client request reaches the load balancer for the first time, the load balancer uses a load balancing algorithm, such as weighted round robin or weighted least connections, to route the request to a backend server.
  2. The load balancer adds a cookie to the response with the target server identifier and expiration time.
  3. When subsequent requests from the same client reach the load balancer, the load balancer parses the cookie.
     • If the cookie has not expired, the request is routed to the same backend server.
     • If the cookie has expired, the load balancer runs its routing logic, determines a new target server, and generates a new cookie.
• Parameter details

  Parameter	Value
  Default timeout duration	20 minutes
  Maximum timeout duration	1440 minutes (24 hours)
  Value range	1 to 1440 minutes

• Failure scenarios
  • The client request contains no cookies, for example, when cookies are disabled in the browser.
  • The session stickiness duration has been reached.
• Supported protocols and load balancing algorithms

  Backend Server Group Protocol	Load Balancing Algorithm	Supported or Not
  HTTP/HTTPS/gRPC	Weighted round robin	Supported
  HTTP/HTTPS/gRPC	Weighted least connections	Supported
  HTTP/HTTPS/gRPC	Source IP hash	Sticky sessions cannot be configured.

This option relies on the backend application to generate a cookie value in the response. The load balancer routes subsequent requests to the same backend server based on the cookie value. The backend application can fully control the cookie name, attributes, and lifecycle, providing maximum flexibility.

Support for application cookie is available in some regions. You can see which regions support this function on the console.

• Common use cases
  • PHP web servers, where the application controls the session duration
  • Servers that maintain temporary session data need to determine whether a session has expired based on the application logic.
  • Scenarios where fine-grained control over session status attributes and duration is required
  • The backend application already has a custom cookie mechanism and wants to reuse it.
• Working principles
  1. When a client request reaches the load balancer for the first time, the load balancer uses the load balancing algorithm deployed by the customer to route the request to a backend server.
  2. The backend server processes the request and returns a response containing the custom cookie defined by the backend application.
  3. The load balancer records the binding relationship between the application cookie and the target server.
  4. The load balancer parses subsequent requests from the client with the application cookie.
     • If the cookie is valid and has not expired, the request is routed to the same backend server.
     • If the cookie has expired, the load balancer runs its routing logic and determines a new target server.
• Failure scenarios
  • The client request contains no cookies, for example, when cookies are disabled in the browser.
  • The session stickiness duration has been reached.
• Supported protocols and load balancing algorithms

  Backend Server Group Protocol	Load Balancing Algorithm	Supported or Not
  HTTP/HTTPS/gRPC	Weighted round robin	Supported
  HTTP/HTTPS/gRPC	Weighted least connections	Supported
  HTTP/HTTPS/gRPC	Source IP hash	Sticky sessions cannot be configured.

If multiple backend server groups are configured in a listener's forwarding policy, you can enable sticky sessions between backend server groups. After this function is enabled, requests from the same client are routed to the same backend server group, but not necessarily the same backend server. To route requests to the same backend server, you need to enable sticky sessions for the backend server group. This ensures that the client continuously uses the same version of the application in scenarios such as blue-green deployment.

This function is available in certain regions. You can see which regions support this function on the console.

• Common use cases
  • Multiple backend server groups are associated with the same forwarding policy of a listener. Client requests should be consistently routed to the same backend server group.
  • Blue-green deployment: Applications of different versions are deployed in different backend server groups. During a session, the client always accesses the same version.
• Working principles
  1. When a client request matches a forwarding policy, the load balancer routes the request to a backend server group based on the weights of the backend server groups specified in the forwarding actions.
  2. The load balancer creates a binding relationship between the user session and the target backend server group and sets an expiration time.
  3. When the client sends a new request, the load balancer checks whether the sticky session binding between the user session and the backend server group exists and has not expired.
     • If the binding has expired or does not exist, the load balancer runs its routing logic and determines a new target backend server group.
     • If the binding has not expired, the load balancer routes the traffic to the same backend server group, but not necessarily to the same backend server.
• Constraints
  The load balancer forwards requests strictly based on the weights. Exercise caution when configuring weights in the following scenarios, as they may pose service risks:

  • The health check results of all backend servers in the backend server group are unhealthy.
  • The backend server group has no backend servers in it.

For details about the configuration method, see Configuring Sticky Session Between Backend Server Groups.