WebRTC対Websocket：WebRTCがビデオ、オーディオ、およびデータを処理できる場合、なぜWebsocketが必要なのですか？
だから、ビデオ、オーディオ、テキストを許可するチャットアプリを構築しようとしています。どちらを使用するかを決定するために、WebsocketとWebRTCの調査に時間を費やしました。 WebRTCには多くのビデオおよびオーディオアプリがあるので、これは合理的な選択のように思えますが、他に考慮すべき点はありますか？気軽に考えを共有してください。
次のようなもの：
新しいため、WebRTCは一部のブラウザーでのみ使用できますが、websocketはより多くのブラウザーにあるようです。
スケーラビリティ-Websocketsはセッションにサーバーを使用し、WebRTCはp2pのようです
多重化/複数のチャットルーム-Google+ハングアウトで使用されており、実装方法に関するデモアプリをまだ表示しています
サーバー-Websocketsは、複数のマシンに拡張するためにRedisSessionStoreまたはRabbitMQを必要とします
WebRTCは、ビデオ、オーディオ、および任意のデータの高性能で高品質な通信のために設計されています。言い換えれば、あなたが説明したものとまったく同じアプリのために。
WebRTCアプリには、ネットワークおよびメディアメタデータを交換できるサービスが必要です。これは、シグナリングと呼ばれるプロセスです。ただし、シグナリングが行われると、ビデオ/オーディオ/データがクライアント間で直接ストリーミングされ、中間サーバーを介したストリーミングのパフォーマンスコストが回避されます。
一方、WebSocketはクライアントとサーバー間の双方向通信用に設計されています。 WebSocketを介してオーディオとビデオをストリーミングすることは可能ですが（たとえば here を参照）、テクノロジとAPIはWebRTCのように効率的で堅牢なストリーミング用に本質的に設計されていません。
他の回答が述べているように、WebSocketはシグナリングに使用できます。
WebRTCリソース のリストを管理しています：2013年のGoogle I/Oをご覧になることを強くお勧めします プレゼンテーション WebRTCについて。
WebSocket：
IETF標準（6455）を批准し、最新のすべてのブラウザー、さらにweb-socket-jsポリフィルを使用するレガシーブラウザーでもサポートします。
HTTP互換ハンドシェイクとデフォルトポートを使用して、既存のファイアウォール、プロキシ、およびWebサーバーインフラストラクチャでの使用をはるかに容易にします。
はるかに単純なブラウザーAPI。基本的に、2つのコールバックを持つ1つのコンストラクター。
クライアント/ブラウザからサーバーのみ。
TCP上に構築されているため、信頼できる順序どおりのトランスポートのみをサポートします。これは、パケットのドロップが後続のすべてのパケットを遅延させる可能性があることを意味します。
WebRTC：
ChromeおよびFirefoxでサポートされ始めたばかりです。 MSは、互換性のないバリアントを提案しています。 DataChannelコンポーネントは、FirefoxとChromeの間でまだ互換性がありません。WebRTCは理想的な状況ではブラウザー間で動作しますが、それでもほとんどの場合、接続をセットアップするためにシグナリングサーバーが必要です。現在、最も一般的なシグナリングサーバーソリューションはWebSocketを使用しています。
トランスポート層は、接続が正常であるか信頼できるかを選択できるアプリケーションで構成可能です。
複雑で多層的なブラウザAPI。よりシンプルなAPIを提供するJSライブラリがありますが、これらは（WebRTC自体のように）若くて急速に変化しています。
WebsocketはTCPプロトコルを使用します。
WebRTCは主にUDPです。
したがって、Websocketの代わりにWebRTCを使用する主な理由はレイテンシです。 WebSocketストリーミングを使用すると、待ち時間が長くなるか、待ち時間が短くなって途切れがちになります。 WebRTCを使用すると、VoIP通信の重要な要素である低遅延でスムーズな再生を実現できます。
これらのテクノロジーをネットワーク損失、つまり2％でテストしてみてください。 Websocketストリームに大きな遅延が発生します。
webRTCまたはwebsockets？両方を使用しないのはなぜですか。
ビデオ/オーディオ/テキストチャットを構築する場合、webRTCはピアツーピアテクノロジーを使用するため、間違いなく適切な選択です。接続が起動して実行されると、サーバー経由で通信を渡す必要はありません（TURNを使用する場合を除く）。
WebRTC通信をセットアップするときは、何らかのシグナリングメカニズムを使用する必要があります。ここではWebsocketsが良い選択かもしれませんが、webRTCはビデオ/オーディオ/テキスト情報を探す方法です。チャットルームはシグナリングで実行されます。
ただし、ご指摘のとおり、すべてのブラウザーがwebRTCをサポートしているわけではないため、websocketはこれらのブラウザーの優れたフォールバックになることがあります。
セキュリティは、見逃した側面の1つです。
Websocketでは、データは通常、すべてのトラフィックを確認してアクセスできる中央Webサーバーを経由する必要があります。
WebRTCを使用すると、データはエンドツーエンドで暗号化され、サーバーを通過しません（TURNサーバーが必要な場合もありますが、転送するメッセージの本文にはアクセスできません）。
アプリケーションに応じて、これは重要な場合と重要でない場合があります。
大量のデータを送信する場合、webRTCのP2Pアーキテクチャによるクラウド帯域幅コストの節約も検討する価値があります。
Websocketとwebrtcの比較は不公平です。
WebsocketはTCPのトップに基づいています。パケットの境界は、tcpとは異なり、websocketパケットのヘッダー情報から検出できます。
通常、webrtcはwebsocketを使用します。 webrtcのシグナリングは定義されていません。使用するシグナリングの種類はサービスプロバイダー次第です。 SIP、HTTP、JSON、または任意のテキスト/バイナリメッセージが可能です。
シグナリングメッセージは、websocketを使用して送受信できます。
Webrtcは、ピアツーピア接続の一部です。ピアツーピア接続を作成する前に、ピアツーピア接続を確立するためにハンドシェイクプロセスが必要であることは誰もが知っています。また、WebSocketはハンドシェイクプロセスの役割を果たします。
WebsocketとWebRTCを一緒に使用できます。WebsocketはWebRTCの信号チャネルとして使用でき、webrtcはビデオ/オーディオ/テキストチャネルです。また、WebRTCはTURNリレーでもUDPにでき、TURNリレーはTCP HTTPもHTTPSに対応します。多くのプロジェクトでは、WebsocketとWebRTCを併用しています。