ACK 延迟或丢失（上行饱和） ACK path congestion on asymmetric links

原因 ID rt-ack-path · 主责 外部·外部 · 配合研发团队·客户端开发

数据已经顺利到达，但表示“已收到”的 ACK 在塞满的上行队列里被耽搁或丢掉，发送方就会判定为丢包并重传。

起因家里在上传视频或做云备份，上行被占满 → 结果 ACK 在路由器队列里被耽搁几百 ms，或因队列溢出被丢弃 → 画面表现 服务器发来的游戏包大多能按时到。堆在同一上行队列里的自己的输入被耽搁，出现操作延迟、拉回，偶尔有虚假重传

症状: 操作延迟, 拉回
因素: 延迟, 丢包
谁会遇到: 同一家庭
何时出现: 偶尔随机, 晚高峰
负责方: 主责 外部·外部 · 配合研发团队·客户端开发
研发团队要做的事: ping 飙升时在画面上显示网络状态，并弹出“检查正在上传的程序”的提示。
外部要做的事: 引导玩家用路由器 SQM 缩短上行队列，优先处理小包（ACK），给视频上传、云备份限速。
数值参考: 后面的 ACK 能替前面的 ACK 完成确认，所以丢几个通常没关系。真正的问题是在队列里被耽搁。
监控图上: 仅部分偏高 · 每个连接的 RTT（ping）
查看位置: 在玩家 PC 上分别于开启上传（视频上传、云备份）和关闭上传时 ping 游戏服务器，比较两者结果。服务器上用 ss -ti 看该玩家连接的 rtt
确认依据: 只在上传期间 ping 升到几百 ms，出现操作延迟和拉回，停止上传后很快恢复。从服务器看，那段时间该连接的 rtt 也一起上升
排除依据: 与上传无关也出现丢包和延迟，看“无线链路丢包”或路径方面的原因。只有服务器到玩家方向慢，且与上传无关，看“瓶颈队列溢出”
确认手段: 需在玩家侧环境确认

出处

RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF
在上行窄的非对称线路上，ACK 延迟或丢失会降低 TCP 性能；ACK 是累积确认，丢掉一部分也有后面的 ACK 补上；对策有 ACK 优先调度等
Smart Queue Management Bufferbloat.net
在路由器上用队列管理和流量整形让队列保持较短
tc-cake(8) — Linux manual page iproute2
CAKE 按流划分，把稀疏发送的流（sparse flow）的延迟降到最低
ss(8) — Linux manual page iproute2
ss -i 的 rtt（平均往返时间）和 rttvar（偏差）