한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

ゲームラグ白書 › L4 インターネット回線

国・通信事業者単位のUDP制限・パケット検査 UDP blocking, throttling and inspection by networks

原因ID isp-udp-block · 主担当 外部・外部 · 副担当 ゲーム開発チーム・クライアント開発, ゲーム開発チーム・サーバー開発, インフラチーム・ネットワークインフラ

図と実験のあるメインページでこのカードを開く →

一部のネットワークでは、特定のUDPアドレス・ポートをブロックしたりUDPの速度を制限したりし、パケット検査装置が識別できないプロトコルを遮断します。UDPで通信するゲームは、そのネットワークでは接続できなかったり、頻繁に切断されたりします。

なぜ UDPの速度を制限する一部の通信事業者網や、国・通信事業者単位のトラフィック検査（検閲）装置があるネットワークから接続 → すると 特定のUDPアドレス・ポートをブロック、混雑する時間帯にUDPの速度を制限、許可リストにないポート・プロトコルを遮断、または最初の数パケットだけ通してからブロック → 画面では 特定の国・通信事業者のユーザーだけ接続不可・無限ロード、接続してもすぐに切断、混雑する時間帯にパケットロスでワープ

症状
接続不可・無限ロード, 切断, ワープ
要因
パケットロス
誰に起きるか
特定の地域・ISP
いつ
接続直後・メンテ明け, 常に, 夜のピーク時間帯
担当
主担当 外部・外部 · 副担当 ゲーム開発チーム・クライアント開発, ゲーム開発チーム・サーバー開発, インフラチーム・ネットワークインフラ
ゲーム開発チームの対応
クライアント：UDPが数秒以内につながらなければTCP・TLS 443の代替経路に自動で切り替える、最初はつながってもすぐ切れるケースも検知して代替経路で再試行、どの経路で接続したかをログに残す。サーバー：同じゲームプロトコルをTCP 443（TLS）でも受け付ける、代替経路は遅延が増えることがあるのでタイムアウトを調整。
インフラチームの対応
海外の国・地域を追加する前に、現地の通信事業者網でUDPの到達可否とピーク時間帯のパケットロスを測定、TCP 443の代替経路を受けるリレー・ゲートウェイを現地の近くに置く、国・ASN別にUDP・TCPの接続成功率を監視、UDPの速度制限が確認された通信事業者はデータを集めてエスカレーション。
外部の対応
該当する通信事業者・機関にUDP制限の基準と緩和について問い合わせ、ユーザーには別のネットワークから接続して比較してみるよう案内。
数値の目安
IETFの文書が引用した測定によると、ネットワークの3〜5%はUDPを完全にブロックしています。Googleが2016年にQUIC（UDPベース）の利用状況を調べたところ、クライアントの4.4%はUDP・QUICがブロックされているか経路MTUが小さいために使えず、その大半は企業のファイアウォールの内側でした。通信事業者全体でブロックしている例は見られませんでした。0.3%はピーク時間帯にパケットロスが大きく増える、UDPの速度を制限しているとみられるネットワークにあり、通信事業者に要請して2015年の1%から減らしました。
グラフでは
一部だけ高い · UDP接続成功率（国・ASN別）
確認箇所
国・ASN別にUDPの接続成功率とTCP 443の代替経路の成功率を分けて確認。該当する通信事業者網のクラウドVMやユーザーのPCから、ゲームのUDPポートとTCP 443でそれぞれ接続試験を行い、mtr -u -P（ゲームのポート）とmtr -T -P 443で、どの区間から応答が消えるかを比較
該当する場合
特定の国・ASNだけでUDPの最初の応答がないか数秒で切れ、同じ場所からのTCP 443は正常。速度制限の場合は、ピーク時間帯にだけUDPのパケットロスがはっきり増え、TCPへの影響は小さい
該当しない場合
TCPも一緒に失敗するなら経路障害・IPブロック・「DNSの障害・遅延」側。すべての国で同じなら自社のサーバー・ファイアウォールの設定、UDP・TCPを問わず瞬間的な送信量が多いときだけパケットロスが出るなら「ポリサーによる超過分の破棄」
確認手段
インフラのツールで確認（ゲームコード不要）
もっと詳しく
パケット検査装置は、アドレス・ポート・プロトコルでUDPのフローを選んでブロックしたり、許可したプロトコル以外はすべてブロックする方式（許可リスト）を使ったりします（IRTFの調査文書）。装置がパケットの一部のフィールドだけを見て判断していると、プロトコルを少し変えただけでブロックされることもあります。QUICの初期には、あるファイアウォールがヘッダーの1ビットが変わった後、最初の数パケットは通してそれ以降のパケットをブロックしたため、クライアントがTCPに切り替えて接続するロジックが働きませんでした。海外の国・地域を追加したときに、「国内は問題ないのに、その国の一部の通信事業者だけ接続できない」という報告で発覚することがあります。カフェや会社のように、ある場所のネットワークだけでブロックされるなら「公衆Wi-Fi・社内ネットワークの制限」の項目を参照してください。

出典

  1. RFC 9308: Applicability of the QUIC Transport Protocol IETF
    測定研究によるとネットワークの3〜5%がUDPを完全にブロックしており、UDPベースのアプリは接続失敗を受け入れるか、TCP（TLS）の代替経路を用意する必要がある、登録されたサービスに対応しないポートはファイアウォールにブロックされることがある
  2. 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への切り替えロジックを無効にした事例
  3. RFC 9505: A Survey of Worldwide Censorship Techniques IRTF
    ネットワークの検査装置はアドレス・ポート・プロトコルでTCP・UDPのフローを選んでブロックでき（QUICではUDPエンドポイントのブロックが観測された）、許可したプロトコル以外をブロックする方式は過剰なブロックを招き、特定のトラフィックの速度を制限する方式も使われる
  4. mtr(8) manual page source mtr
    -uでUDP、-TでTCP SYNを送り、-Pで宛先ポートを指定して、ゲームと同じプロトコル・ポートで経路を測定

あわせて読みたい原因

同じ層：L4 インターネット回線

同じ症状（接続不可・無限ロード）を起こすほかの層の原因

図と実験のあるメインページでこのカードを見る