- Does SLB support HTTP redirection?
- If I disable the public NIC, will my SLB service be affected?
- Why are my connections unable to reach the peak bandwidth value?
- What are the timeout values of each listener?
- Why does my SLB connection time out?
- Why does session persistence sometimes fail?
- How do I view the session persistence string?
- How do I test session persistence by using Linux curl?
- If I disconnect my client from SLB before I receive a response from the backend servers, will SLB disconnect from the backend servers?
Does SLB support HTTP redirection?
Yes. SLB supports HTTP redirection.
For more information, see Redirect HTTP requests to HTTPS.
If I disable the public NIC, will my SLB service be affected?
If the ECS instance is configured with a public IP address, disabling the public NIC will impact the SLB service.
Traffic goes through the public NIC by default if the backend ECS instance is configured with a public IP address. If the public NIC is disabled, no packets are returned. We recommend you do not disable the public NIC. But if you have to, you can direct the default route to the intranet to avoid the impact on the service. You also need to consider whether your service is Internet-dependent, such as accessing RDS over the Internet.
Why are my connections unable to reach the peak bandwidth value?
Because SLB instances work based on SLB server clusters. All external requests are evenly distributed to SLB system servers. Therefore, the specified peak bandwidth is also evenly distributed to these servers.
The calculation method of the traffic ceiling for a single connection download is: Single connection download peak bandwidth = The specified peak bandwidth of the SLB instance/(N-1). N is the number of traffic forwarding groups, and the current value is 4. For example, if you set the peak bandwidth to 10 Mbit/s in the SLB console, the maximum download bandwidth value of each client is 10/(4-1), which equals 3.33 Mbit/s.
Considering the preceding working principle of SLB, we recommend you set an appropriate peak bandwidth value for a single listener based on your service conditions and application modes to avoid impacts on your service.
What are the timeout values of each listener?
- TCP listener: 900 seconds
- UDP listener: 90 seconds
- HTTP listener: 60 seconds
- HTTPS listener: 60 seconds
Why does my SLB connection time out?
With respect to SLB servers, possible causes are as follows:
- The IP address of the SLB instance is blocked for security reasons.
The IP address of the SLB instance may be blocked due to traffic blackholing and scrubbing, or WAF protection which sends RST packets to both the client and the server after a connection is established.
- Insufficient client ports
Insufficient client ports may lead to connection failures especially in stress tests. In detail, the timestamp attribute of TCP connections is erased by SLB by default. As a result, tw_reuse of Linux protocol stack (reuse of ports in time_wait state) does not work, and connections in time_wait state accumulate, resulting in a lack of client ports.
Solution: We recommend that you enable persistent connections on clients and use RST packets instead of FIN packets to terminate connections.
- The backend server accept queue is full.
If the backend server accept queue is full, the backend server does not respond with the syn_ack packet and the client times out.
Solution: Run the command
sysctl -w net.core.somaxconn=1024to change the value of net.core.somaxconn and restart the application on the backend server. The default value of net.core.somaxconn is 128.
- The layer-4 SLB service is accessed from backend servers.
For the layer-4 SLB service, the connection fails if you access the service from a backend server.
- Improper RST configuration
If no data is transferred within 900 seconds after a TCP connection is established on SLB, SLB sends the RST packet to the client and the backend server to terminate the connection. If the RST configuration is not correct on the backend server, the backend server may send data to the closed connection, which leads to a connection timeout.
Why does session persistence sometimes fail?
- Make sure that you have enabled session persistence.
- HTTP/HTTPS listeners cannot insert the cookies needed for session persistence into
the 4xx code messages returned by backend servers.
Solution: Change HTTP/HTTPS listeners to TCP listeners. Session persistence in TCP listeners is based on source client IP addresses, which means cookies can be inserted in backend servers.
- An HTTP 302 redirect changes the SERVERID string in the session persistence.
When SLB inserts a cookie to the response of the backend ECS instance, if the HTTP status code 302 redirect is also returned by the ECS instance, the SERVERID string for session persistence will be changed, resulting in a session persistence failure.
To verify the cause, check the requests and responses in your browser or by using packet checking software. Then, check whether a 302 code is included in the packets and whether the SERVERID string in the cookie is changed.
Solution: Use TCP listeners. Session persistence in TCP listeners is based on source client IP addresses, which means cookies can be inserted into backend servers.
- The timeout period is too short. You can modify the timeout period to a greater value.
How do I view the session persistence string?
You can press F12 in your browser to check whether the SERVERID string or any keywords
that you specified are included in the response message. Alternatively, you can run
curl www.xxx.com -c /tmp/cookie123 to save the cookie and then run
curl www.xxx.com -b /tmp/cookie123 to visit the cookie.
How do I test session persistence by using Linux curl?
- Create a test page.
Create a test page on each of the backend ECS instances and make sure that the intranet IP address of the server is displayed on the test page. The following figure shows an example of a test page. The intranet IP address is used to verify the backend server to which client requests are distributed. You can check whether the intranet IP addresses are the same to determine whether session persistence works.
- Test using curl.
In this example, the IP address of the SLB instance running Linux is 18.104.22.168 and the URL of the created page is http://22.214.171.124/check.jsp.
- Log on to the Linux server used for the test.
- Run the following command to check the value of the cookie inserted in the server.
curl -c test.cookie http://126.96.36.199/check.jspNote By default, SLB maintains session persistence by inserting cookies. However, curl does not save or send any cookies. Therefore, you must save the corresponding cookie first. Otherwise, the curl test result may mistakenly determine that session persistence has failed.
- Run the following command to continue the test.
for ((a=1;a<=30;a++)); 2="" do="" curl="" -b="" 1.cookie="" check.jsp="">/dev/null | grep '10.170.*';sleep 1; done`Note In a<=30, 30 is the number of repeated tests and can be changed to your required testing number. In grep ‘10.170.*’, 10.170. * is the IP address to be searched and you can change it to the intranet IP address of your server.
- Check the IP addresses returned by the preceding tests. If they are the same address, then session persistence is working. If the addresses are different, session persistence has failed.
If I disconnect my client from SLB before I receive a response from the backend servers, will SLB disconnect from the backend servers?
No. SLB does not disconnect from backend servers during read/write operations.