WebRTC の接続確立：ICE・STUN・TURN の原理

なぜ「接続確立」が難しいのか

WebRTC は、サーバーを介さずブラウザ間で音声・映像・データを直接やり取りすることを目指します。ところが現実のクライアントはほぼ全員が NAT の内側にいて、外から到達可能なグローバルアドレスを持ちません。両端が NAT の内側だと、互いに相手の「外から見えるアドレス」を知らず、しかも内側からの発信にしか NAT が穴を開けないため、単純には着信できません。NAT の基本動作は /network/nat/ を参照してください。

この問題を解くのが ICE（Interactive Connectivity Establishment） です。ICE は単一の手法ではなく、複数の候補アドレスを集めて総当たりで到達性を試し、実際に通る経路を選ぶ 枠組み です。その部品として、外部アドレスを発見する STUN と、直接が無理なときに中継する TURN を使います。

候補（candidate）の収集

各端末は、自分が到達されうるアドレスを 候補 として種類ごとに集めます。候補は タイプ・IP・ポート・プロトコル・優先度 を持つレコードです。

host 候補は OS にアドレスを問えば即座に分かります。srflx と relay は外部サーバーへ問い合わせて初めて判明します。集めた候補は相手へ送り、双方の候補を 総当たりでペア化 します。

STUN：外から見た自分を知る

STUN（Session Traversal Utilities for NAT） の本質は単純です。クライアントが STUN サーバーへ Binding Request を送ると、サーバーは受信パケットの 送信元 IP/ポート、すなわち NAT が外向きに割り当てたマッピングを XOR-MAPPED-ADDRESS として返します。これが srflx 候補になります。

Client (192.168.0.10:54000)
  --[NAT が 203.0.113.7:60012 へ書換]--> STUN Server
STUN Server --> "あなたは 203.0.113.7:60012 に見えています"
=> srflx 候補 = 203.0.113.7:60012

ここで決定的に効くのが NAT のマッピング方式 です。発信元の内部アドレスが同じなら宛先が違っても同じ外側ポートを使い回す NAT（エンドポイント独立マッピング、いわゆる錐型）では、STUN で得たポートに相手が直接パケットを送れば穴を通れます。一方、宛先ごとに別のマッピングを切る対称 NAT では、STUN サーバー宛のマッピングと相手宛のマッピングが食い違い、STUN で得たアドレスへ相手が送っても届きません。

TURN：直接が無理なら中継する

TURN（Traversal Using Relays around NAT） は STUN の拡張で、サーバー自身が パケットを中継 します。クライアントは TURN サーバーに Allocate を要求して中継用アドレス（リレー候補）を確保し、以降の通信はすべてこのサーバーを経由します。両端とも自分から TURN への外向き接続なので、どんな NAT 配下でも到達でき、最後の砦 として機能します。

Peer A <--(A→TURN の外向き)--> TURN Server <--(B→TURN の外向き)--> Peer B
  すべて TURN を中継。A も B も「自分から外へ出る」だけなので NAT を問わない

代償は、メディアの全帯域が中継サーバーを通ること、つまり 運用側がトラフィックコストを負担 することです。だからこそ ICE は TURN を最優先にはせず、直接経路を試し尽くしてから中継へ落とす設計になっています。なお TURN over TLS（TCP/443）にすると、Web 通信に紛れて厳しいファイアウォールも越えやすくなります。

ICE：候補ペアの接続性チェックと選定

候補が出揃うと、ICE は自分の候補と相手の候補を掛け合わせた 候補ペア を作り、優先度の高い順に並べた チェックリスト を構成します。host×host が最優先、relay を含むペアが最劣後です。

各ペアの到達性は、メディアと同じ経路で STUN Binding Request を相手へ直接送る ことで実測します。要求が相手に届き、相手からの応答が返って初めてそのペアは双方向に通ると確定します。この双方向確認の過程で、事前リストになかったアドレス（実行時に観測された prflx 候補）も拾えます。

ICE では一方が controlling、他方が controlled の役割を持ちます。両者が並行してチェックを進めますが、最終的にどのペアを使うかは controlling 側が USE-CANDIDATE フラグ付きの要求で 指名（nomination） して確定させます。複数ペアが通っても、優先度最上位の通ったペアが昇格して採用される仕組みです。

1. 全候補ペアを priority 降順でチェックリスト化
2. 各ペアで双方向に STUN Binding を撃ち、応答が返れば「succeeded」
3. controlling 側が最優先の succeeded ペアを USE-CANDIDATE で nominate
4. 選定ペアでメディアが流れ始める（接続確立）

確立後の維持と再接続

採用ペアでも、ICE は consent freshness として定期的に STUN Binding を送り続け、経路がまだ生きているか確認します。NAT のマッピングが無通信でタイムアウトするのを防ぐ keepalive も兼ねます。ネットワークが切り替わった（Wi-Fi からモバイル等）場合は ICE restart で候補収集からやり直し、メディアを止めずに経路を張り替えます。

WebRTC のメディアは UDP 上の SRTP で運ばれるのが基本で、UDP の素の挙動は /network/tcp-udp/ を参照してください。TURN を TCP/TLS に切り替える縮退は、UDP が塞がれた企業網でも到達性を保つための実務上の保険です。VPN を併用する場合の経路の見え方は /network/vpn/ も合わせて押さえると、なぜ候補が増減するかを理解しやすくなります。STUN・TURN・ICE は別々の技術ではなく、「候補を集める／外側を知る／中継する／実測して選ぶ」という一連の役割分担で、NAT 越えという難問を確率の高い順に解いていく総合解だと捉えると全体像が掴めます。