Server Load Balancer:FAQ about CLB listeners

Does CLB support port forwarding?

Yes, CLB supports port forwarding.

For more information, see Redirect requests from HTTP to HTTPS.

Can Layer 4 CLB listeners listen on a port range?

No, they can't. If you want to use a TCP or UDP listener that listens on a port range, you can create Network Load Balancer (NLB) instances, which support multi-port listening and forwarding for Layer 4 listeners. For detailed instructions, see Enable multi-port listening and forwarding for NLB.

What do I need to know before configuring listener ports for CLB?

Specific carriers mark ports 25, 135, 139, 444, 445, 5800, and 5900 as high-risk ports, and block traffic over these ports in specific regions. Even if the ports are opened by security group rules, CLB instances remain inaccessible over these ports in the restricted regions. We recommend that you do not use the ports.

• For information about the ports that are used by applications on Windows Server operating systems, see Service overview and network port requirements for Windows in Windows documentation.

• For more information about common ports, see Common ports.

If a request already carries a TCP Option Address (TOA) header before the request is sent to CLB, can CLB preserve the client IP address in the header?

No, CLB cannot preserve the client IP address in the TOA header. By default, if the TOA module is installed, CLB automatically adds the TOA header to preserve client IP addresses. If CLB receives a request that already carries a TOA header, CLB cannot preserve the client IP address in the header.

Which listeners should I choose for backend services using the WebSocket or WebSocket Secure protocol?

• For backend services using the WebSocket protocol, use TCP or HTTP listeners.

• For backend services using the WebSocket Secure protocol, use TCP or HTTPS listeners.

How long does it take for CLB listener configuration modifications to take effect, and what is the impact?

The modifications take effect immediately upon submission. They affect only subsequent new requests. Existing connections are not affected.

How do I enable WAF protection for CLB?

If I disable the public network interface controller (NIC), is my CLB service affected?

If a backend Elastic Compute Service (ECS) instance is assigned a public IP address, the service that the ECS instance provides will be interrupted after you disable the public NIC.

By default, if an ECS instance is assigned a public IP address, it uses this IP address for communication. In this case, network traffic is transferred through the public NIC of the ECS instance. If you disable the public NIC, the ECS instance cannot send responses to the Internet. We recommend that you do not disable the public NIC of your ECS instance. If you must disable it, change the destination of the default route to a private IP address to avoid service disruption. Additionally, confirm whether your service requires access to the Internet, such as accessing ApsaraDB RDS instances over the Internet.

Why do connections fail to reach the maximum bandwidth in some scenarios?

• Description: If you purchase an Internet-facing CLB instance whose Internet metering method is pay-by-bandwidth, and you perform stress tests on a client or use a client to transfer large packets, connections may fail to reach the maximum bandwidth.

• Causes:

  CLB provides load balancing services by evenly distributing requests across groups of backend servers. The maximum bandwidth you specify is evenly allocated to each backend server.

  The upper limit for data that can be downloaded through a connection is calculated using the following formula: The maximum bandwidth of the CLB instance that you specified/(N-1). N indicates the the number of nodes in a CLB cluster, for Layer 4 CLB, N is 4. For Layer 7 CLB, N is 8. Assume you specify a 10 Mbit/s bandwidth when purchasing the CLB instance and use it for Layer 4 forwarding. When multiple clients attempt to access CLB, the total bandwidth of the CLB instance can reach 10 Mbit/s, while the upper limit for data that can be downloaded by each client from CLB is 10/(4-1)=3.33 Mbit/s.

• The maximum bandwidth of each backend server is calculated by using the following formula: Peak bandwidth for download on a single connection = Total bandwidth of the CLB instance/(N - 1). N represents the number of server groups, which is 4. For example, if you set the maximum bandwidth to 10 Mbit/s in the CLB console, the total bandwidth can reach 10 Mbit/s if connections for multiple clients are used at the same time. The maximum bandwidth of each client is calculated based on the following formula: 10/(4 - 1) = 3.33 Mbit/s.

• Recommended solutions:

  • Change the Internet metering method of the CLB instance to pay-by-data-transfer.

  • Use a Network Load Balancer (NLB) or Application Load Balancer (ALB) instance, an elastic IP address (EIP), and an EIP bandwidth plan. This solution increases the scalability of the ALB or NLB instance and ensures that connections can reach the maximum bandwidth.

Why do packet losses occur even if monitoring data indicates the maximum bandwidth of a CLB instance is not reached?

Possible causes:

• The monitoring data is not real-time but the average of monitoring metric values in a whole minute. If incoming traffic exceeds the maximum bandwidth of CLB within specific seconds in a minute but the average bandwidth value of the whole minute is less than the maximum bandwidth, the bandwidth usage displayed in the monitoring panel will be lower than the maximum bandwidth.

• CLB provides load balancing services by evenly distributing requests across groups of backend servers. The maximum bandwidth you specify is evenly allocated to each backend server. If the data volume requested to download by a client exceeds the upper limit for a single backend server, packet losses occur. For the specific formula used to determine the upper limit for a backend server, see Why do connections fail to reach the maximum bandwidth in some scenarios?

Why does CLB fail to reach the maximum QPS in some scenarios?

• Description: In scenarios in which a small number of persistent connections are used, not all backend servers in server groups are allocated at least one persistent connection. As a result, the CLB instance cannot reach the maximum QPS.

• Causes:

  CLB provides load balancing services by evenly distributing requests across groups of backend servers. The maximum QPS that you configure is evenly allocated to each backend server.

  The maximum QPS of each backend server is calculated by using the following formula: Maximum QPS of each backend server = Total QPS/(N - 1). N is the number of backend servers in server groups. For example, if you purchase a CLB instance of the Small I (slb.s1.small) specification in the CLB console, the maximum QPS is 1,000. When multiple clients are used at the same time, the total QPS can reach 1,000. If the number of backend servers is 8, the maximum QPS of each backend server is calculated based on the following formula: 1000/(8 - 1) = 142.

• Recommended solutions:

  • Use short-lived connections on a single client for stress testing.

  • Reduce connection reuse based on business requirements.

  • Upgrade the specification of the CLB instance. For more information, see Upgrade or downgrade a pay-as-you-go (pay-by-specification) instance.

  • Use an ALB instance, which supports higher scalability.

In some scenarios, why does the number of new connections fail to reach the upper limit?

• Problem: After I purchase a CLB instance that uses the pay-by-specification metering method, new connections fail to reach the maximum bandwidth in some scenarios, such as client-side stress testing and single-source access.

• Causes:

  The load balancing system uses cluster deployment to ensure high availability and scalability. Connections from external networks are distributed to multiple system servers in the cluster. As a result, the quota on connections per second is evenly distributed among the servers.

  Maximum number of connections per second = Total number of connections per second of the CLB instance/(N - 1). N represents the number of servers.

  For example, if you purchase a Small I (slb.s1.small) instance, the maximum number of connections per second supported by the CLB instance is 3,000. When multiple clients access the CLB instance, the total number of connections per second can reach 3,000 on the CLB instance. 3,000/(4 - 1) = 1,000. Therefore, each server supports a maximum of 1,000 connections per second.

• Recommended solutions:

  • Change the metering method of the CLB instance: Change the metering method of the CLB instance from pay-by-specification to pay-as-you-go, which does not require you to specify a specification and supports higher performance.

  • Use NLB: NLB is ideal for scenarios that require high concurrency or a large number of new connections per second. NLB supports higher performance and scalability than CLB. CLB supports Limited by servers, CLB supports only a limited number of connections per second. However, NLB can withstand a large number of concurrent connections.

How long is the connection timeout period for each type of listener?

• TCP listener: 10 to 900 seconds.

• HTTP listener:

  • Idle connection timeout period: 1 to 60 seconds.

  • Connection request timeout period: 1 to 180 seconds.

• HTTPS listener:

  • Idle connection timeout period: 1 to 60 seconds.

  • Connection request timeout period: 1 to 180 seconds.

Why do connections to the service address of CLB time out?

Possible causes:

• The service IP address of CLB is blocked for security reasons.

  The IP address of CLB may be blocked due to traffic blackholing, traffic scrubbing, or WAF. WAF offers protection by sending Reset (RST) packets to the client and backend server after a connection is established.

• Client port exhaustion

  Client port exhaustion can cause connection errors, especially in stress tests. By default, CLB removes the timestamps of TCP connections. As a result, the tw_reuse setting does not take effect and connections in the time_wait state cannot be reused. These accumulated connections exhaust all ports.

  Solutions: Set clients to establish persistent connections instead of short-lived connections. Set the so_linger socket option to close connections by sending RST packets instead of FIN packets.

• The accept queue of a backend server is full.

  If the accept queue on the backend servers is full, the backend servers can no longer return syn_ack packets. As a result, requests from clients time out.

  Solution: Set net.core.somaxconn to 128. Specify a proper value based on your business requirements and run the sysctl -w net.core.somaxconn=<Desired value> to change the value of the parameter and restart applications on the backend servers.

• Layer 4 CLB is accessed from backend servers.

  If you access Layer 4 CLB from a backend server, the connection fails. For example, a request that reaches a backend server is redirected to the application on another backend server.

• RST packets are not correctly responded to.

  If no data is transmitted within 900 seconds after a TCP connection is established on CLB, CLB sends RST packets to the client and the backend server to close the connection. If the application on the backend server does not correctly respond to the RST packet, the application may send data packets after the connection is closed. As a result, a CLB connection timeout occurs.

  Note

  The default timeout period is 900 seconds. You can modify this value based on your business requirements.

What are the timeout values specified for HTTP and HTTPS listeners?

• A maximum of 100 requests can be consecutively sent over an HTTP persistent connection. The connection is closed when the limit is reached.

• The timeout period between two HTTP or HTTPS requests over an HTTP persistent connection can be set to a value from 1 to 60 seconds. The actual timeout period may have a time error of 1 or 2 seconds. The TCP connection is closed when the timeout period reaches the specified value. If your customers want to use HTTP persistent connections, configure the clients to send heartbeat requests every 13 seconds or less.

• The timeout period for the TCP three-way handshake between CLB and a backend Elastic Compute Service (ECS) instance is 5 seconds. After the handshake times out, CLB selects the next ECS instance. You can find the timeout record by checking the upstream response time in the access logs.

• The time that CLB waits for the response from an ECS instance can be set to a value that ranges from 1 to 180 seconds. If the wait time reaches the specified timeout period, an HTTP 504 or 408 status code is sent to the client. You can find the timeout record by checking the upstream response time in the access logs.

• After 300 seconds, HTTPS session reuse times out. Then, the client must perform the complete SSL handshake process again.

If a client closes the connection with CLB before the client receives a response, does CLB closes the connection on the backend server side?

No, CLB does not close the connection on the backend server side in this case.

Can I enable persistent connections for my CLB instance?

No, CLB does not support persistent connections.

To implement persistent connections, you can use Application Load Balancer (ALB) instances and you need to deploy and enable Keep-Alive on your backend servers. For detailed instructions, see Create and manage server groups.

Why does session persistence fail in some scenarios?

The possible causes and corresponding solutions are as follows:

• Cause: The session persistence feature is not enabled.

  Solution: Check whether session persistence is enabled for the listener in use.

• Cause: HTTP or HTTPS listeners are used. HTTP and HTTPS listeners cannot persist sessions by inserting cookies into responses that carry 4xx status codes.

  Solution 1: Use TCP listeners instead of HTTP and HTTPS listeners. TCP listeners persist sessions based on client IP addresses.

  Solution 2: Configure backend ECS instances to persist sessions. ECS instances can insert and validate cookies to ensure that sessions are persisted.

• Cause: HTTP or HTTPS listeners are used. HTTP 302 redirects change the SERVERID string for persisting a session. When CLB inserts a cookie into a response that carries the HTTP status code 302, the SERVERID string is changed. As a result, the session cannot be persisted.

  To verify the cause, use a browser or packet capture software to capture requests to and responses from CLB, and check whether a 302 status code is included in the packets and whether the SERVERID string in the cookie is changed.

  Solution 1: Use TCP listeners instead of HTTP and HTTPS listeners. TCP listeners persist sessions based on client IP addresses.

  Solution 2: Configure backend ECS instances to persist sessions. ECS instances can insert and validate cookies to ensure that sessions are persisted.

• Cause: The timeout period is set to a small value.

  Solution: Set the timeout period to a greater value.

How do I view a cookie?

Open your browser and press F12 to check whether SERVERID or a user-defined cookie is inserted into the response. You can also run the curl www.example.com -c /tmp/cookie123 command to save a cookie and then run the curl www.example.com -b /tmp/cookie123 command to view the cookie.

How do I test session persistence by using the Linux curl command?

1. Create a test page.

   Create a test page on each backend ECS instance where you can view the private IP address of the backend server. The following figure shows an example of a test page. The private IP address indicates the backend server to which requests are distributed. The private IP address is used to test whether CLB can persist sessions.

   

2. Run the curl command in Linux.

   In this example, the IP address of the CLB instance that runs Linux is 10.170.XX.XX and the URL of the test page is http://10.170.XX.XX/check.jsp.

   1. Log on to a server that runs Linux.

   2. Run the following command to query the cookie inserted by the backend server:

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      Note

      By default, CLB persists sessions by inserting cookies. However, curl does not send or save cookies. Therefore, you must save a cookie before you perform the test. Otherwise, the curl test result may show that session persistence is invalid.

   3. After you save the cookie, run the following command:

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      Note

      a<=30 indicates the number of tests to be performed. You can set this value based on your business requirements. Set the IP address in grep '10.170.XX.XX' to the private IP address of your ECS instance.

   4. Check the IP addresses that are returned in the preceding tests. If the same IP address is returned, it indicates that CLB can persist sessions.

Why do the style sheets fail to load when I open a website over an HTTPS listener?

Issue:

An HTTP listener and an HTTPS listener are created, and they use the same backend servers. When I access the website over the HTTP listener with the specified port number, the website is displayed. However, the website layout is distorted when I access the website over the HTTPS listener.

Causes:

By default, CLB does not block loading and transferring of JavaScript files. This problem may be caused by the following reasons:

• The certificate is not compatible with the security level of the web browser.

• The certificate is an unqualified third-party certificate. In this case, contact the certificate issuer to check the qualification of the certificate.

Solutions:

1. When you open the website, load scripts as prompted by the browser.

2. Add the required certificate to the browser.

Which version of HTTP is used by HTTP and HTTPS listeners when they access backend servers?

• If requests use HTTP/1.1 or HTTP/2, Layer 7 listeners use HTTP/1.1 to distribute the requests to backend servers.

• If requests use protocols other than HTTP/1.1 and HTTP/2, Layer 7 listeners use HTTP/1.0 to distribute the requests to backend servers.

Can backend servers obtain the protocol version that a client uses to access the HTTP or HTTPS listener?

Yes, they can.

If I enable traffic redirection from an HTTP listener to an HTTPS listener, do I need to deploy certificates on backend servers?

No, you don't. You only need to deploy certificates on CLB and configure the certificate for the HTTPS listener. For detailed instructions, see Configure the SSL certificate.