游戏卡顿白皮书 › TCP 重传的根本原因
双工不匹配 Duplex mismatch
原因 ID rt-duplex · 主责 运维团队·网络运维 · 配合 运维团队·系统运维
在含图示和实验的完整版中打开此卡片 →
一端用自动协商，另一端把速率和双工写死，就会有一端以半双工工作，每当负载上来就因冲突丢包。
起因 只有一端设备固定了速率和双工 → 结果 一端以全双工、另一端以半双工工作，产生冲突和晚期冲突（late collision） → 画面表现 平时正常，流量一上来，经过这台设备的所有人都先卡住再快进
- 症状
- 卡住, 快进
- 因素
- 丢包
- 谁会遇到
- 全服, 特定地点/分线
- 何时出现
- 人多的时候, 晚高峰
- 负责方
- 主责 运维团队·网络运维 · 配合 运维团队·系统运维
- 运维团队要做的事
- 两端都设为自动协商，或两端都固定为相同的值。网络：在交换机端口状态里确认速率和双工；在端口计数器里确认半双工一端的晚期冲突、全双工一端的 CRC 错误和超短帧（runt）是否增加。服务器/OS：用 ethtool 确认速率和双工。
- 数值参考
- 1 Gbps 电口（铜缆）必须自动协商，10 Gbps 及以上根本没有半双工。所以现在主要出现在 100 Mbps 及以下的老设备、管理口和部分线路对接处。
- 监控图上
- 随人数/负载上升 · 端口晚期冲突数和 CRC 错误数，重传率
- 查看位置
- 看链路两端实际的速率和双工。服务器只带接口名运行 ethtool，交换机看端口状态或 SNMP 的 dot3StatsDuplexStatus。同时看晚期冲突（服务器 tx_window_errors，交换机 dot3StatsLateCollisions）和 CRC 错误
- 确认依据
- 一端显示半双工，另一端显示全双工。每当流量增加，半双工一端的晚期冲突和全双工一端的 CRC 错误一起增加
- 排除依据
- 两端速率和双工一致，只有 CRC 增加，看“物理层错误”。10 Gbps 及以上的链路没有半双工，可排除这个原因
- 确认手段
- 运维工具即可确认（无需游戏代码）
出处
- Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
1000BASE-T 标准要求自动协商 - IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
10G 以太网只支持全双工 - IEEE P802.3ba Objectives IEEE
40G、100G 以太网也只支持全双工 - Interface statistics Linux kernel
tx_window_errors 是因晚期冲突（late collision）而失败的发送次数，rx_crc_errors 是收到的有 CRC 错误的数据包数 - ethtool(8) — Linux manual page ethtool
用 ethtool -s 的 speed、duplex、autoneg 设置速率、双工和自动协商；只给接口名时显示当前设置 - RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
dot3StatsDuplexStatus（用 halfDuplex、fullDuplex 表示当前双工模式），dot3StatsLateCollisions（晚期冲突次数）
相关原因
同一层：TCP 重传的根本原因
其他层中同样导致“卡住”的原因
查看含图示和实验的原卡片