ブラウザのP2P

著者：アレクサンダー・トリシュチェンコ





趣味についてお話します-WebRTCテクノロジー（Webリアルタイム通信-リアルタイムWeb通信）を使用して、ブラウザーでビデオ放送を整理します。 Googleは2012年からこのオープンソースプロジェクトを積極的に開発しており、最初の安定版リリースは2013年に登場しました。現在、WebRTCは、Safariを除き、最も一般的な最新のブラウザーで既に十分にサポートされています。



WebRTCテクノロジーを使用すると、P2Pベースで2人以上のユーザー間のビデオ会議を手配できます。 したがって、ユーザー間のデータはサーバーを介さずに直接送信されます。 ただし、まだサーバーが必要ですが、これについては後で詳しく説明します。 まず、WebRTCはブラウザで動作するように設計されていますが、WebRTC接続を使用できるようにするさまざまなプラットフォーム用のライブラリがあります。



WebRTCを使用する場合、次の問題を解決します。

• サーバーのメンテナンスコストを削減します。 サーバーは、接続を初期化し、ユーザーが相互にネットワーク情報を交換するためにのみ必要です。 また、ユーザーの接続および切断に関する通知などのイベントを送信するためにも使用されます（各クライアントの情報が最新になるように）。
• データ転送速度を上げ、ビデオとサウンドの送信の遅延を減らします。結局、サーバーは必要ありません。
• データのプライバシーを強化します 。データストリームが通過するサードパーティはありません（もちろん、ネットワークに入る前にデータが通過するゲートウェイを除きます）。

接続の初期化

JavaScriptセッション確立プロトコル



接続は、JavaScriptセッション確立プロトコルを使用して初期化されます-現在、このソリューションの仕様を説明するドラフトのみがあります。 以下について説明します。

• サーバーに接続するプロセス。
• 新しいユーザーの一意のトークンを生成します。これにより、バックエンドでユーザーを識別できます。
• ユーザーに会話にアクセスするためのキーを取得する-シグナリング。
• 2人のユーザーを接続するためのRTCStreamConnection初期化。
• 新しい参加者に関するブロードキャストメッセージの会話のすべての参加者による受信。

新しい参加者は、次のようにビデオ会議に接続します。すでにビデオ会議に参加しているというメッセージをこのユーザーに送信し、ユーザーは接続要求を送信します。 同時に、すべての会議参加者に情報を送信して、新しいユーザーと接続します。



どのように機能しますか？ クライアントがメディアデータを直接交換できるブラウザレベルがあり、クライアント間の対話の残りの部分が行われるシグナリングサーバーレベルがあります。







セッション記述プロトコル



特定のユーザーに関する情報を記述できるセッション記述プロトコル（SDP-Session Description Protocol）には、承認された仕様RFC 4556が既にあります 。



SDPでは、次のパラメーターについて説明しています。

• v =（プロトコルバージョン。現在、バージョンは常に0です）。
• o =（作成者/所有者およびセッション識別子）;
• s =（セッション名、空にすることはできません）;
• i = *（セッション情報）;
• u = *（追加のセッション情報でWWWクライアントが使用するURL）;
• e = *（会議の責任者の電子メール）;
• p = *（会議の責任者の電話番号）;
• c = *（すべてのメディアデータの説明がある場合、接続の情報は必要ありません）;
• b = *（通信チャネルの占有帯域幅に関する情報）;
• 時間パラメーターの説明を含む1行以上（以下の例を参照）。
• z = *（タイムゾーンの設定）;
• k = *（暗号化キー）;
• a = *（セッションの属性を説明する1行以上。以下を参照）。

クライアントに関するSDP情報は次のようになります。



対話型接続確立（ICE）



ICEテクノロジーにより、ファイアウォールの内側にいるユーザーが接続できます。 次の4つの仕様が含まれます。

• RFC 5389：NAT（ STUN ）のセッショントラバースユーティリティ。
• RFC 5766：NAT（ TURN ）周辺のリレーを使用したトラバーサル：STUNへのリレー拡張。
• RFC 5245：Interactive Connectivity Establishment（ ICE ）：オファー/アンサープロトコルのNATトラバーサル用プロトコル。
• RFC 6544：対話型接続確立（ICE）を使用するTCP候補

STUNは、VoIPに積極的に使用されるクライアント/サーバープロトコルです。 ここでは、STUNサーバーが優先順位と見なされます。これにより、UDPトラフィックをルーティングできます。 STUNサーバーを使用できない場合、WebRTCはTURNサーバーへの接続を試みます。 リストには、ICE自体のRFCおよびTCP候補のRFCもあります。



WebRTCのICEサーバーのクライアント実装はすでにインストールされているため、複数のSTUNまたはTURNサーバーを簡単に指定できます。 さらに、このためには、初期化中に、適切なパラメーターを使用してオブジェクトを渡すだけで十分です（後で例を示します）。



GetUserMedia API



WebRTC APIの最も興味深い部分の1つはGetUserMedia APIです。このAPIを使用すると、クライアントから直接オーディオおよびビデオ情報をキャプチャし、他のピアにブロードキャストできます。 このAPIはGoogleを積極的に宣伝しているため、2014年の終わり以来、ハングアウトはWebRTCによって完全に強化されています。 GetUserMediaは、Chrome、Firefox、Operaでも完全に機能します。 IEでWebRTCを操作できるようにする拡張機能もあります。 Safariはこのテクノロジーをサポートしていません。



最近リリースされた制限によると、ChromeのGetUserMedia APIはビーコンサーバー上のHTTPSでのみ機能することに注意することが重要です。 したがって、HTTPサーバー上のネットワークにある多くの例はうまくいきません。



興味深いことに、画面のブロードキャストを許可するためにGetUserMedia APIが使用されていましたが、現在これは不可能です-アドオンを使用するカスタムソリューションのみがあるか、開発時にFirefoxで対応するフラグを有効にすることができます。



GetUserMediaには次の機能があります。

• ビデオストリームの最小、「理想」、および最大解像度の選択。これは、接続速度に応じてビデオの解像度を変更できることを意味します。
• 電話のカメラのいずれかを選択する機能。
• フレームレートを指定する機能。

これらはすべて設定が非常に簡単です。 GetUserMedia APIを呼び出すと、「audio」と「video」という2つのプロパティを持つオブジェクトをそこに渡します。

{ audio: true, video: { width: 1280, height: 720 } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ビデオでは、「true」も指定できます-デフォルトで設定されます。 falseの場合、オーディオまたはビデオはミュートされます。 ビデオを設定できます-幅と高さを指定します。 または、たとえば、最小幅、理想幅、最大幅を設定できます。

 width: { min: 1280 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 width: { min: 1024, ideal: 1280, max: 1920 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、使用したいカメラを選択します（「ユーザー」-前面、「環境」-背面）：

 video: { facingMode: "user" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 video: { facingMode: "environment" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、接続速度とコンピューターリソースに応じて選択される最小、理想、および最大フレームレートを指定することもできます。

 video: { frameRate: { ideal: 10, max: 15 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらは、GetUserMedia APIの機能です。 一方、ビデオおよびオーディオストリームのビットレートを決定する機能と、実際に送信される前に何らかの方法でストリームを操作する機能が明らかに欠けています。 また、もちろん、以前に存在していた画面をブロードキャストする機会を返すことは害になりません。

WebRTCの機能

WebRTCを使用すると、オーディオコーデックとビデオコーデックを変更できます。これらは、送信されるSDP情報で直接指定できます。 一般に、WebRTCはG711とOPUSの2つのオーディオコーデック（ブラウザーに応じて自動的に選択されます）、およびVP8ビデオ形式（HTML5ビデオに最適なGoogleのWebM）を使用します。



WebRTCテクノロジーは、Chromium 17 +、Opera 12 +、Firefox 22+である程度サポートされています。 他のブラウザーの場合、webrtc4all拡張機能を使用できますが、個人的にはSafariで実行できませんでした。 WebRTCをサポートするC ++ライブラリもあります。これは、おそらく、今後デスクトップアプリケーションの形でWebRTC実装を見ることができることを示唆しています。



セキュリティを確保するために、RFC 6347で説明されているトランスポート層セキュリティプロトコルであるDTLSが使用されます。また、前述のように、NATおよびファイアウォールの背後にいるユーザーの接続にはTURNおよびSTUNサーバーが使用されます。

ルーティング

次に、STUNとTURNを使用してルーティングがどのように行われるかを詳しく見てみましょう。



リレーNATを使用したトラバーサル （ TURN ）は、NATまたはファイアウォールの背後にあるホストがTCPまたはUDP接続を介して着信データを受信できるようにするプロトコルです。 これは古いテクノロジーであるため、優先順位はNATのセッショントラバーサルユーティリティ（ STUN ） -UDP接続のみを確立できるネットワークプロトコルを使用することです。



フォールトトレランスを確保するために、複数のSTUNサーバーを選択することができます。これを行う方法は、 手順に示されています 。 また、 ここで STUNサーバーとTURNサーバーへの接続をテストできます 。



STUNおよびTURNサーバーは次のように機能します。 内部IPとファイアウォールを介したネットワークへの外部アクセスを持つ2つのクライアントがあるとします。







これら2つのクライアントを接続してすべてのポートをリダイレクトするには、STUNサーバーとTURNサーバーを使用する必要があります。その後、必要な情報がユーザーに送信され、コンピューター間で直接接続が確立されます。



ICEサーバーを操作するためのアルゴリズム

• RTCPeerConnectionの初期化時にSTUNサーバーへのアクセスを提供します。 パブリックSTUNサーバーを使用できます（たとえば、Googleから）。
• 接続初期化イベントをリッスンし、成功した場合は、ストリーム転送を開始します。
• エラーが発生した場合、TURNサーバーへの要求を実行し、それを介してクライアントを接続しようとします。
• TURNサーバーの十分な帯域幅に注意してください。

ビデオストリームのパフォーマンスと速度

• 30 FPSで720p：1.0〜2.0 Mbps
• 30 FPSで360p：0.5〜1.0 Mbps
• 30 FPSで180p：0.1〜0.5 Mbps

ビデオブロードキャストに割り当てる必要があるWebRTCトラフィックは、WebRTCのパフォーマンスに最大の影響を及ぼします。 2人のユーザーのみがブロードキャストに参加する場合、少なくともFullHDを問題なく整理できます。20人のビデオ会議の場合、問題が発生します。



たとえば、MacBook Air 2015（4 GBのRAM、2 GHzのCore iプロセッサー）で得られた結果です。 GetUserMedia実装のみがプロセッサを11％読み込みます。 Chrome-Chrome接続が初期化されると、3つのChrome（70％、4）が完全なプロセッサ負荷であり、5番目のクライアントが既にブレーキにつながる場合、プロセッサは既に50％でロードされ、WebRTCは最終的にクラッシュします。 もちろん、モバイルブラウザーではさらに悪いことです。2人のユーザーしか接続できませんでした。3人目のユーザーを接続しようとすると、すべてが遅くなり、接続が切断されました。



これはどのように対処できますか？

スケーリングと問題解決

では、何がありますか？ 会議のユーザーごとに、UDP接続を開いてデータを転送する必要があります。 その結果、音声付き480pビデオをブロードキャストするには、1人のユーザーが1〜2メバギット、双方向通信の場合は2〜4メガビットが必要です。 放送用鉄に重い負荷がかかります。



パフォーマンスの問題は、プロキシサーバー（リレー）を使用することで解決されます。プロキシサーバーは、会議の場合はブロードキャスターからデータを受信し、他の全員に配信します。 必要に応じて、1つのサーバーではなく、複数のサーバーを使用できます。



また、ビデオブロードキャストを行う場合、多くの冗長なクライアント情報を送信することを考慮する価値がありますが、これは拒否できます。 たとえば、コースを実施するとき、他の人からのビデオだけでなく、メッセージだけでさえ音だけが必要な場合があります。 また、アクティブなスピーカーを変更した後、接続の1つを中断し、ストリームで受信する情報の種類を変更してから再接続するのが理にかなっている場合があります。 これにより、ネットワーク負荷を最適化できます。



ソフトウェアの制限を考慮することが重要です。1つのWebRTCインスタンスに接続できるピアは256個までです。 遅かれ早かれ、いくつかのサーバーを一緒に接続する必要があるため、これにより、たとえばスケーリングのためにAmazonの巨大で高価なインスタンスを使用することができなくなります。



CreateOffer API



どのように機能しますか？ 送信するSDPデータを作成できるCreateOffer（）APIがあります。







CreateOfferはプロミスです。オファーを作成した後、localDescriptionを直接取得し、オファーをその中に入れて、さらにSDPフィールドとして使用できます。 sendToServerは、マシンの名前（名前）、ターゲットマシンの名前（ターゲット）、タイプオファー、およびSDPが書き込まれているサーバーに要求するための抽象関数です。



サーバーについて少し言いたいと思います。これらの目的のために、WebSocketを使用することは非常に便利です。 誰かが接続するとすぐに、イベントを発行してリスナーを追加できます。 クライアントと一緒にイベントを公開することも非常に簡単です。



動作中のGetUserMedia API



実際には、すべてを少しシンプルにすることができます-GetUserMedia APIを使用できます。 呼び出しの初期化は次のようになります。







ここでは、ビデオとサウンドの両方を送信します。 出力では、mediaStreamオブジェクト（これがデータストリーム）を受け入れるプロミスを取得します。



そして、私たちは電話に出ます：







誰かが電話に出たいとき、私たちのオファーを受け取ります（getRemoteOfferは、サーバーからデータを受け取る抽象関数です）。 次に、GetUserMediaがストリーミングを開始し、onaddstreamとaddstreamについて既に説明しました。 setRemoteDescription-これをRTC用に初期化し、offer'aとして指定し、回答（answer）を送信します。 回答を送信...→ここでは、サーバーへのオファーの送信プロセスについて説明します。その後、ブラウザー間の接続が確立され、ブロードキャストが開始されます。

WebRTCのクライアントサーバーアーキテクチャ

サーバー全体をスケーリングすると、どのように見えますか？ 通常のクライアント/サーバーアーキテクチャのように：







ブロードキャストとストリームを中継するWebサーバーとの間にWebSocket接続とRTCPeerConnectionがあります。 残りはRTCPeerConnectionsをセットアップします。 ブロードキャストに関する情報はプーリングによって取得でき、WebSocket接続の数を節約できます。



このようなアーキテクチャを拡張する方法はあまり多くなく、すべて似ています。 できること：

• サーバーの数を増やします。
• ターゲットオーディエンスが最も混雑するエリアにサーバーを配置します。
• 過剰な生産性を提供するために、結局のところ、この技術は依然として活発に開発されているため、誤動作が発生する可能性があります。

耐障害性を高める

第一に、フォールトトレランスを向上させるには、ビーコンサーバーとリレーサーバーを分離することが理にかなっています。 クライアントに関するネットワーク情報を配信するWebSocketサーバーを使用できます。 中継サーバーはWebSocketサーバーと通信し、それ自体を通じてメディアストリームをブロードキャストします。



さらに、優先度の障害が発生した場合に、あるブロードキャストサーバーから別のブロードキャストサーバーにすばやく切り替える機能を編成できます。



極端な場合、ブロードキャストサーバーに障害が発生した場合にユーザー間の直接接続を確立する可能性を想定することは可能ですが、これは会議に参加する人がほとんどいない場合（10人未満）にのみ適しています。

メディアストリーム表示

クライアント間で交換されるフローを表示する方法の例を次に示します。







onaddstream-リスナーを追加します。 リスナーが追加されたら、video要素を作成し、この要素をページに追加して、ソースとしてストリームを指定します。 つまり、これらすべてをブラウザーで表示するには、受信したストリームとしてソースHTML5ビデオを指定するだけです。 すべてが非常に簡単です。



呼び出しが終了した場合（endCallメソッド）、ビデオ要素を調べ、これらのビデオを停止し、ピア接続を閉じて、アーティファクトやフリーズがないようにします。 エラーが発生した場合、同じ方法で呼び出しを終了します。

便利なライブラリ

最後に、WebRTCを操作するために使用できるライブラリ。 数十行で簡単なクライアントを書くことができます：

• シンプルなピア-私はこのライブラリが本当に好きです。2人のユーザー間の接続を作成する問題を解決します。
• Easyrtc-ビデオ会議を作成できます。
• SimpleWebRTCも同様のライブラリです。
• js-platform / p2p。
• node-webrtc-ライブラリにより、ビーコンサーバーを整理できます。