遊戲 Lag 白皮書 › TCP 重傳的根本原因
瓶頸佇列溢位（壅塞遺失） Tail drop at a congested bottleneck
原因 ID rt-queue-drop · 主要負責 基礎設施團隊（網路基礎設施） · 協同 外部（外部）, 遊戲開發團隊（用戶端開發）
在含圖解與實驗的完整版中開啟卡片 →
分享器、電信業者之間的互連區段、資料中心線路這類最窄的地方，佇列一滿就會丟棄新進來的封包。
為什麼 影片、下載與其他使用者的流量把瓶頸區段塞滿 → 於是 佇列滿的期間，新到的封包接連被丟棄（tail drop）。沒被丟棄的封包也要在塞滿的佇列尾端等待 → 畫面上 多個封包同時消失，長時間定格後快轉，晚間時段常見
- 症狀
- 定格, 快轉, 拉回
- 因素
- 遺失, 延遲
- 誰會遇到
- 同一個家, 特定地區／電信業者, 整個伺服器
- 何時
- 晚間尖峰時段, 人潮湧入時
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 外部（外部）, 遊戲開發團隊（用戶端開發）
- 遊戲開發團隊要做的事
- 遺失集中出現或 ping 急遽升高時，在畫面上顯示網路狀態（提示可能是同一條線路上有大量傳輸）。
- 基礎設施團隊要做的事
- 確保資料中心線路有餘裕、檢查我方線路與交換器 port 的佇列丟棄（output drops）計數器、電信業者區段壅塞時改走其他線路或 peering 繞開。
- 外部要做的事
- 建議玩家在分享器使用 SQM（fq_codel、CAKE）與 ECN（讓傳送端在佇列溢位前降速）、要求電信業者為瓶頸區段擴充容量。
- 數值參考
- 佇列溢位的瞬間，數十 ms 內進來的封包會有相當多一起消失。容易連續遺失，連重送的封包也可能遺失，因此常常要等到 RTO 才復原。
- 圖表上
- 只在特定時段偏高 · 重傳率、RTT（ping）
- 查看位置
- 把伺服器重傳率（每 1 分鐘執行一次 nstat 取得的 TcpRetransSegs ÷ TcpOutSegs 增加量）與各連線 RTT 依地區、電信業者、時段分開看，同時查看我方線路與交換器 port 的輸出丟棄（ifOutDiscards）。在尖峰與離峰時段各對問題地區跑 mtr 比較
- 符合的跡象
- 只有晚間尖峰時重傳率上升，而且遺失前 RTT 先升高（佇列逐漸塞滿的樣子）。mtr 只在尖峰時段從某個躍點起到終點遺失與延遲一起增加
- 不符合的跡象
- 遺失前 RTT 沒有升高時是「Policer 丟棄超額流量」。不論哪個時段遺失都差不多時，是「實體層錯誤」或「路由變更、ECMP 不良路徑」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 實際案例
- Riot Games 2015: 繞遠路的 League of Legends 流量與 Riot Direct
出處
- RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
說明 tail drop 會讓佇列長時間塞滿，拉高延遲並造成集中遺失，並建議採用 AQM - RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm IETF
fq_codel：以每條流（flow）各自的佇列加上 AQM 讓佇列保持短小，減少 bufferbloat - RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP IETF
ECN：以 IP 標頭中的標記通知壅塞，取代丟棄封包 - Smart Queue Management Bufferbloat.net
SQM：同時使用依流排程、佇列長度管理（AQM）與流量整形（shaping）的做法 - Cake Bufferbloat.net
CAKE：結合 shaper 與 fq_codel 類佇列管理的分享器用 SQM - net/ipv4/proc.c Linux kernel
nstat 顯示的 TcpRetransSegs、TcpOutSegs（Tcp 項目下的 RetransSegs、OutSegs） - nstat(8) — Linux manual page iproute2
nstat 預設顯示自上次執行以來的增加量 - RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards：沒有偵測到錯誤，卻因要騰出緩衝區空間等原因而沒有送出、直接丟棄的封包數 - An Internet-Wide Analysis of Traffic Policing Google
佇列溢位時，遺失前等待時間與 RTT 會先升高；policing 則在 RTT 沒有增加的情況下丟棄超額部分（SIGCOMM 2016）
相關原因
同一層：TCP 重傳的根本原因
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片