负载均衡服务FAQ - 负载均衡

包含以下问题：

传统型负载均衡CLB是否支持端口跳转？

支持。

如果ECS有公网IP，禁用公网网卡会影响负载均衡服务。

因为在有公网网卡的情况下，默认路由会走公网，禁用后无法回包从而影响负载均衡服务。建议不要禁止公网网卡，如一定要禁止，需要修改默认路由为私网才会不影响服务，但需要考虑业务是否对公网有依赖，如通过公网访问RDS等。

因为负载均衡系统通过集群部署的方式为负载均衡实例提供服务，所有外部的访问请求都将平均分散到这些负载均衡系统服务器上进行转发。所以，设定的带宽峰值将被平均设定在多台系统服务器上。

单个连接下载的流量上限计算方法为：单个连接下载峰值=设置的负载均衡总带宽/(N-1)。N为流量转发分组个数，当前值固定为4。例如您在控制台上设置的是10 Mbps带宽上限，那么单个客户端可下载的最大流量为10/(4-1)=3.33 Mbps。

基于负载均衡的实现原理，建议在配置单个监听的带宽峰值时根据您实际的业务情况并结合其实现方式来设定一个较为合理的值，从而确保您业务的正常对外服务不会受到影响和限制。

从服务端分析，以下情况会导致服务地址连接访问超时：

服务地址被安全防护
如流量黑洞和清洗，WAF防护（WAF的特点是建连后向客户端和服务器集群双向发送RST报文）。
客户端端口不足
尤其容易发生在压测的时候，客户端端口不足会导致建立连接失败，负载均衡默认会抹除TCP连接的timestamp属性，Linux协议栈的tw_reuse（time_wait状态连接复用）无法生效，time_wait状态连接堆积导致客户端端口不足。

解决方法：客户端使用长连接代替短连接。使用RST报文断开连接（socket设置SO_LINGER属性），而不是发FIN包这种方式断开。
后端服务器accept队列满
后端服务器accept队列满，导致后端服务器不回复syn_ack报文，客户端超时。

解决方法：默认的net.core.somaxconn的值为128，执行sysctl -w net.core.somaxconn=1024更改它的值，并重启后端服务器上的应用。
从四层负载均衡后端服务器访问该四层负载均衡的服务地址
四层负载均衡，在该负载均衡的后端服务器上去访问该负载均衡的服务地址会导致连接失败，常见的场景是后端应用使用URL拼接的方式跳转访问。
对连接超时的RST处理不当
负载均衡上建立TCP连接后，如果900秒未活动，则会向客户端和服务器双向发送RST断开连接，有的应用对RST异常处理不当，可能会对已关闭的连接再次发送数据导致应用超时。

查看是否在监听配置中已经开启了会话保持功能。
HTTP或HTTPS监听在后端服务器返回4xx响应码的报文中无法插入会话保持所需Cookie。
解决方案：改用TCP监听，因为TCP监听是以源客户端的IP来做会话保持的，另外后端ECS上也可以插入Cookie，并增加Cookie的判断来多重保障。
302重定向会改变会话保持中的SERVERID字串。
负载均衡植入Cookie时，如果后端ECS中有回复302重定向的报文，将改变会话保持中的SERVERID字串，导致会话保持失效。

排查方法：在浏览器端捕抓请求与响应的回复，或用抓包软件抓包后分析是否存在302的响应报文，对比前后报文的Cookie中的SERVERID字串是否不同了。

解决方案：改用TCP监听，因为TCP监听是以源客户端的IP来做会话保持的，另外后端ECS上也可以插入Cookie，并增加Cookie的判断来多重保障。
会话保持时间设置过小，会话保持时间过小也会导致会话保持失败。

可以在浏览器中用F12查看回应报文中是否含有SERVERID字符串或用户指定的关键字，或者运行curl www.example.com -c /tmp/cookie123 保存一下Cookie，再用 curl www.example.com -b /tmp/cookie123访问。

创建测试页面。
在负载均衡所有后端ECS中创建测试页面，如下图所示页面中能显示本机内网IP。内网IP用于判断相应请求被指派到的物理服务器。通过观察该IP的一致性，来判断负载均衡会话保持的有效性。
Linux系统内执行curl命令。
假设负载均衡服务IP地址是 10.170.XX.XX，创建的测试页面URL为： http://10.170.XX.XX/check.jsp。
1. 登录用来测试的Linux服务器。
2. 执行以下命令查询负载均衡服务器Cookie值。
```
curl -c test.cookie http://10.170.XX.XX/check.jsp
```
  说明阿里云负载均衡会话保持默认模式是植入Cookie，而curl测试默认不会保存和发送Cookie，所以必须先保存相应的Cookie，用于Cookie测试。否则，curl测试结果是随机的，会误认为负载均衡会话保持无效。
3. 执行以下命令持续测试。
```
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
```
  说明 a≤30是重复测试次数，可以按需修改。grep '10.170.XX.XX' 是筛选显示的IP信息，根据后端ECS内网IP情况进行相应修改。
4. 观察上述测试返回的IP，如果是同一台ECS内网IP，则证明负载均衡会话保持有效；反之则证明负载均衡会话保持有问题。

负载均衡在读写过程中不会断开与后端服务器的连接。

默认不支持。客户端请求自带的TOA（TCP Option Address）字段会与负载均衡内部交互使用的TOA字段冲突，导致无法获取客户端的真实IP地址。

但您可以通过以下方法来获取客户端的真实IP：