游戏卡顿白皮书 › TCP 重传的根本原因
物理层错误（线缆/光模块/连接器不良） Bit errors: bad cable, optics, dirty fiber
原因 ID rt-physical · 主责 运维团队·网络运维 · 配合 运维团队·系统运维, 外部·外部
在含图示和实验的完整版中打开此卡片 →
线缆损坏、光纤连接器积灰、光模块老化都会产生误码，损坏的数据包会被设备悄无声息地丢弃。
起因 线缆、光模块或连接器不良，导致比特翻转 → 结果 设备丢弃校验和（CRC）不对的数据包 → 画面表现 只有经过这条路径的玩家反复顿一下再快进，与时段无关
- 症状
- 卡住, 快进, 瞬移
- 因素
- 丢包
- 谁会遇到
- 特定地点/分线, 同一家庭
- 何时出现
- 一直
- 负责方
- 主责 运维团队·网络运维 · 配合 运维团队·系统运维, 外部·外部
- 运维团队要做的事
- CRC 错误记在出错方向的接收端，所以两端都要查。网络：检查设备端口的 CRC 和入方向错误计数器；检查光功率（交换机上的光模块信息）；清洁光纤连接器；更换线缆或光模块。服务器/OS：检查服务器 ethtool -S 的 rx_crc_errors（各驱动的名称略有不同）；检查光功率（ethtool -m）；更换服务器侧线缆或网卡。
- 外部要做的事
- 问题在玩家家中时，引导玩家更换网线或路由器；在运营商线路上时，要求运营商检修线路。
- 数值参考
- 即使只有 0.1% 的丢包，也是每 1,000 个游戏数据包丢一次。经过这条路径的玩家有几十人时，每隔几秒就会有人顿一下。包越大，越容易碰上误码。
- 监控图上
- 仅部分偏高 · 各端口的 CRC 错误数，各服务器、各端口的重传率
- 查看位置
- 看链路两端的 CRC 计数器。服务器看 ethtool -S 的 rx_crc_errors 或 ip -s -s link 的 crc，交换机看端口的 FCS 错误（dot3StatsFCSErrors）和入方向错误（ifInErrors）。光链路用 ethtool -m 和交换机的光模块信息查看接收光功率
- 确认依据
- 某个端口的 CRC 错误不分时段持续增加，只有经过该端口的服务器和连接重传率高。接收光功率比同类其他链路低
- 排除依据
- CRC 不变，只有出方向丢弃增加，属于队列溢出（“突发发送导致浅缓冲区溢出”“瓶颈队列溢出”）。一端的晚期冲突和另一端的 CRC 同时增加，看“双工不匹配”
- 确认手段
- 运维工具即可确认（无需游戏代码）
出处
- Interface statistics Linux kernel
rx_crc_errors 是接收端接口因 CRC 错误计数的数据包数，可用 ip -s -s link 和 ethtool -S 查看 - ethtool(8) — Linux manual page ethtool
用 -S 查看各网卡、驱动的统计，用 -m 查看光模块（SFP+、QSFP）的 EEPROM 和光诊断信息 - RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
交换机端口的 FCS 错误（dot3StatsFCSErrors），这类错误计入入方向错误（ifInErrors）
相关原因
同一层：TCP 重传的根本原因
其他层中同样导致“卡住”的原因
查看含图示和实验的原卡片