负载均衡：负载均衡服务FAQ

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

支持。

具体操作，请参见配置监听转发（redirect）。

禁用公网网卡是否影响负载均衡服务？

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

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

在部分特殊场景中，为什么会出现连接达不到带宽峰值的现象？

• 场景描述：当购买公网CLB且公网计费方式为按固定带宽时，单客户端压测或单客户端传输超大数据包等特殊场景下，可能会出现连接达不到带宽峰值的现象。
• 原理（原因）：

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

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

• 推荐方案：
  • CLB实例的公网计费方式使用按流量计费。
  • 使用NLB或ALB实例，且搭配EIP和共享带宽。此种方案下负载均衡实例具有足够的弹性，不会出现此类问题。

在部分特殊场景中，为什么CLB实例达不到QPS峰值？

• 场景描述：在使用少量长连接的业务场景下，转发分组中的系统服务器可能不会全部被分配到长连接，可能会出现CLB实例达不到QPS峰值的现象。
• 原理（原因）：

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

  单个系统服务器的QPS上限计算方法为：单个系统服务器QPS峰值=实例总QPS/（N-1）。N为转发分组中系统服务器的个数。例如您在控制台上购买了简约型I（slb.s1.small）规格的CLB实例，对应的QPS为1000，当多客户端同时使用时，总QPS可以达到1000 QPS。若系统服务器个数为8，那么单个系统服务器的最大QPS为1000/(8-1)=142 QPS。

• 推荐方案：
  • 使用单客户端短连接进行压测。
  • 根据实际业务情况减少连接复用。
  • 升配CLB实例规格。具体操作，请参见按量付费（按规格计费）升降配。
  • 使用ALB实例，此种方案下负载均衡实例具有足够的弹性。

负载均衡各监听支持的连接超时时间范围是多少？

• TCP监听连接超时时间：10~900秒
• HTTP监听：
  • 连接空闲超时时间：1~60秒。
  • 连接请求超时时间：1~180秒。
• HTTPS监听：
  • 连接空闲超时时间：1~60秒。
  • 连接请求超时时间：1~180秒。

为什么负载均衡服务地址会连接访问超时？

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

• 服务地址被安全防护

  如流量黑洞和清洗，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访问。

如何使用Linux curl测试负载均衡会话保持？

1. 创建测试页面。

   在负载均衡所有后端ECS中创建测试页面，如下图所示页面中能显示本机内网IP。内网IP用于判断相应请求被指派到的物理服务器。通过观察该IP的一致性，来判断负载均衡会话保持的有效性。

   
2. 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字段？

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

CLB开启WAF防护的使用说明？