WebRTC の動作原理の分析 | Nuggets Technology 論文募集

導入

WebRTC は、Web アプリケーション間のリアルタイムのピアツーピア通信を提供するために現在開発中のオープン ソース プロジェクトです。

WebRTC は、開発者がリアルタイムのオーディオおよびビデオ送信機能を備えた Web アプリケーションを簡単に構築できるようにするシンプルな JavaScript API を提供します。WebRTC は、携帯電話上のネイティブ アプリケーションもサポートする予定です。WebRTC が提供する API の中には、実は WebRTC の基盤となる実装原理が隠されているため、API を利用するだけでなく、WebRTC の基盤となる実装を理解する必要があります。

この記事は、WebRTC を初めて使用する人、特に WebRTC の動作原理を知らない人に非常に適しています。誰もができる限り理解できるように、簡単な用語と例えを使用して WebRTC の基本的な動作原理を説明します。 WebRTCの詳細。

始める

A と B の間で WebRTC 接続を確立するには、次の 2 つの手順を実行する必要があります。

  1. お互いの位置を調べます。
  2. WebRTC 接続をセットアップするようにピアに通知します。

ステップ 1: お互いを見つける

WebRTC で相手を見つけるプロセスは電話をかけることに似ており、電話で誰かと話す必要がある場合、相手に連絡する前に相手の電話番号を入力する必要があります。誰かがあなたに電話をかけたい場合も、同じプロセスが必要です。電話をかけるとき、当社は電話番号を使用してユーザーを識別し、さらに電気通信システムでこの識別情報を使用してユーザーを特定します。

ただし、Web アプリケーションは相互にダイヤルしたり通話したりすることはできません。なぜなら、世界中には多くのブラウザが存在し、多くのブラウザが 1 つのシステム内に同時に存在することができ、ブラウザには電話番号のような固有の ID が存在しないためです。 ID は IP アドレスであり、測位に使用できます。
 

ただし、そのプロセスはそれほど簡単ではありません。ほとんどの場合、これらのシステムはネットワーク アドレス変換 (NAT) デバイスの背後にあるためです。使用可能なパブリック IP アドレスに対するセキュリティと IPv4 の制限には、NAT デバイスが必要です。NAT デバイスは、ローカル ネットワーク上のシステムにプライベート IP アドレスを割り当てます。このプライベート IP アドレスはローカル ネットワーク内でのみ有効かつ表示され、ネットワーク外のシステムはネットワーク内のデバイスのパブリック IP を知らないため、外部からの通信を受け入れるために使用することはできません。


NAT デバイスの関与により、必要なピアは、NAT によって割り当てられたプライベート IP アドレスによってマスクされるため、自分自身のパブリック IP アドレスを知りません。したがって、パブリック IP アドレスを別のピアと共有して接続を受け入れることはできません。さらにわかりやすくするために、誰かに電話してもらいたい場合は、相手に自分の電話番号を伝える必要があります。ただし、NAT の存在下では、部屋の電話番号が外界から隠されているホテルに滞在しているようなもので、ホテルにかかってきた電話はフロントで処理され、さらにリクエストに応じて部屋にリダイレクトされます。この間接的な接続形式は、ピアツーピア接続テクノロジを目的としたものではありません。

これを克服するために、ICE (対話型接続確立) と呼ばれるプロトコルを使用します。ICE の仕事は、2 つのピアを接続する最適なパスを見つけることです。ICE は、直接接続 (NAT なし) と間接接続 (NAT が存在する場合) を実行できます。ICE フレームワークは、ICE 候補を提供します。ICE 候補は、独自のパブリック IP アドレス、ポート番号、その他の接続関連情報を含むオブジェクトにすぎません。

NAT がない場合、ピアのパブリック IP アドレスが常に利用可能なため、ICE は非常にシンプルです。ただし、NAT が存在する場合、ICE は NAT 用セッション トラバーサル ユーティリティ (STUN) や NAT 周囲のリレーを使用したトラバーサル (TURN) と呼ばれるエンティティに依存します。
 

STUN サーバーでは、基本的にピアが自身のパブリック IP アドレスを見つけることができます。自身のパブリック IP アドレスを知る必要があるピアは、STUN サーバーにリクエストを送信します。STUN サーバーは、ピアのパブリック IP アドレスで応答します。このパブリック アドレスを他のピアと共有できるようになり、他のピアがあなたを見つけることができるようになります。ただし、ピアが複雑な NAT またはファイアウォールの背後にある場合、STUN ですらその IP アドレスを見つけて、要求元のピアに提供することができません。この場合、ICE は TURN に依存して接続を確立します。名前が示すように、TURN はリレー サーバーであり、2 つのピア間で直接接続できない場合にデータ、オーディオ、ビデオを送信するための媒体として使用できます。

STUN サーバーは、パブリック IP を見つけるプロセスにのみ関与します。WebRTC 接続が確立されると、それ以降の通信はすべて WebRTC 経由で行われます。ただし、TURN の場合、WebRTC 接続を設定した後でも TURN サーバーが必要です。

しかし、STUN には制限があるため、それに依存する必要があります。STUN サーバーの成功率はわずか 86% です。

ステップ 2: WebRTC 接続をセットアップするようにピアに通知します。
 

ICE 候補が得られたので、次のステップは、接続したいピアにこれらの候補を送信することです。候補者とともに、セッション情報、時間の説明、メディアの説明などのセッションの説明が送信されます。ICE 候補とセッション記述はオブジェクト内にバンドルされ、SDP (セッション記述プロトコル) を使用して配信されます。場合によっては、ICE 候補がセッション記述と同じオブジェクトにバンドルされず、個別に送信されることがあります。これは Trickle ICE と呼ばれます。

接続を確立するときは、他のピアに情報を「送信」する必要があります。しかし、送信側の IP アドレスだけがわかっていて、受信側ピアの IP アドレスがわからない場合、候補とセッションの説明をどのように転送すればよいでしょうか? WebRTC 接続がまだ確立されていないため、この情報はどのような媒体を通じて送信されるのでしょうか?

これらすべての質問に対する答えは、シグナリング メカニズムとして知られる概念にあります。WebRTC 接続を確立する前に、ピア間で上記の情報を送信し、WebRTC 接続を見つけて接続する方法をピアに伝えるための何らかの媒体が必要です。ここでシグナリングメカニズムが登場します。名前が示すように、シグナリング メカニズムは、接続を目的とした 2 つのピア間で接続信号 (ICE 候補、セッションの説明など) を交換します。

WebRTC では、このようなシグナリング メカニズムを実装するための標準を定義しておらず、開発者が任意のメカニズムを作成することができます。情報を交換するためのシグナリング メカニズムは、単に情報をコピーしてそれぞれのピアに貼り付けるか、 WebSocket、 http://Socket.io 、サーバー サイド イベントなどの通信チャネルを使用することによって実装できます。つまり、信号伝達メカニズムは単なるパターンにすぎません。接続関連の情報はピア間で交換されるため、ピアはお互いを認識し、さらに WebRTC を使用して通信を開始できます。

簡単な要約

より深く理解するために、プロセス全体を確認してみましょう。

たとえば、ピア A がピア B との WebRTC 接続を確立したい場合、次のことを行う必要があります。

ピア A は、ICE を使用して ICE 候補を生成します。ほとんどの場合、NAT (STUN) セッション トラバーサル ユーティリティ、またはリレーを使用した NAT (TURN) サーバー トラバーサルが必要です。
ピア A は、ICE 候補とセッションの説明を 1 つのオブジェクトにバンドルします。このオブジェクトはピア A 内のローカル記述 (ピア自身の接続情報) として保存され、シグナリング メカニズムを介してピア B に伝達されます (この部分はオファーと呼ばれます)。
ピア B は提案を受信し、その後の使用のためにそれをリモート記述 (相手側のピアの接続情報) として保存します。ピア B は、独自の ICE 候補とセッション記述を生成し、ローカル記述として保存し、シグナリング メカニズムを通じてピア A に送信します。この部分はアンサーと呼ばれます。(注: 前述したように、ステップ 2 と 3 の ICE 候補は個別に送信することもできます)
ピア A はピア B から応答を受信し、それをリモート記述として保存します。このようにして、両方のピアが互いの接続情報を取得し、WebRTC 経由で通信を正常に開始できるようになります。

オリジナル WebRTC の動作原理の分析 | Nuggets Technology 論文募集

 

★記事末尾の名刺では、オーディオ・ビデオ開発学習教材(FFmpeg、webRTC、rtmp、hls、rtsp、ffplay、srs)やオーディオ・ビデオ学習ロードマップ等を無料で受け取ることができます。

以下を参照してください!

 

おすすめ

転載: blog.csdn.net/yinshipin007/article/details/132475154