WebRTC：音声通話とビデオ通話で2つのブラウザーがどのように一致するか

ネタバレ：ありえない。 彼らのために、開発者はそれを行います。



Flashが何年も前に殺され始めたとき、ブラウザゲームだけでなく被害を受けました。 Flashは従来、音声通話やビデオ通話で強力でした。マイク、カメラ、スピーカーへの直接アクセス、UDPパケットを処理する機能。 HTML5では、WebRTCテクノロジーが代わりになりました。 数ヶ月前についにSafariとEdgeに上陸したもの。 これで、iPhoneで開いているWebページから別のWebページ、たとえば、Linux上のFirefox Quantumで開いているWebページに電話をかけることができます。



FlashにないWebRTCの機能の1つは、ブラウザー間のP2P接続の可能性です。 しかし、ピアツーピアが機能するには、プログラマーが苦しむ必要があります。 ブラウザがUDPパケットを送信する場所についてどのように同意するか、および開発者がそれで何をすべきかについて-カットの下で。

「アラーム」-彼らが話さないようにすること

ほとんどのWebRTCチュートリアルには、同じWiFiに接続されている場合に、iPhoneからWindowsラップトップへのビデオ通話を行う際の、Flashのクールな交換、ブラウザーからの音声通話とビデオ通話、ピアツーピアと10メガバイトのビデオストリームに関する遅延のない話があります。 コードとして、彼らは通常、それがいかに単純かを説得力をもって実証するJavaScriptの数行を示します。



秘Theは、WebRTCのラッパーが通常実証されることです。 このようなラッパーは、 RTCPeerConnectionとMediaDevices.getUserMediaを腸の開発者から隠すことに加えて、PubNub、Twilio、またはVoximplantなど、独自のクラウドとテクノロジースタックを使用する2つのブラウザー間のすべての通信を開発者から隠します。 開発者のために仕事をするのは良いことです。 しかし、技術スタックを単純化して、「ボンネット内」で発生するプロセスの誤解が期限を破り、解決策や「技術的問題」を解決するときに時限爆弾を植えることがよくあります。









このストーリーは、WebRTCでのシグナリング、私たちや他の企業が行う方法、既成のサービスを使用せずにゼロからソリューションを作成する場合の方法について説明しています。

P2Pコールにサーバーが必要な理由

「ピアツーピア」というフレーズを聞いて、私たちは通常トレントを思い出します。 中央サーバーがないようです。 WebRTCの「シグナリング」とは何ですか。また、サーバーはどこにありますか？



WebRTCとJavaScriptコードを使用してWebページを作成したとします。 WiFiに接続された3台のラップトップで開き、最初のラップトップから3番目のラップトップへのビデオ通話を行います。 最初のラップトップのWebRTCは、3番目に接続する必要があることをどのように認識しますか？ WebRTC開発者の代わりに何をしますか？



最初に思いついた方法は、最初のラップトップのWebRTCを3番目のラップトップのIPアドレスに送信し、UDPパケットを送信させることでした。 ただし、この方法は、両方のデバイスが同じネットワークに接続されており、このネットワークで相互からのパケットの受信が許可されている場合にのみ機能します（サプライズ-ホテルや会議場でのパブリックWiFiはほとんどの場合許可されません）。 しかし、1つではなく3つのWiFiアクセスポイントがある場合はどうでしょうか。 また、3台のラップトップはすべて異なるアクセスポイントに接続され、同じ仮想IPアドレス（「192.168.0.5」など）を持っています。 最初のラップトップで実行されているブラウザはどこにパケットを送信する必要がありますか？



この状況では呼び出しは行われないと想定できますが、いずれの場合も、両方のラップトップのブラウザーが相互に通信できる「実際の」IPアドレスを持つ外部サーバーが必要です。 しかし、WebRTCの作成者は、音声とビデオはトラフィック集約型の通信であり、何百万人ものSkype for WebまたはGoogleハングアウトユーザーがパブリックサーバーを介して電話をかけると、これらのサーバーがバーストすることを感じました。 WebRTCの作成者は、両方のデバイスに仮想IPアドレスがあり、直接パケットを交換できない場合でも、NATを「パンチ」してP2P接続を確立する機能をテクノロジに付与しました。 回収は同じ「アラーム」でした。 開発者は、2番目のデバイスまたは外部サーバーのWebRTC IPアドレスを単に送信することはできません。 彼は、両方のブラウザがネットワークを慎重に検査し、互いに同意するのを手伝う必要があります。 このために、彼は彼のSignaling Serverを必要とします。

オファー、アンサー、ICE候補、その他の恐ろしい言葉

それでは、2つのブラウザ間のビデオコールは開発者の観点からどのように見えますか？

1. 最初のブラウザーで必要なJavaScriptオブジェクトの準備と作成がすべて完了した後、WebRTCメソッドcreateOffer（）が呼び出され、SDP形式のテキストパッケージ（または、将来、APIのoRTCバージョンが「クラシック」オブジェクトを取得する場合はJSONシリアライズ可能オブジェクト）を返します。 このパッケージには、開発者が必要とするコミュニケーションの種類に関する情報が含まれています。音声、ビデオ、またはデータの送信、どのコーデックが存在するか-このストーリー全体
2. そして今-アラーム。 開発者はどういうわけか （本当に、仕様に書かれています！）このテキストパッケージの提供を2番目のブラウザーに渡す必要があります。 たとえば、インターネット上で独自のサーバーを使用し、両方のブラウザーからWebSocket接続する
3. 2番目のブラウザーでオファーを受け取った後、開発者はsetRemoteDescription（）メソッドを使用してWebRTCにオファーを渡します。 次に、createAnswer（）メソッドを呼び出します。このメソッドは、同じテキストパケットをSDP形式で返しますが、2番目のブラウザーに対して、最初の受信パケットを考慮に入れます
4. シグナリングの継続：開発者は応答テキストパケットを最初のブラウザーに返します
5. 開発者は、最初のブラウザーで回答を受け取った後、すでに述べたsetRemoteDescription（）メソッドを使用してWebRTCに渡します。その後、両方のブラウザーのWebRTCは最小限の相互認識を行います。 接続できますか？ ああ、いや。 実際、すべてが始まったばかりです
6. 両方のブラウザーのWebRTCは、ネットワーク接続の状態の調査を開始します（実際、標準ではこれを行うタイミングが示されておらず、多くのブラウザーでは、WebRTCは対応するオブジェクトを作成した直後にネットワークの調査を開始し、接続時に不要な遅延が発生しないようにします）。 開発者が最初の手順でWebRTCオブジェクトを作成したとき、少なくともSTUNサーバーのアドレスを渡す必要があります。 これは、「私のIPとは何か」というUDPパケットに応答して、このパケットを受信したIPアドレスを送信するサーバーです。 WebRTCはSTUNサーバーを使用して「外部」IPアドレスを取得し、それを「内部」IPアドレスと比較して、NATがあるかどうかを確認します。 もしそうなら、どのNATリバースポートがUDPパケットのルーティングに使用しますか？
7. 時々、両方のブラウザのWebRTCは、onicecandidateコールバックを呼び出し、すでに馴染みのあるSIPパケットに2番目の接続参加者の情報を送信します。 このパッケージには、内部および外部IPアドレス、接続試行、NATが使用するポートなどに関する情報が含まれています。 開発者は、シグナリングを使用してこれらのパケットをブラウザ間で転送します。 送信されたパケットは、 addIceCandidate（）メソッドを使用してWebRTCに送信されます
8. しばらくすると、WebRTCはピアツーピア接続を確立します。 または、NATが干渉する場合は使用できません。 このような場合、開発者はTURNサーバーのアドレスを送信できます。これは外部接続要素として使用されます。両方のブラウザーは、音声またはビデオを含むUDPパケットを送信します。 STUNサーバーが無料で見つかる場合（たとえば、Googleにある場合）、自分でTURNサーバーを上げる必要があります。 そのようにテラバイトのビデオトラフィックを自分自身に渡すことに誰も興味がない

完成したプラットフォームを使用すると、これらすべてのニュアンスを隠すことができます。 Web SDKは、WebRTCを正しく構成し、SDPパケットにパッチを適用し、VoximplantクラウドへのWebSocket接続をサポートし、さらに多くの詳細を処理します。 そしてもちろん、独自のSTUNサーバーとTURNサーバーがあり、どのような場合でも接続が行われます。 しかし、ニュアンスを隠して自分でやることはできません！ ブラウザで利用可能なAPIにより、以下のように、さまざまな方法でアラームを作成できるようになりました。

動作しない単純なHTTPリクエストシグナリング

最初に思い浮かぶのは、最も単純なHTTPサーバーと、ブラウザー側からのxmlHttpRequest / fetchです。 悲しいかな、それは教科書の「こんにちは世界」に対してのみ機能します。 実際には、サーバーは非常に多くのリクエストから落ちます。 これは非常に頻繁に実行する必要があるため、「接続」をクリックすることで、ユーザーは「接続を確立する」ために数分間待たないようにします。 また、WebRTCはリアルタイムのストーリーであり、オファー/アンサー/アイスを非常に迅速に送信する必要があるため、頻繁に行う必要があります。 数秒の遅延でさえ、「何も起こらない」というWebRTCのシグナルとして機能し、その後、エンジンは接続の確立を試行しなくなります。 または、「ロングポーリング」手法を試すこともできますが、実際にはうまく機能せず、中間のインターネットインフラストラクチャはそのような「遅い」HTTPリクエストを中断することを好みます。

WebSockets Signaling： 最も効果的 な 戦略が有用

WebRTCを使用するほとんどのソリューションは、シグナリングにWebSocketを使用します。 このプロトコルは、すでに使用されているWebブラウザーとネットワーク機器の大部分でサポートできるほど「古い」ものです。 また、socket.ioやSocketJSのようなラッパーを使用する場合、WebSocketが機能しないまれなケースでは、HTTPロングポーリングに低下させることができます。これは「少なくとも何らかの形で」機能します。 サーバー側では、データが送信されないWebSocket接続はほとんどリソースを消費せず、サーバーは呼び出しを待っている何万ものWebページを簡単に処理できます。



WebSocketにはどのような問題がありますか？ まあ、接続が時々壊れます-それは処理する必要があります。 また、キープアライブタイムアウトも高くなっています。接続は生きているように見えますが、実際には中間機器のどこかで既に切断されています。 そして、次のキープアライブパケットが来ない場合にのみ、これについて知ることができます。これは10分になることがあります。 その間、彼らは私たちに到達しようとしますが、到達できません。 このメカニズムはブラウザーとサーバーの実装に依存しているため、サーバー側のピンポンフレームは、必要に応じて確認および強化するのに役立ちます。

WebSocketの最新のアナログとしてのHTTP / 2シグナリング

HTTPのバージョン2の人気が高まると、WebSocketとサーバーサイドイベントは過去のものになる可能性があります。 サーバーと双方向の通信のバイナリチャネルであり、これを使用してHTMLページと画像の両方を取得し、WebRTCシグナリングを整理できます。 残念なことに、人気のあるブラウザーの最新バージョンのサポートにもかかわらず、HTTP / 2は、多くのユーザーがいるプロジェクトで使用するのに依然として危険です。 その理由は、インターネットの「スケルトン」を構成する中間機器にあります。 これらすべてのルーター、ゲートウェイ、バリケード、および20歳の猫は、多くの場合HTTP / 2接続を完了し、それが何であるかを理解せず、誰かから何かを「保護」しようとします。

再帰の例としてのWebRTCシグナリング

別のWebRTC接続を使用して、WebRTCに信号を送ることもできます！ 奇妙に聞こえますが、この方法には利点があります。 他のシグナリングを使用して、ブラウザとクラウドの間に最初のWebRTC接続を確立すると（非P2Pコールの場合と同様）、そのような接続ではデータチャネルAPIを使用できます。 これは、「TCPのように」だけでなく「UDPのように」機能し、配信を保証せずに非常に迅速にパケットを送信できるという点で、WebSocketsと比較して有利です。 この方法により、WebSocketsやHTTP / 2よりも高速に接続をシグナルすることができます。 場合によっては、このメソッドが必要です。 たとえば、ゲームで。

TL; DL

説明されているすべてを要約します：WebRTCがピアツーピア接続を確立する前に、開発者は2つのブラウザー（または他のデバイス; Googleのlibwebrtcライブラリにより、C ++コンパイルを移動するすべてでWebRTCを使用して複数のテキストパケットを交換できるようにする必要があります。 これは迅速に行う必要があります。そうしないとタイムアウトになり、何も機能しません。 プラットフォームは、開発者にアラーム（およびそれ以上）を提供しますが、本当に必要な場合は、自分でそれを行うことができます。 たくさんのニュアンスを覚えて、すべてをデバッグしてください。



サイトwww.elasticrtc.comからカタへのイラスト

www.sococo.com/blog/webrtc-signaling-here-be-dragonsのドラゴンイラスト