遊戲 Lag 白皮書 › L4 網際網路線路
BGP 路由變更與收斂 Route change / BGP convergence
原因 ID isp-bgp · 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）, 外部（外部）
在含圖解與實驗的完整版中開啟卡片 →
網際網路的路由資訊改變後重新收斂的幾秒到幾十秒（偶爾幾分鐘）之間，封包會遺失。
為什麼 某個電信業者區段的路由資訊改變 → 於是 幾秒到幾十秒之間封包消失，或切換到新路徑 → 畫面上 突然停住幾秒，之後 ping 值改變（例：40 → 70ms）
- 症狀
- 定格, 瞬移
- 因素
- 遺失, 延遲
- 誰會遇到
- 特定地區／電信業者
- 何時
- 偶爾隨機發生
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 遊戲開發團隊（伺服器開發）, 外部（外部）
- 遊戲開發團隊要做的事
- 設定能撐過短暫中斷的逾時（停住幾秒的連線不要立刻切斷）。
- 基礎設施團隊要做的事
- 監控路由（監看我方 IP 區段的路由與 ping 變化）；我方線路故障用 BFD 在 1 秒內偵測並切換（BGP 預設 hold time 為 90～180 秒）；若改走遠路後遲遲沒有恢復，就把流量移到其他線路。
- 外部要做的事
- 路由經常變動的電信業者區段，請該電信業者查明原因。
- 圖表上
- 從某個時間點起階梯式上升 · RTT、traceroute 路徑
- 查看位置
- 比較 RTT 改變前後的 traceroute、mtr 路徑，並用 RIPEstat BGPlay 查看我方位址區段（prefix）的 BGP 路由變更紀錄
- 符合的跡象
- 停住幾秒的同時 RTT 移到另一個數值，同一時間有 BGP 更新與 AS 路徑變更
- 不符合的跡象
- 沒有路由變更紀錄、只在晚上升高時是「尖峰時段 peering 區段壅塞」，只有部分連線變差時是「ECMP 其中一條路徑異常」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 實際案例
- Cloudflare 2020: Cloudflare 骨幹設定錯誤導致部分城市的流量遺失
Meta 2021: 一道骨幹指令讓 Facebook 連 DNS 都消失的事故
Cloudflare 2025: Cloudflare 公用 DNS 1.1.1.1 事故
出處
- RFC 4271: A Border Gateway Protocol 4 (BGP-4) IETF
BGP hold time 建議預設值 90 秒（這段時間內沒有收到對方訊息就切斷 session） - BGP updates in 2024 APNIC
不穩定的路由到重新穩定為止，每日平均 25～35 秒（IPv4）、40～50 秒（IPv6） - Delayed Internet Routing Convergence (SIGCOMM 2000) ACM
路由故障後收斂最長要數分鐘，期間遺失與延遲增加（2000 年當時的量測） - BGPlay (RIPEstat Data API) RIPE NCC
顯示位址區段（prefix）在起始時間點的 BGP 路由、該期間觀測到的 BGP 更新，以及路徑上的 AS 資訊
相關原因
同一層：L4 網際網路線路
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片