负载均衡超时问题

最近更新时间:2021-06-25 15:25:32

查看PDF

1.负载均衡各类型监听连接超时时间如下

TCP 900秒

UDP 120秒

HTTP 300秒

HTTPS 300秒

注:当前负载均衡未开放超时时间给用户自行设置

2. HTTP Keep-alive 超时时间

如果客户端访问 SLB HTTP 监听时使用长连接, 那么这条连接最长的空闲时间为 300 秒, 即如果超过 300 秒没有发送任何 HTTP 请求, 这条连接将会被 SLB 主动断开。如果您的业务可能会出现超过 300 秒的空闲, 需要检测连接的断开并重新发起连接。

3.为什么会碰到 VIP 连接访问超时?

注:访问超时场景很多,本文档主要是从服务端入手分析

CASE 1 VIP 被安全防护

如流量黑洞和清洗,WAF 防护(waf 的特点是为建连后向 client 和 lvs 双向发送rst 报文)

CASE 2 客户端端口不足

尤其容易发生在压测的时候,客户端端口不足会导致建立连接失败,负载均衡默认会抹除 tcp 连接的 timestamp 属性,linux 协议栈的 tw_reuse ( time_wait 状态连接复用)无法生效,time_wait 状态连接堆积导致客户端端口不足

解决方法:

客户端端使用长连接代替短连接。

使用 RST 报文断开连接( socket 设置 SO_LINGER 属性) ,而不是发 FIN 包这种方式断开。

CASE 3 后端服务器 accept 队列满

后端服务器 accept 队列满,导致后端服务器不回复 syn_ack 报文,客户端超时。

解决方法:默认的 net.core.somaxconn 参数为 128 ,执行 sysctl -w net.core.somaxconn=1024 或者其它更大的值,并重启后端服务器上的应用。

CASE 4 从4层负载均衡后端服务器访问该4层负载均衡 VIP

4 层负载均衡,在该负载均衡的后端服务器上再去访问该负载均衡 VIP,这个目前是无法支持的,会导致连接失败,常见的场景是用户后端应用使用 URL 拼接的方式跳转访问

CASE 5 对连接超时的 rst 处理不当

负载均衡上建立 TCP 连接后如果 900s 未活动,则会向 client 和 rs 双向发送 rst 断开连接,有的应用对 rst 异常处理不当,可能会对已关闭的连接再次发送数据导致应用超时
_注: 这种情况建议调整 后端主机 系统内核参数 net.ipv4.tcp_keepalive_time 为小于 900s 的值。

文档内容是否对您有帮助?

根本没帮助
文档较差
文档一般
文档不错
文档很好

在文档使用中是否遇到以下问题

内容不全,不深入
内容更新不及时
描述不清晰,比较混乱
系统或功能太复杂,缺乏足够的引导
内容冗长

更多建议

0/200

评价建议不能为空

提交成功!

非常感谢您的反馈,我们会继续努力做到更好!

问题反馈