遊戲 Lag 白皮書 › L4 網際網路線路
傳播延遲（物理距離） Propagation delay
原因 ID isp-distance · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同 基礎設施團隊（網路基礎設施）, 遊戲開發團隊（伺服器開發）
在含圖解與實驗的完整版中開啟卡片 →
光在光纖中 1 秒也只能前進約 20 萬 km。伺服器在遠方，效能再好也會慢。
為什麼 伺服器位在遠方（海外伺服器、其他大陸） → 於是 距離越遠，往返時間越長（每 1,000km 至少 10ms） → 畫面上 所有動作都有固定的輸入延遲，判定上也吃虧
- 症狀
- 輸入延遲
- 因素
- 延遲
- 誰會遇到
- 特定地區／電信業者
- 何時
- 一直都有
- 負責單位
- 主要負責 基礎設施團隊（伺服器基礎設施） · 協同 基礎設施團隊（網路基礎設施）, 遊戲開發團隊（伺服器開發）
- 遊戲開發團隊要做的事
- 物理定律無法用程式碼改變，只能緩解：提供地區選擇讓玩家挑選較近的地區伺服器，並用延遲補償（回溯）減少判定上的劣勢。
- 基礎設施團隊要做的事
- 伺服器設備／OS：在玩家多的地區設置各地區的伺服器。網路：在玩家附近設置接入據點（edge），選擇繞路較少的線路與路由。
- 數值參考
- 首爾–東京約 30ms，首爾–新加坡約 75ms，首爾–美國西岸約 140ms，首爾–歐洲約 230～270ms（往返，以實際路徑為準）。歐洲方向在直線上幾乎沒有大型海底電纜，必須繞經東南亞與蘇伊士或繞經美國，所以延遲比距離推算的長得多。
- 圖表上
- 一開始就一直偏高 · RTT（依國家／地區）
- 查看位置
- 依連線 IP 標上國家，查看各國的 RTT 分布；再從該地區的雲端區域（region）VM 或 RIPE Atlas probe（依國家、ASN 挑選）用 ping、traceroute 量測到伺服器的延遲
- 符合的跡象
- 遠方國家的 RTT 不分時段一直偏高，且數值接近依距離算出的最小延遲（每 1,000km 往返 10ms）與公開的延遲統計
- 不符合的跡象
- 遠高於距離能解釋的數值時是「繞遠路的路由」，只在晚上升高時是「尖峰時段 peering 區段壅塞」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 實際案例
- Riot Games 2015: 繞遠路的 League of Legends 流量與 Riot Direct
出處
- ITU-T G.114: One-way transmission time ITU
光纖傳播延遲規劃值 5µs/km（秒速約 20 萬 km，1,000km 往返 10ms） - Azure network round-trip latency statistics Microsoft Azure
以首爾（Korea Central）為起點的實測往返中位數：東京 30ms、新加坡 68ms、美國西岸 124～136ms、歐洲 234～244ms - AAE-1 & SMW5 cable cuts impact millions of users across multiple countries Cloudflare
歐洲與亞洲之間的流量大多經過埃及（蘇伊士）的海底電纜 - Probe Selection (RIPE Atlas REST API) RIPE NCC
依國家、地區、ASN、位址區段挑選 RIPE Atlas 量測的 probe，執行 ping、traceroute
相關原因
同一層：L4 網際網路線路
同一症狀（輸入延遲）在其他層的原因
查看含圖解與實驗的完整版卡片