代表的な面接トピック

一般面接:ICE、STUN、TURN はどのようにして WebRTC 接続を確立するのか?

一般難しい
Offer.cc 編集チーム公開日 更新日

質問

2つのブラウザが未知のネットワークをまたいで WebRTC 接続を確立する必要があります。シグナリング、ICE、STUN、TURN がどのように連携し、候補ペアがどのように選択され、ICE の障害をどのように診断するかを説明してください。

プロンプトと適用範囲

2つのブラウザが音声、動画、またはデータの接続を必要としています。それらは同じ LAN 内にある場合もあれば、異なる NAT の背後にある場合や、UDP をブロックするネットワーク上にある場合もあります。接続確立の経路と失敗の経路を説明してください。回答では、記述(description)を交換するシグナリングチャネルと、利用可能なネットワーク経路を検出して検証する ICE とを明確に区別する必要があります。

Credmark の公開 WebRTC 面接ガイドでは、ICE の仕組みや STUN と TURN の役割を説明することが明示的に求められています。RFC 8445 は ICE の候補、チェックリスト、接続性チェックの手順を定義しており、WebRTC.org はピア接続が STUN または TURN サーバーを使用して候補を収集する方法をドキュメント化しています。

面接官が評価するポイント

  • シグナリング、候補の収集、接続性チェック、メディアの暗号化を明確に分離して説明できているか。
  • STUN が「ポートを開放する」などと誤った説明をせず、ホスト候補、サーバー再帰的(server-reflexive)候補、リレー候補を正確に説明できているか。
  • 直接経路のレイテンシと TURN の帯域幅、プライバシー、運用コストとのトレードオフを検討できるか。

重要なシグナルは因果関係に基づくタイムラインです。記述と候補がシグナリングを通じて送受信され、候補ペアに対してチェックが実行され、その後にのみ選択された経路で暗号化されたメディアやデータが転送されます。

回答前の前提確認

  1. シグナリングはすでに利用可能か? ICE は、アプリケーションの WebSocket、HTTP、またはメッセージングによるシグナリングトランスポートを定義しません。
  2. ピアはブラウザ間通信か、それとも SFU 経由か? SFU はメディアトポロジーを変更しますが、各ピアとの接続性は依然として必要です。
  3. UDP および TCP 443 は許可されているか? ファイアウォールのポリシーによって、ホスト、再帰的、またはリレー候補が成功するかどうかが変わります。
  4. コストの目標は何か? TURN リレーはトラフィックを中継するため、動画のビットレートとリレー率が支出を左右します。

30秒での簡潔な回答

「シグナリングは SDP のオファー/アンサーと trickled ICE 候補を交換するもので、アプリケーション固有の実装です。各ピアはホスト候補を収集し、STUN にサーバー再帰的アドレスを問い合わせ、直接経路が失敗する可能性がある場合は TURN リレー候補を取得します。ICE は候補ペアを形成し、認証された接続性チェックを送信して、機能するペアを指定(ノミネート)します。その後、DTLS がピアを認証してメディアやデータ用の鍵を導出します。STUN はマッピングされたアドレスの検出を支援し、TURN はバイト列を中継します。対称 NAT、UDP のブロック、制限の厳しいファイアウォールによって TURN が強制される場合があるため、候補ペアの成功率、接続完了までの時間、リレー率、ネットワークタイプ別の失敗率を測定します。」

ステップごとの詳細な回答

ステップ 1: シグナリングによる記述の交換。

発信側(caller)はメディアセクションと ICE クレデンシャルを含むオファーを作成し、アプリケーションのシグナリングサービスを介して送信します。着信側(callee)はアンサーを返します。シグナリングはまた、trickled 候補や end-of-candidates マーカーも転送します。シグナリングサーバーは SDP を中継するだけであり、それ自体がメディアを伝送するわけではありません。

ステップ 2: 候補タイプの収集。

ホスト候補はローカルインターフェースを表します。STUN バインディングリクエストにより、ピアはその STUN サーバーから観測されたパブリックなマッピング済みアドレスとポートを含むサーバー再帰的候補を取得します。TURN 割り当て(allocation)はリレー候補を作成し、TURN サーバーがトラフィックのエンドポイントになります。候補の優先順位(priority)とファンデーション(foundation)は ICE が経路を比較するのに役立ちますが、優先順位の高いペアが必ず疎通することを保証するものではありません。

ステップ 3: 候補ペアの形成とチェック。

各ピアは自身のローカル候補とリモート候補を組み合わせます。ICE はペアをチェックリストに並べ替え、ICE クレデンシャルを使用して STUN 接続性チェックを送信し、応答を記録します。チェックの成功は、その時点でトラフィックがそのペアを通過できることを証明しますが、将来の可用性を証明するものではありません。制御エージェント(controlling agent)が有効なペアを指定し、両ピアがそのペアに収束します。

ステップ 4: 選択された経路の保護。

ICE の接続確立後、DTLS がピアを認証し、鍵を導出します。SRTP は音声と動画を保護し、DTLS 上の SCTP がデータチャネルを伝送します。ICE は到達可能性を選択するものであり、アプリケーションのペイロードを暗号化するものではありません。ブラウザ API は接続状態と選択された候補の統計情報を公開しており、これらは診断に不可欠です。

ステップ 5: 一般的な NAT 結果の説明。

同じ LAN 内のホスト候補は多くの場合機能します。フルコーン NAT または互換性のある NAT では、サーバー再帰的候補が機能する場合があります。対称 NAT(symmetric NAT)のマッピング、エンドポイント依存のフィルタリング、または UDP のブロックにより、直接候補が失敗することがあります。ポート 443 上の UDP、TCP、または TLS 経由の TURN はリレーフォールバックを提供しますが、レイテンシと帯域幅コストが増加し、信頼境界(trust surface)も拡大します。

ステップ 6: 根拠に基づく障害診断。

シグナリング状態、ICE 収集状態、ICE 接続状態、候補タイプ、ペアチェック、選択された候補ペア、RTT、同意の鮮度(consent freshness)、ネットワークファミリをログに記録します。LAN、モバイル、対称 NAT、VPN、UDP ブロック環境などの制御されたマトリックスを使用します。収集には成功するがチェックが失敗する場合はファイアウォールと NAT ポリシーを調査し、リレーのみが成功する場合はリレーコストと通話品質を測定した後にのみ直接経路ポリシーを改善します。

質の高い模範解答

「私は4つの境界線を引いて説明します。第1に、アプリケーションのシグナリングサービスは SDP、ICE クレデンシャル、候補、end-of-candidates を交換しますが、メディア経路ではありません。第2に、ホスト候補はローカルインターフェースを示し、STUN はサーバー再帰的マッピングを生成し、TURN はリレーを割り当てます。第3に、ICE はローカルとリモートの候補を組み合わせ、認証された STUN メッセージでペアをチェックし、ペアを指定します。その後、DTLS が鍵を導出し、SRTP が音声/動画を伝送し、SCTP がデータチャネルを伝送します。

直接のホスト経路や再帰的経路はコストが低く、通常はレイテンシも低くなりますが、対称 NAT や UDP ブロックには TURN が必要になる場合があります。候補の収集、ペアチェックのエラー、接続までの時間、選択された候補のタイプ、リレー率、RTT、ネットワーククラスごとの同意喪失を計測します。これにより、シグナリングの欠落、NAT トラバーサルの失敗、メディア経路が劣悪な接続済み通話を明確に区別できます。」

よくある間違い

  • STUN をリレーと呼ぶ → STUN はマッピングされたアドレスを報告するだけでセッションを中継しない → リレーのセマンティクスは TURN のみに用いる。
  • シグナリングがメディアを確立すると言う → シグナリングは記述と候補を転送するだけである → その後の ICE チェックと選択されたペアのプロセスを追跡する。
  • STUN 応答の成功が接続性を証明すると想定する → フィルタリングによりピアペアが依然として失敗する可能性がある → 両方の候補間で ICE チェックを実行する。
  • 測定せずにすべての通話に TURN を使用する → リレーの帯域幅とレイテンシがコストと品質を悪化させる可能性がある → 直接経路を優先し、リレー率を監視する。
  • ICE を暗号化として扱う → ICE は到達可能性をチェックするものであり、機密性を担保するものではない → DTLS と SRTP/SCTP は別個に説明する。

フォローアップの質問と回答

フォローアップ 1: STUN が成功しているのにピア接続が失敗するのはなぜですか?

STUN は、サーバーがある一方からのマッピングを観測したことしか示しません。リモートピアは、NAT がエンドポイント依存のマッピングやフィルタリングを使用している場合や、ファイアウォールがプロトコルをブロックしている場合、そのマッピング宛てに送信できない可能性があります。ICE はペア全体をテストする必要があり、STUN リクエストの成功は経路の成立を保証するものではありません。

フォローアップ 2: システムが TURN を強制すべきなのはどのような場合ですか?

ポリシーでピアアドレスが禁止されている場合、直接チェックが繰り返し失敗する場合、または管理されたネットワーククラスが UDP をブロックしていることが判明している場合に、TURN を強制または優先します。短寿命のクレデンシャル、リージョンごとのリレー、レート制限、キャパシティアラームを使用します。グローバルに TURN を強制すると、直接経路のデグレードが見落とされ、帯域幅コストが増加するため、測定に基づいた明示的なポリシーとして適用する必要があります。

フォローアップ 3: 通話は接続されていますが動画品質が劣悪です。何を調査しますか?

選択された候補ペア(それがリレーであるかどうか)、RTT、パケット損失、ジッター、同意の鮮度、ビットレート適応を確認します。直接経路とリレー経路で同じ通話を比較し、CPU とエンコーダのキューを調査し、SFU または TURN のリージョンが遠方にないか確認します。ICE の成功は到達可能性を証明するだけであり、十分な容量やメディア品質を保証するものではありません。

公開情報ソース

関連する質問