游戏卡顿白皮书 › L5 数据中心网络设备
MTU 不匹配（只有大包丢失） MTU black hole
原因 ID dc-mtu · 主责 运维团队·网络运维 · 配合 运维团队·系统运维, 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
中间某段的 MTU（一次能发送的最大尺寸）变小，而包过大通知又被拦截时，只有大包会一直丢失。
起因 隧道、VPN 段的 MTU 变小 → 结果 包过大通知（ICMP）被防火墙拦截，发送方不知情 → 画面表现 只有打开背包、角色列表这类数据量大的界面时才卡住，随后掉线
- 症状
- 卡住, 掉线, 连不上/无限加载
- 因素
- 丢包
- 谁会遇到
- 特定地区/运营商, 只有我
- 何时出现
- 做特定操作时, 刚登录/维护结束后
- 负责方
- 主责 运维团队·网络运维 · 配合 运维团队·系统运维, 研发团队·服务器开发
- 研发团队要做的事
- 要在服务器侧直接调小，就设置 socket 的最大报文段长度 TCP_MAXSEG（只在游戏代码里把消息切小防不住）；UDP 包保持在 1,200 字节以内。
- 运维团队要做的事
- 网络：在隧道段调小 TCP 包大小（MSS 调整）；在防火墙、云网络 ACL 中放行包过大通知（ICMP）。服务器/OS：服务器防火墙、云安全组同样放行包过大通知（ICMP）；开启服务器内核的 MTU 探测（tcp_mtu_probing=1），这是停顿几秒后才会生效的最后一道保险。
- 数值参考
- 通常为 1,500 字节，经过隧道后会降到 1,400 左右。
- 监控图上
- 仅部分偏高 · 按地区/运营商的掉线数、大响应失败数
- 查看位置
- 在出问题的玩家电脑上向服务器发送带“禁止分片”标志（DF）的 ping，并不断改变包大小。Windows 用 ping /f /l 1472 SERVER_IP，Linux 用 ping -M do -s 1472 SERVER_IP（1,472 是 MTU 1,500 减去 IP 头 20 字节和 ICMP 头 8 字节后的值）。逐步减小尺寸，找出能通过的最大值；并确认服务器侧安全组、防火墙是否放行 ICMP 包过大通知（Fragmentation Needed）
- 确认依据
- 小 ping 能通，1,472 字节的 DF ping 却失败（无响应，或报需要分片的错误），能通过的最大尺寸只有 1,400 左右。同一地区的玩家只在打开数据量大的界面时卡住
- 排除依据
- 1,472 字节的 DF ping 也能通，则不是路径 MTU 问题。小 ping 也不通，说明 ICMP 本身被拦截，用这个方法无法判断
- 确认手段
- 需在玩家侧环境确认
出处
- RFC 2923: TCP Problems with Path MTU Discovery IETF
防火墙拦截 ICMP（Fragmentation Needed）时路径 MTU 发现失败，只有大包一直丢失（黑洞）；ping 和小数据量通信正常，因此难以诊断 - Maximum transmission unit and maximum segment size Cloudflare
互联网路径 MTU 为 1,500，经过 GRE 隧道后为 1,476；建议把 TCP MSS 限制在 1,436 以下 - IP Sysctl Linux kernel
tcp_mtu_probing=1 时平时不启用，检测到 ICMP 黑洞后才开启 TCP 路径 MTU 探测 - ping(8) — Linux manual page iputils
-M do 设置 DF 标志，拒绝发送大于路径 MTU 的包；-s 指定数据大小（默认 56 字节，另加 8 字节 ICMP 头） - ping Microsoft
/f 设置 DF 标志，用于排查路径 MTU 问题；/l 指定数据大小
相关原因
同一层：L5 数据中心网络设备
其他层中同样导致“卡住”的原因
查看含图示和实验的原卡片