游戏卡顿白皮书 › TCP 重传的根本原因
中间设备超出处理上限（防火墙/IPS/DDoS 防护） Inline appliance PPS / CPU overload
原因 ID rt-appliance-pps · 主责 运维团队·网络运维 · 配合 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
防火墙、入侵防御设备（IPS）、DDoS 防护设备会逐个检查经过的数据包。一旦超出检测能力，处理不过来的包就会被丢弃。
起因 高峰时段或活动期间，体积小的游戏数据包每秒涌入几十万个以上，或检测规则太重 → 结果 设备的 CPU 或每秒包数上限被打满，在设备上丢弃。误判时正常数据包也会被拦截 → 画面表现 这台设备后面的所有服务器同时出现卡住、瞬移，只在人多时加重
- 症状
- 卡住, 快进, 瞬移, 掉线
- 因素
- 丢包, 延迟
- 谁会遇到
- 全服, 特定地区/运营商
- 何时出现
- 晚高峰, 人多的时候
- 负责方
- 主责 运维团队·网络运维 · 配合 研发团队·服务器开发
- 研发团队要做的事
- 把游戏流量模式（端口、包大小、每秒包数）同步给运维团队；一个 tick 内要发的小消息攒起来一次发出，减少包数。
- 运维团队要做的事
- 把设备的 CPU、每秒包数、丢弃计数器与游戏指标放在一起看；按小包规划设备容量；让游戏端口跳过重度检测；按游戏流量模式调整 DDoS 防护规则。
- 数值参考
- 设备规格里的“10 Gbps”多半是按 1,500 字节的大包标的。游戏数据包只有 100 字节左右，同样的带宽下包数要多 10 倍以上，所以线路看着很空闲，每秒包数上限却先被打满。
- 监控图上
- 触顶后走平 · 设备每秒包数和 CPU 利用率，设备丢弃数
- 查看位置
- 看设备的 CPU、每秒包数和丢弃计数器，并按相同间隔比较设备前后交换机端口的包数。与同时在线人数、服务器重传率叠加在同一张图上看
- 确认依据
- 高峰或活动时，设备的每秒包数或 CPU 停在某个值上不去，出设备的包比进设备的少，同一时刻其后所有服务器的重传率一起上升
- 排除依据
- 设备前后包数一致，设备也没有丢弃，则是其他原因。服务器的网卡丢弃计数器或 softnet dropped 增加，看“接收端服务器主机丢包”
- 确认手段
- 运维工具即可确认（无需游戏代码）
出处
- RFC 2544: Benchmarking Methodology for Network Interconnect Devices IETF
设备性能要用包括最小和最大尺寸在内的多种帧长测试（处理性能随包大小而变）
相关原因
同一层：TCP 重传的根本原因
其他层中同样导致“卡住”的原因
查看含图示和实验的原卡片