游戏卡顿白皮书 › L5 数据中心网络设备
负载均衡器空闲超时 Load balancer idle timeout
原因 ID dc-lb-idle · 主责 运维团队·网络运维 · 配合 研发团队·客户端开发, 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
负载均衡器会在一段时间后清除空闲连接。游戏这边仍以为连接还在，结果就掉线了。
起因 玩家一段时间内没有发送任何数据包（停在对话框、暂时离开） → 结果 负载均衡器清理空闲连接（常见默认值 60~350 秒） → 画面表现 再次操作的瞬间掉线
- 症状
- 掉线
- 因素
- 丢包
- 谁会遇到
- 只有我, 全服
- 何时出现
- 挂机一段时间后
- 负责方
- 主责 运维团队·网络运维 · 配合 研发团队·客户端开发, 研发团队·服务器开发
- 研发团队要做的事
- 客户端：心跳间隔不超过最短空闲超时的一半（经过 ALB 时，60 秒超时对应 30 秒以内）；断开后自动重连。服务器：响应心跳，一段时间收不到就主动清理连接；凭会话令牌接续会话。
- 运维团队要做的事
- 确认路径上各负载均衡器的空闲超时值并告知研发团队，必要时调大。
- 数值参考
- 默认值：AWS ALB 为 60 秒，NLB 为 TCP 350 秒、UDP 120 秒，Azure Load Balancer 为 TCP 4 分钟。ALB 和 NLB 的 TCP 值可以修改，NLB 的 UDP 120 秒不能改。ALB 超时后会把服务器侧的连接也关掉；NLB 则悄悄清除，服务器往往并不知情。
- 监控图上
- 连接成批断开 · 断开次数、断开前的空闲时长
- 查看位置
- 确认路径上各负载均衡器的空闲超时配置，收集每个断开连接从最后一个包到断开所经过的时间。AWS NLB 还要看 CloudWatch 的 TCP_ELB_Reset_Count（负载均衡器发出的 RST 数）
- 确认依据
- 断开连接的空闲时长集中在配置值（ALB 60 秒、NLB TCP 350 秒等）刚过的位置；静止超过这个时间后再操作即可复现。NLB 在那一时刻 TCP_ELB_Reset_Count 增加
- 排除依据
- 断开与空闲时长无关，则不是这个原因。不经负载均衡器直连的服务器上集中在 350 秒附近，看“云安全组连接跟踪过期”；问题在玩家家用路由器一侧，看“NAT 映射过期”
- 确认手段
- 运维工具即可确认（无需游戏代码）
出处
- Edit attributes for your Application Load Balancer AWS
ALB 空闲超时默认 60 秒（1~4,000 秒），客户端侧或目标侧连接在这段时间内没有数据，负载均衡器就关闭连接 - Network Load Balancers AWS
NLB TCP 空闲默认 350 秒（60~6,000 秒），超时后只停止跟踪，之后再有数据到来就回 RST；UDP 流的 120 秒不可修改 - Configure load balancer TCP reset and idle timeout Microsoft Azure
Azure Load Balancer 空闲超时默认 4 分钟（4~100 分钟），超过后不保证会话保持；TCP 重置为可选设置 - CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count：负载均衡器自己生成并发出的 RST 包数
相关原因
同一层：L5 数据中心网络设备
其他层中同样导致“掉线”的原因
查看含图示和实验的原卡片