Webrtc-finding-route

提供:Dev Guides
移動先:案内検索

WebRTC-ルートを見つける

別のユーザーに接続するには、自分のネットワークと他のユーザーのネットワークの周りに明確なパスを見つける必要があります。 ただし、使用しているネットワークには、セキュリティの問題を回避するために、いくつかのレベルのアクセス制御がある可能性があります。 別のユーザーへの明確なルートを見つけるために使用されるいくつかの技術があります-

  • STUN(NATのセッショントラバーサルユーティリティ)
  • TURN(NAT周辺のリレーを使用したトラバーサル)
  • ICE(インタラクティブ接続の確立)

それらがどのように機能するかを理解するために、典型的なWebRTC接続のレイアウトがどのように見えるか見てみましょう-

典型的なWebRTC

最初のステップは、独自のIPアドレスを見つけることです。 ただし、IPアドレスがネットワークルーターの背後にある場合は問題があります。 セキュリティを強化し、複数のユーザーが同じIPアドレスを使用できるようにするために、ルーターは自分のネットワークアドレスを隠し、別のネットワークアドレスに置き換えます。 自分とパブリックWebの間に複数のIPアドレスがある場合によくある状況です。

STUN

STUNは、各ユーザーを識別し、それらの間の適切な接続を見つけるのに役立ちます。 まず最初に、STUNプロトコルで有効化されたサーバーにリクエストを送信します。 次に、サーバーはクライアントのIPアドレスを送り返します。 これで、クライアントはこのIPアドレスで自分自身を識別できます。

だから基本的に2つのステップがあります-

STUNモデル

このプロトコルを使用するには、接続するためのSTUN対応サーバーが必要です。 すばらしいことは、ChromeとFirefoxがデフォルトのサーバーを提供しているので、すぐにテストできることです。

実稼働環境でのアプリケーションの場合、クライアントが使用する独自のSTUNおよびTURNサーバーをデプロイする必要があります。 今日これを提供するオープンソースのサービスがいくつかあります。

TURN

他のユーザーへのSTUNベースのトラフィックを許可しないファイアウォールがある場合があります。 たとえば、一部のエンタープライズNAT。 これは、別のユーザーと接続する別の方法としてTURNが出てくる場所です。

TURNは、クライアント間にリレーを追加することで機能します。 このリレーは、ユーザーに代わってピアツーピア接続として機能します。 次に、ユーザーはTURNサーバーからデータを取得します。 次に、TURNサーバーは、ユーザーごとに送信されるすべてのデータパケットを取得してリダイレクトします。 これが、代替手段がない最後の手段である理由です。

TURNモデル

ほとんどの場合、ユーザーはTURNなしで大丈夫です。 実動アプリケーションをセットアップするとき、TURNサーバーを使用するコストに見合う価値があるかどうかを判断することをお勧めします。

ICE

これで、STUNとTURNがすべてICEによってどのように統合されるかを学習できます。 STUNとTURNを利用して、ピアツーピア接続を成功させます。 ICEは、両方のユーザーに有効な範囲のアドレスをソートされた順序で検出してテストします。

ICEが起動すると、各ユーザーのネットワークについて何も知りません。 ICEのプロセスは段階的に一連の段階を経て、さまざまなテクノロジーセットを使用して、各クライアントのネットワークがどのようにセットアップされているかを発見します。 主なタスクは、接続を成功させるために各ネットワークに関する十分な情報を見つけることです。

STUNおよびTURNは、各ICE候補を見つけるために使用されます。 ICEは、STUNサーバーを使用して外部IPを見つけます。 接続に失敗すると、TURNサーバーを使用しようとします。 ブラウザは、新しいICE候補を見つけると、クライアントアプリケーションに通知します。 次に、アプリケーションは、シグナリングチャネルを介してICE候補を送信します。 十分なアドレスが見つかってテストされると、接続が確立されます。