遊戲 Lag 白皮書 › TCP 重傳的根本原因
路由變更、ECMP 不良路徑 Route change / bad ECMP member
原因 ID rt-path · 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）, 外部（外部）
在含圖解與實驗的完整版中開啟卡片 →
網際網路路由變更的那幾秒內，或是多條 ECMP 路徑中被分配到不良路徑的連線，會有封包消失。
為什麼 BGP 重新計算路由，或多條路徑（ECMP、LAG）中某一條的設備或線路不良 → 於是 切換路由時暫時遺失，或只有走該路徑的連線持續遺失 → 畫面上 突然定格幾秒後快轉，或是「重新連線就變好」（被分配到其他路徑）
- 症狀
- 定格, 快轉, 瞬移
- 因素
- 遺失
- 誰會遇到
- 特定地區／電信業者
- 何時
- 偶爾隨機發生
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）, 外部（外部）
- 遊戲開發團隊要做的事
- 記錄各連線的重傳統計（TCP_INFO），以便找出受影響玩家的 IP、port 與時間點、停住幾秒的連線不要立刻切斷。
- 基礎設施團隊要做的事
- 監控各地區、各電信業者的重傳率、確認重新連線後路徑是否改變、準備多家電信業者的線路、檢查我方設備 ECMP 與 LAG 路徑中的不良鏈路、路徑量測也使用與遊戲相同的 TCP port（mtr --tcp --port。路徑依位址與 port 決定，一般 ping 可能走不同的路徑而顯示正常）。
- 外部要做的事
- 向電信業者回報不良路徑，並附上以相同 TCP port 量測的路徑結果與重新連線前後的比較。
- 圖表上
- 從某個時間點起階梯式上升 · RTT（ping）、各地區／電信業者的重傳率
- 查看位置
- 用 bcc tcpretrans -c 依連線彙整重傳，找出受影響玩家的位址與 port，再以與遊戲相同的 TCP port，分別從伺服器往玩家、從玩家往伺服器跑 mtr（mtr -T -P PORT）比較。重新連線前後的結果也要比較
- 符合的跡象
- 以某個時間點為分界，某一地區或電信業者的 RTT 像階梯一樣改變，並集中出現幾秒的遺失；或是在同一電信業者內，也只有部分連線（位址與 port 的組合）持續重傳，重新連線就變好。有時一般 ping 正常，只有 TCP mtr 看得到遺失
- 不符合的跡象
- 該電信業者的所有連線在晚間尖峰一起變差時是「瓶頸佇列溢位」。只有一名玩家變差、從 ping 分享器就開始遺失時是「無線區段的封包遺失」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 實際案例
- Cloudflare 2020: Cloudflare 骨幹設定錯誤導致部分城市的流量遺失
出處
- RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
說明在多路徑環境下，ping、traceroute 這類診斷工具的結果難以採信，以及將流（flow）雜湊後固定路徑的做法 - RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
ECMP 以區分流的標頭欄位雜湊值選擇下一段路徑（同一個流走同一條路徑） - tcp(7) — Linux manual page Linux man-pages
TCP_INFO：查詢各 socket 的狀態（struct tcp_info） - mtr(8) manual page source mtr
-T（--tcp）以 TCP SYN 取代 ICMP，-P（--port）指定目標 port - Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
每次重傳顯示一行，包含對端位址與 port；-c 會依流彙總重傳次數
相關原因
同一層：TCP 重傳的根本原因
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片