游戏卡顿白皮书 › L4 公网链路
ECMP 单条路径故障 ECMP / link bundle member fault
原因 ID isp-ecmp · 主责 运维团队·网络运维 · 配合 研发团队·服务器开发, 外部·外部
在含图示和实验的完整版中打开此卡片 →
运营商和数据中心通往同一目的地的路径往往有多条，每个连接固定走其中一条。只要有一条路径出故障，分到这条路径上的人就会一直卡。
起因 在多条线路捆绑的链路上，某一条线路或某台设备故障或拥塞 → 结果 路径按地址、端口组合（哈希）确定，只有分到该路径的连接出现丢包和延迟 → 画面表现 同一地区、同一运营商，只有部分人持续瞬移。重新连接后有时会恢复正常
- 症状
- 瞬移, 拉回, 一卡一卡
- 因素
- 丢包, 抖动
- 谁会遇到
- 只有我, 特定地区/运营商
- 何时出现
- 一直
- 负责方
- 主责 运维团队·网络运维 · 配合 研发团队·服务器开发, 外部·外部
- 研发团队要做的事
- 按连接记录丢包和重传统计，以便提取受影响玩家的 IP、端口和时间（TCP 用 TCP_INFO 里的重传次数，UDP 按缺失的包序号计算）。
- 运维团队要做的事
- 收集受影响玩家的 IP、端口和时间，转交给运营商或数据中心；按路径监控丢包；路径测量要用和游戏相同的协议、端口（mtr --tcp、--udp 加 --port）；如果是我方设备上的路径，就把故障线路或设备从捆绑组中摘除。
- 外部要做的事
- 请运营商确认并更换故障路径；引导玩家通过重新连接临时避开（重连后端口会变的情况下）。
- 数值参考
- 有 4 条路径时，只有约四分之一的用户会遇到。ping 测量可能走的是和游戏不同的路径，结果反而正常。
- 监控图上
- 仅部分偏高 · 各连接的丢包、重传（按 IP/端口）
- 查看位置
- 按源 IP、源端口拆分查看各连接的丢包和重传；用 mtr 以 UDP（-u）发往游戏端口（-P），并固定源端口（-L）测量，再换几个源端口重复多次。只给 -P 不给 -L 时，每个请求的源端口都会变，多条路径的结果会混在一起
- 确认依据
- 同一地区、同一运营商内，只有特定的源端口（或地址）组合持续丢包，重新连接换了端口后恢复正常
- 排除依据
- 换了端口仍然都差，是某一段整体拥塞或故障
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 深入了解
- 为了不打乱同一连接内数据包的顺序，设备会按地址和端口（视设备配置，也可能只用地址）算出的值，给每个连接固定一条路径（ECMP、LAG）。只用地址计算的地方，重新连接也还是同一条路径，不会好转。所以同时收到“ping 正常，只有游戏卡”“重连之后好了”这类反馈时，就要怀疑这个原因。
出处
- RFC 7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks IETF
LAG、ECMP 用报头字段的哈希为每个流指定一条链路，以保证包序（流→链路为多对一映射） - RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
区分流的依据因实现而异（只看目的地址、看地址对、连端口一起看）；多路径下 ping、traceroute 的结果难以信任 - mtr(8) manual page source mtr
-u（UDP）、-P（目的端口）、-L（UDP 源端口）选项；只给 -P 时会把请求序号填进源端口，每个请求都不同
相关原因
同一层：L4 公网链路
其他层中同样导致“瞬移”的原因
查看含图示和实验的原卡片