한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

云安全组连接跟踪过期 Cloud security group connection tracking timeout

原因 ID dc-cloud-conntrack · 主责 运维团队·系统运维 · 配合研发团队·客户端开发, 研发团队·服务器开发

云服务器上挂载的防火墙（安全组）同样会跟踪连接，空闲连接的跟踪条目到了规定时间就会过期。即使服务器不经负载均衡器、由玩家直接连接，挂机一段时间的玩家也可能掉线。

起因安全组采用会跟踪游戏连接的配置（只放行特定地址、限制出站规则、经由 NLB 等） → 结果连接空闲一段时间后跟踪条目过期，之后到达的数据包被安全组悄悄丢弃 → 画面表现 暂时离开后再操作，先是没有反应，随后掉线。服务器程序很长时间都察觉不到

症状: 掉线
因素: 丢包
谁会遇到: 只有我, 全服
何时出现: 挂机一段时间后
负责方: 主责 运维团队·系统运维 · 配合研发团队·客户端开发, 研发团队·服务器开发
研发团队要做的事: 客户端：心跳间隔不超过最短空闲超时的一半（TCP 为 350 秒时即 175 秒以内，UDP 流为 180 秒时即 90 秒以内）；断开后自动重连。服务器：响应心跳，一段时间收不到就主动清理连接；凭会话令牌接续会话。
运维团队要做的事: 确认实例的连接跟踪时长（TcpEstablishedTimeout），必要时调大（UDP 最大就是 180 秒，无法再调大）；评估不产生跟踪的安全组配置（游戏端口对所有地址放行，出站规则全部放行。经由 NLB 的连接仍会被跟踪）；迁移到新一代实例时做空闲测试。
数值参考: 以 AWS 为例，Nitro v6 实例类型默认在 350 秒后清除空闲 TCP 连接的跟踪条目（其他类型为 5 天）。UDP 方面，请求和响应往返多次的流（stream）默认 180 秒，只朝一个方向发送或请求/响应只有一次的流默认 30 秒。
监控图上: 连接成批断开 · 断开次数、断开前的空闲时长
查看位置: 确认实例的连接跟踪时长配置和安全组规则（是否属于会产生跟踪的配置），收集断开连接的空闲时长。刚断开时在服务器上用 ss -tnoi 看该连接是否仍停留在 ESTABLISHED、重传定时器（timer:(on,…)）在运转且 backoff 不断变大
确认依据: 断开连接的空闲时长集中在 TCP 350 秒、UDP 流 180 秒、UDP 单向 30 秒刚过的位置；服务器侧 socket 没察觉到断开，仍停留在 ESTABLISHED（服务器有数据要发时只会反复重传）
排除依据: 安全组属于不跟踪的配置（游戏端口对所有地址放行、出站规则全部放行、不经由 NLB），则不是这个原因。经由 NLB 时，与“负载均衡器空闲超时”的值对比
确认手段: 运维工具即可确认（无需游戏代码）

出处

Amazon EC2 security group connection tracking AWS
TCP 空闲跟踪默认 350 秒（Nitro v6；其他类型为 432,000 秒=5 天），UDP 单向 30 秒、流 180 秒（最大 180），规则放行所有地址时不跟踪，经由 NLB 的连接始终被跟踪
Update the TCP idle timeout for your Network Load Balancer listener AWS
NLB 空闲超时长于目标实例的连接跟踪时长时，实例一侧会先悄悄丢掉连接状态
ss(8) — Linux manual page iproute2
-o 输出中的 timer:(on,…) 表示重传定时器，-i 输出中的 backoff 是重传等待时间翻倍的次数

云安全组连接跟踪过期 Cloud security group connection tracking timeout

出处

相关原因

同一层：L5 数据中心网络设备

其他层中同样导致“掉线”的原因