遊戲 Lag 白皮書 › L4 網際網路線路
國家／電信業者層級的 UDP 限制與封包檢測 UDP blocking, throttling and inspection by networks
原因 ID isp-udp-block · 主要負責 外部（外部） · 協同 遊戲開發團隊（用戶端開發）, 遊戲開發團隊（伺服器開發）, 基礎設施團隊（網路基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
部分網路會封鎖特定 UDP 位址與 port，或限制 UDP 速度；封包檢測設備也會過濾掉無法辨識的協定。用 UDP 通訊的遊戲在這類網路上會連不上或經常斷線。
為什麼 從限制 UDP 速度的部分電信業者網路，或設有國家／電信業者層級流量檢測（審查）設備的網路連線 → 於是 封鎖特定 UDP 位址與 port、在壅塞時段限制 UDP 速度、過濾不在允許清單上的 port 與協定，或只放行前幾個封包後就封鎖 → 畫面上 只有特定國家或電信業者的玩家連不上／無限讀取，或連上後很快斷線，壅塞時段因封包遺失而瞬移
- 症狀
- 連不上／無限讀取, 斷線, 瞬移
- 因素
- 遺失
- 誰會遇到
- 特定地區／電信業者
- 何時
- 剛登入／維護剛結束, 一直都有, 晚間尖峰時段
- 負責單位
- 主要負責 外部（外部） · 協同 遊戲開發團隊（用戶端開發）, 遊戲開發團隊（伺服器開發）, 基礎設施團隊（網路基礎設施）
- 遊戲開發團隊要做的事
- 用戶端：UDP 在幾秒內連不上時，自動切換到 TCP／TLS 443 替代路徑；也要偵測一開始連上、很快又斷掉的情況，改用替代路徑重試；在 log 中記錄是走哪條路徑連上的。伺服器：同一套遊戲協定也透過 TCP 443（TLS）接收；替代路徑的延遲可能增加，需調整逾時。
- 基礎設施團隊要做的事
- 新增海外國家之前，先在當地電信業者網路量測 UDP 是否能連通與尖峰時段的遺失；在當地附近設置接收 TCP 443 替代路徑的中繼（relay）或閘道；監看各國家、ASN 的 UDP 與 TCP 連線成功率；確認有 UDP 限速的電信業者，整理資料後提報（escalation）。
- 外部要做的事
- 向該電信業者或機關詢問 UDP 限制的標準與放寬方式，並引導玩家改從其他網路連線比較看看。
- 數值參考
- 根據 IETF 文件引用的量測，3～5% 的網路會完全封鎖 UDP。Google 在 2016 年檢視 QUIC（以 UDP 為基礎）的使用結果，發現 4.4% 的用戶端因 UDP 或 QUIC 被封鎖，或路徑 MTU 太小而無法使用，其中大多位於企業防火牆後方，沒有觀察到整個電信業者全面封鎖的情況。另有 0.3% 位於尖峰時段封包遺失大幅增加、看起來在限制 UDP 速度的網路上；Google 請電信業者處理後，這個比例已從 2015 年的 1% 降下來。
- 圖表上
- 只有部分偏高 · UDP 連線成功率（依國家／ASN）
- 查看位置
- 依國家、ASN 分開查看 UDP 連線成功率與 TCP 443 替代路徑的成功率。從該電信業者網路上的雲端 VM 或玩家電腦，分別對遊戲 UDP port 與 TCP 443 做連線測試，並用 mtr -u -P（遊戲 port）與 mtr -T -P 443 比較從哪個區段開始沒有回應
- 符合的跡象
- 只有特定國家、ASN 的 UDP 收不到第一個回應或幾秒內就斷線，同一地點的 TCP 443 則正常。若是限速，只在尖峰時段 UDP 遺失明顯增加，TCP 受影響較小
- 不符合的跡象
- TCP 也一起失敗時，查路徑故障、IP 封鎖或「DNS 故障與延遲」。所有國家都一樣時，查我方伺服器與防火牆設定；不分 UDP、TCP，只在瞬間傳輸量大時才遺失，是「Policer 丟棄超額流量」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 深入了解
- 封包檢測設備可能依位址、port、協定挑出 UDP flow 加以封鎖，也可能採取只放行允許的協定、其餘全部封鎖的允許清單方式（IRTF 調查文件）。設備若只看封包的部分欄位來判斷，協定稍有改動就可能被擋。QUIC 早期曾有一款防火牆在標頭的 1 個位元改變後，只放行前幾個封包、之後的封包全部封鎖，導致用戶端改用 TCP 連線的邏輯無法運作。新增海外國家時，這個問題可能以「韓國沒問題，只有該國部分電信業者連不上」的回報形式浮現。如果只在咖啡廳、公司這類特定場所的網路被擋，請參考「公共 Wi-Fi／公司網路限制」。
出處
- RFC 9308: Applicability of the QUIC Transport Protocol IETF
量測研究顯示 3～5% 的網路完全封鎖 UDP，因此以 UDP 為基礎的應用程式必須接受連線失敗，或準備 TCP（TLS）替代路徑；未對應已註冊服務的 port 可能被防火牆封鎖 - The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017) ACM
2016 年：4.4% 的用戶端無法使用 QUIC（UDP）（UDP、QUIC 被封鎖或路徑 MTU 太小，主要位於企業防火牆後方，未觀察到整個電信業者全面封鎖），0.3% 位於看起來在限制 UDP 速度的網路（尖峰時段遺失增加，請電信業者處理後從 2015 年的 1% 下降），曾有防火牆在標頭 1 個位元改變後只放行前幾個封包、之後全部封鎖，使 TCP 替代邏輯失效 - RFC 9505: A Survey of Worldwide Censorship Techniques IRTF
網路上的檢測設備可以依位址、port、協定挑出 TCP、UDP flow 加以封鎖（QUIC 曾觀測到 UDP 端點被封鎖），只放行允許協定的方式會造成過度封鎖，也有限制特定流量速度的做法 - mtr(8) manual page source mtr
用 -u 送 UDP、用 -T 送 TCP SYN，並以 -P 指定目的 port，用與遊戲相同的協定與 port 量測路徑
相關原因
同一層：L4 網際網路線路
同一症狀（連不上／無限讀取）在其他層的原因
查看含圖解與實驗的完整版卡片