WebRTCシグナリングおよびトランスポートプロトコル：ベールを引き裂く

VoxImplantプラットフォームは、クラウド、API、さまざまなプラットフォーム用のSDKのいくつかの部分で構成されています。 ブラウザSDKはWebSocketを介してクラウドに接続し、他のVoxImplantユーザーと通常の電話の両方を作成（および着信）できるようにします。 これは以前はフラッシュで動作していましたが、最新のブラウザはWebRTCテクノロジーを使用しており、音声とビデオで動作するように特別に設計されています。 良いことですが、使用するのは非常に困難です。テクノロジーの重要な「チップ」の1つであるピアツーピア通信の機能は、完全に手動で制御されます。 2つのブラウザーがボイスチャットまたはビデオチャットを相互に整理できるように、開発者はコンピューターのIPアドレスに関する情報を収集し、何らかの方法でこの情報をブラウザー間で転送し、NATトラバーサルを実行してすべてをWebRTCにフィードする必要があります。 また、NATを回避できなかった場合は、データ転送用のリレーサーバーを提供します。



最近、インターネット上でブラウザ間の「情報の転送」の技術的な詳細を伝える興味深い記事を見つけました。 Habrに適合した翻訳-猫の下で。

ここの信号はどこにあり、トランスポートレベルはどこにありますか？

プロトコルとしてのWebRTCには「シグナリング」メカニズムが含まれていません。 これは、開発者として、あなたが自分でそれらの世話をする必要があることを意味します。



最初のステップは、プロトコルを選択することです。 さらに正確に言うと、トランスポートとシグナリングの2つのプロトコルです。 ほとんどの場合、違いは見られません（または見たくありません）が、非常に重要な場合もあります。 最近、私は投稿の1つについて質問を受けたため、説明を書くようになりました。

WebブラウザーとWebRTCトランスポートプロトコル

あるデバイスから別のデバイスにメッセージを送信するには、トランスポートプロトコルが必要です。 この場合、メッセージ内の内容やメッセージの構造は関係ありません。送信できることのみです。 そして受け取った。

HTTP / 1.1

5年前、プロトコルについて話すとき、ブラウザは簡単でした。 実際、HTTP / 1.1とその上にあるXHR、SSE、BOSH、Cometとして知られるすべてのハッキングがありました。 メカニックの詳細に興味がある場合は、コメントを残してください。以下の記事で説明を試みます。ただし、少しグーグルで検索すれば簡単に説明を見つけることができます。



HTTP / 1.1松葉杖とともにソリューショングループを呼び出します。 これらのソリューションはHTTP / 1.1を使用します。なぜなら、当時は単に代替手段がなかったからです。しかし、技術的な意味をなさない方法でそれを行います。



はい、RESTを使用できます。 しかし、これもHTTP / 1.1に関連した小さな詳細です。



その後、3つのテクノロジーが登場しました：WebSocket、WebRTC、そして最近ではHTTP / 2。

Webソケット

HTTP / 1.1ではできないことを行うために、WebSocketが追加されました。 クライアントとWebサーバーの両方が互いにメッセージを送信できる双方向メカニズムを提供します。 これらのメッセージの種類、意味、サポートする形式の種類-Webページ開発者が決定します。



socket.ioまたはあまり人気のないSockJSもあります。 どちらも、使用できない場合にWebSocketをエミュレートするクライアント側のメカニズムを提供します。



WebSocketがうまく機能するとき、socket.ioとSockJSも素晴らしいです。 ただし、うまく機能しない場合があります（これについては、HTTP / 2パートで詳しく説明します）。

WebRTCデータチャネル

ある程度まで、データチャネルはWebRTCでシグナリングに使用されます。



はい 使用するIPアドレス、およびその前にICEを使用することに同意する必要があります。 このためには、追加の信号とトランスポートレベルが必要になります（リストはこの投稿にあります）。 接続を確立した後、データチャネルを信号レベルとして使用できます。



データチャネルを使用して、2つのデバイス間で直接信号を送ることも、（タスクに応じて）仲介者を介して信号を送ることもできます。



データチャネルをトランスポートプロトコルとして使用する理由

1. シグナリングの遅延を減らします。 理論的には、データチャネルはあなたができる最速のものです。
2. サーバーの負荷を減らします。 これで、彼はどこかにリダイレクトするためだけにすべてのメッセージを受信することはありません-あなたは彼のために特に意図されているものを彼に送信します。
3. 個人データの機密性/セキュリティのレベルを上げます-サーバーを介してメッセージを送信しない場合、これは彼が送信されているものを覗かないことを意味します-または何らかのメッセージが起こっていることに気付かないことを意味します。

しかし、実際には、このオプションはほとんど使用されません。 WebRTCの世界では、DataChannelがまだ利用できないときに接続が確立される前に、トランスポートレイヤーが重要です。 また、1つの接続のDataChannelをトランスポートレイヤーとして使用して別の接続に信号を送ることは奇妙です。

HTTP / 2

私はすでにHTTP / 2について書きました 。 しかし、それ以来、HTTP / 2はさらに普及し、さらに人気が高まっています。



HTTP / 2は、HTTP / 1.1に存在する多くの制限を取り除きます。 したがって、近い将来、信号レベルのプロトコルの優れた候補になる可能性があります。



HTTP / 2がWebSocketのニーズにどのように影響するかについて、 Alan Denisが詳しく説明しています。

WebRTCシグナリングプロトコル

「シグナリング」とは、自分自身を表現する場所です。 またはあなたのサービス。 あるユーザーが別のユーザーと通信できるようにする必要があります。 または、仮想ルームに参加する人々のグループと。 必要なメッセージの種類、意味、外観などを決定します。



これは信号プロトコルです。



転送プロトコルとは異なり、ブラウザで許可されているものではなく、達成しようとしているものによって制限されます。



WebRTCでよく使用される3つの主要なシグナリングプロトコルを検討してください。

一口

SIPは電話の世界から来ました。 彼の主なトランスポートはUDPでした。 次に、トランスポートプロトコルとしてTCPとTLSが追加されました。 その後、SCTPは自身を引き上げました。 ブラウザを介して使用することはできないため、それらを理解することは意味がありません。 そのため、WebSocketはSIPトランスポートとして追加され、単に「SIP via WebSocket」と呼ばれました。 WebSocket経由のSIPはWebRTC（まだ標準化されていない）の前に標準化されており、とりわけ、独自のRFCをすでに持っています 。 上記のすべてが重要なのはなぜですか？ WebSocketを介したSIPの使用は、WebRTCでのみ可能であるためです。



これはSIPについてです。 また、SIPを知っている場合、SIPを愛している場合、または必要な場合は、WebRTCのシグナリングプロトコルとして使用できます。

Xmpp

私はXMPPが嫌いです。



しかし、その理由はよくわかりません。 おそらく私が彼について何か悪いことを言うと、すべての経験豊かなXMPPファン/フォロワー/狂信者がコメントで彼を守るために急ぐからです。 そして、それは私を笑わせます。



XMPPはすべて、ユーザーステータス情報とクイックメッセージに焦点を当てています。 これらが唯一の要件である場合、特に開発者がすでにXMPPを使用して何ができるかを知っている場合、XMPPが本当に勝ちます。



XMPPが気に入ったら、コメントに返信することを忘れないでください-これは下にあります。

所有権

私はニーが嫌いです。 それにもかかわらず、独自の信号プロトコルには多くの利点があります。



たいていの場合、あなたがしたいのは、1人のページに2人のユーザーを置くだけです。 もうありません。 私は大幅に簡素化することを知っていますが、単純化しないと、一般的なプロトコルの冗長性がすべて必要になります。



他の多くの場合、シグナリングを操作するためだけに別のWebサーバーを追加するのは本当に望ましくありません。 1つのサーバーでWebアプリケーション全体を処理する必要があります。 したがって、独自の信号レベルのプロトコルになります。 あなたはそれを呼び出すことはできませんが。 または、信号レベルのプロトコルとは考えないでください。

選択方法は？

常にシグナリングプロトコルで開始します。



インフラストラクチャがある場合、または接続する外部サービスがある場合は、SIPを使用する必要があります。 必要がない場合はスキップします。



XMPPが好きな場合、またはユーザーステータス情報とクイックメッセージの機能が必要な場合は、それを使用します。



WebRTCを追加するサービスが独自のロジックを持っている場合は、既にシグナリングを持っている可能性があります。 したがって、必要なメッセージを独自のシグナリングに追加するだけです。



他のすべての場合、私のアドバイスは、要件を完全に満たす独自の信号ソリューションを使用することです。 このためにSaaSソリューションを使用することもできます。