ACK 延遲或消失（上傳飽和） ACK path congestion on asymmetric links

原因 ID rt-ack-path · 主要負責 外部（外部） · 協同遊戲開發團隊（用戶端開發）

資料已順利送達，但「收到了」的 ACK 在塞滿的上傳佇列裡延遲或消失時，傳送端會判斷為遺失而重傳。

為什麼 家中有人上傳影片或做雲端備份，把上傳頻寬塞滿 → 於是 ACK 在分享器佇列裡延遲數百 ms，或因溢位而被丟棄 → 畫面上 伺服器送來的遊戲封包大致準時到達。自己的輸入堆在同一個上傳佇列裡而晚送出，造成輸入延遲、拉回，偶爾出現不必要的重傳

症狀: 輸入延遲, 拉回
因素: 延遲, 遺失
誰會遇到: 同一個家
何時: 偶爾隨機發生, 晚間尖峰時段
負責單位: 主要負責 外部（外部） · 協同遊戲開發團隊（用戶端開發）
遊戲開發團隊要做的事: ping 急遽升高時在畫面上顯示網路狀態、跳出「請檢查正在上傳的程式」提示。
外部要做的事: 建議玩家用分享器的 SQM 縮短上傳佇列、優先處理小封包（ACK）、限制上傳速度（影片上傳、雲端備份）。
數值參考: 後面的 ACK 會代替前面的 ACK 完成確認，所以少了幾個通常沒關係。真正的問題是 ACK 在佇列裡被延遲。
圖表上: 只有部分偏高 · 各連線的 RTT（ping）
查看位置: 在玩家電腦上，分別在開啟與關閉上傳（影片上傳、雲端備份）的狀態下 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（偏差）