tencent cloud

PrevNext

Feedback

search by keyword

Recent Pages

Documentation
Cloud Load Balancer
    Documentation
    Download PDF

    Session Persistence

    Last updated: 2024-01-04 14:34:05
    Download PDF
      Session persistence can forward requests from the same IP to a single real server. By default, a CLB instance will route requests to different real server instances for load balancing. However, you can use session persistence to route requests from a specified user to the same real server instance. This enables applications that require session persistence (such as shopping cart) to run properly.

      Layer-4 Session Persistence

      Layer-4 protocols (TCP/UDP) support source IP address-based session persistence. The session persistence duration can be set to any integer (in seconds) between 30 and 3,600. If the time threshold is exceeded and the session has no new requests, session persistence will end. Session persistence is subject to the load balancing mode:
      In the mode of Weighted round robin where requests are distributed based on the weight of real servers, source IP address-based session persistence is supported.
      In the mode of Weighted least connections where scheduling is performed based on server load and weight, session persistence is not supported.

      Layer-7 Session Persistence

      Layer-7 protocols (HTTP/HTTPS) support session persistence based on cookie insertion (CLB inserts the cookie into the client). The session persistence duration can be set to a value (in seconds) between 30 and 3,600. Session persistence is subject to the load balancing mode:
      In the mode of Weighted round robin where requests are distributed based on the weight of real servers, session persistence based on cookie insertion is supported.
      In the mode of Weighted least connections where scheduling is performed based on server load and weight, session persistence is not supported.
      The mode of IP Hash supports session persistence based on source IP addresses, but not on cookie insertion.

      Connection Timeout Period

      Currently, HTTP connection timeout period (keepalive_timeout) is 75s by default. To adjust it, enable custom configuration. If the threshold is exceeded and the session has no data transmission, the connection will end. Currently, TCP connection timeout period is 900s by default and cannot be customized. If the threshold is exceeded and the session has no data transmission, the connection will end.

      Configuring Session Persistence

      1. Log in to the CLB console and click the ID of the CLB instance to be configured with session persistence to enter its details page.
      2. Select the Listener management tab.
      3. Click Modify next to the CLB listener to be configured with session persistence.
      4. Choose whether to enable the session persistence feature. Click the button to enable it, enter the persistence duration, and click submit.

      Relationship Between Persistent Connection and Session Persistence

      For information about how to enable long connection, see Configuring an HTTP Listener and Configuring an HTTPS Listener.

      Scenario 1: HTTP layer-7 business

      Assume a client uses HTTP/1.1 as the request protocol and includes the Connection:keep-alive header in requests. If the client accesses a real server via CLB without session persistence enabled, can the client access the same real server next time?
      A: No.
      First, HTTP keep-alive indicates TCP connection remains connected after a request is sent, so the browser can send requests via the same connection. Persistent connection reduces the time required for establishing a new connection for each request and lowers bandwidth consumption. The default timeout period of a CLB cluster is 75s (if there is no new request within 75s, TCP will be disconnected by default).
      The HTTP keep-alive connection is established between the client and a CLB instance. If cookie session persistence is disabled, the CLB instance will randomly select a real server according to the round-robin policy for your access next time. The previous persistent connection is no longer valid.
      Therefore, we recommend you enable session persistence.
      If the cookie session persistence duration is configured as 1,000s, the client will initiate a request again. Because the interval between the two requests exceeds 75s, TCP connection needs to be established again. The application layer identifies the cookie and finds the real server the client accessed last time so it will be assessed again this time.

      Scenario 2: TCP layer-4 business

      Assume a client initiates access, TCP is the transport-layer protocol, persistent connection is enabled, but session persistence based on source IP address is disabled. Can the same client access the same server in the next access request?
      A: Not necessarily.
      First, according to layer-4 implementation mechanism, when persistent connection is enabled for TCP and not closed, and the same connection is accessed in two requests, then the same client can access the same server. If the connection is closed for some reasons (such as network restart or connection timeout) during the second access request, the request may be scheduled to another real server. The default global timeout period for a persistent connection is 900s, that is, the persistent connection will be released if there is no new request in 900s.
      For information about how to enable persistent connection, see Configuring an HTTP Listener and Configuring an HTTPS Listener.
      Contact Us

      Contact our sales team or business advisors to help your business.

      Contact Us
      Technical Support

      Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

      Submit a Ticket
      7x24 Phone Support
      Copyright © 2013-2024 Tencent Cloud. All Rights Reserved.
      Privacy PolicyLegalCookie Policy