
ICE(Interactive Connectivity Establishment)
プロトコルファイアウォールやNATを越えてピア接続を確立するためのフレームワーク。
ICEとは?
Interactive Connectivity Establishment(ICE)は、NAT(ネットワークアドレス変換)やファイアウォールなどのネットワーク障害にもかかわらず、ブラウザやデバイス間の直接接続を確立するためにWebRTCが使用するフレームワークです。ICEは複数の接続戦略を同時に試行し、2つのピア間の最適なパスを見つけるスマートネゴシエーターのようなものです。
ICE自体はメディアを転送しません。メディア(ビデオ、音声、データ)がピア間を流れるように、2つのデバイスをどのように接続するかを見つけ出すプロセスです。ICEが成功すると、実際のWebRTC接続はICEが発見したパスを使用します。
RFC 8445で標準化されたICEは、ブラウザ間通信というWebRTCの約束に不可欠です。ICEがなければ、参加者は通常、直接接続をブロックするNATルーターの背後にいるため、ほとんどのWebRTC通話は失敗するでしょう。
ICEの動作:ステップバイステップ
1. ICE候補の収集
WebRTC接続が開始されると、各ピアは「候補」(潜在的な接続パス)を収集します。ICEは3種類の候補を発見します:
- ホスト候補:デバイスのローカルIPアドレス(WiFi用の192.168.1.100やVPN用の10.0.0.5など)。両方のピアが同じローカルネットワーク上にある場合にのみ機能
- サーバーリフレクシブ候補:STUNサーバーへの問い合わせで発見された、インターネットから見たパブリックIPアドレス
- リレー候補:直接接続が失敗した場合にトラフィックを転送するTURNリレーサーバー上のアドレス。常に機能するが、レイテンシが追加されるフォールバック
2. シグナリングを介した候補の交換
各ピアの候補は、シグナリングチャネル(通常WebSocketまたはHTTPS)を通じて相手のピアに送信されます。最新のWebRTCは「Trickle ICE」を使用し、すべての候補の収集を待たずに、発見次第、候補をインクリメンタルに送信します。
3. 接続性チェック
ピアが互いの候補を持つと、ICEは接続性チェックを実行します。ローカル候補とリモート候補をペアにし、STUNバインディングリクエストを送信して各ペアをテストします。テストは並行して実行され、候補の品質で優先順位付けされます。
4. 最適なパスの選択
ICEは正常に接続された候補ペアを特定し、最低レイテンシ、候補タイプの優先度、接続の信頼性に基づいて「最良」のものを選択します。
接続成功率
実際の展開では:
- 接続の75-85%:サーバーリフレクシブ候補(STUN)を使用した直接P2Pパスで成功
- 接続の15-25%:対称NAT、制限的なファイアウォール、または企業ネットワークのためにTURNリレーが必要
- 接続の1%未満:完全に失敗。通常、企業プロキシがWebRTCを完全にブロックしているため
ICEリスタート
ICEは通話を終了せずに候補の収集と選択プロセスを再開することをサポートしています。これは、ネットワーク条件が変化した場合(WiFiからセルラーへの切り替えなど)、接続が劣化または失敗した場合に発生します。
まとめ
ICEはWebRTCの縁の下の力持ちです。両者がNATルーターやファイアウォールの背後にいても、リンクをクリックするだけで世界中の誰とでもビデオ通話を即座に開始できるのはICEのおかげです。直接ローカル接続、STUNを介したP2P、TURNを介したリレーという複数の接続戦略を体系的に試行することで、ICEはレイテンシを最小限に抑えながら接続成功率を最大化します。