游戏卡顿白皮书 › TCP 重传的根本原因
流量监管丢弃超额流量 Traffic policing
原因 ID rt-policer · 主责 运维团队·网络运维 · 配合 运维团队·系统运维, 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
运营商套餐限速、云实例上限和 DDoS 防护设备，有时会把超过规定速率的数据包直接丢弃，不放进队列。
起因 瞬时发送量超过允许速率或允许突发量 → 结果 超出的数据包不排队，直接丢弃（流量监管） → 画面表现 每逢突发量大的瞬间就丢好几个包，卡住后表现为快进；平均速率看起来低于上限
- 症状
- 卡住, 快进, 瞬移
- 因素
- 丢包
- 谁会遇到
- 全服, 特定地区/运营商, 只有我
- 何时出现
- 人多的时候, 晚高峰
- 负责方
- 主责 运维团队·网络运维 · 配合 运维团队·系统运维, 研发团队·服务器开发
- 研发团队要做的事
- 把每个 tick 集中发出的量分散到 tick 内发送，让瞬时发送量低于允许突发量；碰到每秒包数上限时，把一个 tick 的消息合并到一个数据包里。
- 运维团队要做的事
- 网络：检查设备的流量监管超限计数器；用流量整形替换流量监管；调大允许突发量。服务器/OS：检查云平台的超限指标（AWS 为 ethtool -S 的 bw_out_allowance_exceeded、pps_allowance_exceeded）；升级实例规格；在服务器上做平滑发送（Linux fq 队列）。
- 数值参考
- 流量整形（放进队列延后发送）会增加延迟，流量监管（直接丢弃）会增加丢包。TCP 游戏连接丢一次包就可能停顿几百 ms，所以只是短暂超出上限时，通常流量监管的影响更大。
- 监控图上
- 触顶后走平 · 短间隔采样的发送量，流量监管和 allowance 超限计数器
- 查看位置
- 看配置了流量监管的设备上的超限（exceed）和丢弃计数器；云上看 ethtool -S 的 bw_out_allowance_exceeded、pps_allowance_exceeded。对发生丢包的连接，用 ss -ti 的 rtt 或抓包查看丢包前一刻的 RTT
- 确认依据
- 超限计数器增加，短间隔采样的发送量在某个值处像被削平一样走平。丢包前 RTT 没有上升，只在突发量大的瞬间多个包同时丢失
- 排除依据
- 丢包前 RTT 先上升，属于队列溢出（“瓶颈队列溢出”“突发发送导致浅缓冲区溢出”）。超限计数器不变则是其他原因
- 确认手段
- 运维工具即可确认（无需游戏代码）
出处
- RFC 2475: An Architecture for Differentiated Services IETF
定义：流量整形把数据包延后，使流量符合规定的流量特征（traffic profile）；流量监管丢弃超出流量特征的数据包 - An Internet-Wide Analysis of Traffic Policing Google
受流量监管的传输丢包率平均高 6 倍，用平滑发送或流量整形可以达到同样目的。区分方法：流量监管在 RTT 不增加的情况下丢弃超额部分，队列溢出则在丢包前 RTT 先上升（SIGCOMM 2016） - Monitor network performance for ENA settings on your EC2 instance AWS
ethtool -S 的 bw_out_allowance_exceeded、pps_allowance_exceeded：因超出实例上限而被排队或丢弃的数据包数 - tc-fq(8) — Linux manual page iproute2
Linux fq 队列的按连接平滑发送 - ss(8) — Linux manual page iproute2
ss -i 的 rtt（平均往返时间）
相关原因
同一层：TCP 重传的根本原因
其他层中同样导致“卡住”的原因
查看含图示和实验的原卡片