WebRTCとWebSocketの違い：P2Pかサーバーか
WebRTCとWebSocketの比較
WebRTCとWebSocketの違い（WebhookとHTTPも比較）| We.Inc
WebRTCとWebSocketの違いを解説。P2Pのメディア・データチャネルとクライアント・サーバー型ソケットの比較、WebRTCにシグナリングが必要な理由、Webhookとの違い、HTTPとの違いもまとめています。
WebSocketはブラウザーとサーバーの間に双方向の接続を1本維持し、すべてのメッセージがそのサーバーを経由します。WebRTCはブラウザー同士を直接つなぎ、音声、映像、任意のデータをやり取りします。通信はDTLSとSRTPで暗号化されます。両者はよく組み合わせて使われ、WebRTC通話を確立するためのシグナリングメッセージをWebSocketが運びます。
WebRTCとWebSocketの比較
- 通信相手
- ブラウザー同士（ピアツーピア）
- ブラウザーとサーバー
- 主な用途
- 音声、映像、画面共有、ピア間データ
- アプリとサーバー間のメッセージ
- 接続確立
- 自前のシグナリングでオファー、アンサー、ICE候補を交換
- HTTP Upgradeハンドシェイク1回
- 配信方式
- データチャネルは順序あり・なし、信頼性あり・なしを選択可能
- 順序保証あり、信頼性あり
- 暗号化
- 常に有効（DTLS、SRTP）
- wss://の場合のみ
- サーバーの要否
- シグナリング用、およびピア同士が直接接続できない場合のTURNリレー用に必要
- 必要。接続の相手側そのもの
下のヘルパーで作りたいものを選ぶと、適した技術とその理由が表示されます。この比較とよく混同される2つの疑問、つまりサーバー間通信であるWebhookと、通常のHTTPリクエストについても扱います。
- 自分の機能に最も近いものを選びます。
- どの技術が適しているか、その理由を確認します。
- コードのセクションまでスクロールして、シグナリングの概要とデータチャネルの例を確認します。
- 末尾近くの2つの表で、WebhookおよびHTTPとの比較を確認します。
- サーバーから更新をプッシュするためにWebRTCを使うのはやめましょう。その場合サーバーはピアではなく、WebSocketやイベントストリームのほうがはるかにシンプルです。
- 通話機能を公開する前に、TURNリレーの費用を見込んでおきましょう。ピア同士の直接接続をブロックするネットワークもあり、その場合はすべてのメディアが有料のリレーを経由します。
- シグナリングサーバーは単純に保ちましょう。オファー、アンサー、候補を転送するだけで十分です。MDNは、そのペイロードをサーバーが理解する必要のないブラックボックスとして説明しています。
- ピア間のゲームやライブカーソルのフィードでは、orderedをfalse、maxRetransmitsを0に設定してデータチャネルを開きましょう。遅れたパケットが新しいパケットを妨げなくなります。
よくある質問
WebRTCはWebSocketの代わりになりますか？
なりません。WebRTCには2つのブラウザーが互いを見つける仕組みが組み込まれていないため、接続確立用のメッセージを交換するチャネルが別途必要です。一般的にはWebSocketが使われますが、MDNによればどのトランスポートでも構いません。
WebRTCで映像以外の普通のデータも送れますか？
送れます。RTCPeerConnection.createDataChannel()でピア間にテキストやバイナリデータ用のチャネルを開けます。そのAPIはsend()やmessageイベントを備え、意図的にWebSocketのAPIに近い設計になっています。
WebhookとWebSocketの違いは何ですか？
Webhookは、イベントが発生したときにあるサーバーが別のサーバーのURLへ送るHTTPリクエストで、送信後に接続は終了します。WebSocketは開いたままの接続で、ブラウザーとサーバーが継続して通信できます。
WebSocketはHTTPより速いですか？
小さなメッセージを大量に送る場合は、たいてい速いです。ハンドシェイクは1回だけで、以降のメッセージにはリクエストヘッダーが付かないためです。ページやファイルの読み込みには通常のHTTPが適しており、キャッシュの恩恵も受けられます。
大人数の通話でもWebRTCはピアツーピアですか？
各接続は2つのピア間のものなので、参加者が増えるとフルメッシュはすぐに膨れ上がります。大規模な通話サービスの多くは、代わりにストリームを転送するサーバー経由でメディアを流しますが、これはWebRTCのブラウザーAPI自体の範囲外です。
WebRTCにもサーバーが必要な理由
- 2つのブラウザーが接続する前に、それぞれが相手のセッション記述（SDPのオファーとアンサー）と、ICE候補と呼ばれるネットワークアドレス候補の一覧を知る必要があります。これらのメッセージの受け渡しはWebRTCではなく、あなたに任されています。
- 交換が終わるとICEが候補を順に試し、STUNが各側の公開アドレスの検出を助けます。直接の経路がどれも使えない場合、通信はTURNサーバーによるリレーにフォールバックします。その後のメディアはシグナリングサーバーを経由せず、ピア間で流れます。
WebhookとWebSocketの違い
- この2つは別の問題を解決します。Webhookは、決済プロバイダーやコードホスティングなどのサービスが、登録したURLにHTTPリクエストを送ることで、何かが起きたことをバックエンドに知らせる仕組みです。接続は開いたままにならず、ブラウザーも関与しません。
- WebSocketはユーザーのブラウザーとの回線をつないだままにします。両方を使うパターンもよくあります。Webhookで注文の支払い完了がサーバーに通知され、サーバーがその知らせをWebSocket経由で顧客の開いているページにプッシュします。
HTTPとWebSocketの違い
- 通常のHTTPはリクエストとレスポンスの仕組みです。クライアントが要求し、サーバーが応答します。GETのレスポンスはブラウザーやCDNでキャッシュできます。ページ、ファイル、ほとんどのAPI呼び出しではこれが標準の選択です。
- WebSocketはHTTPリクエストとして始まり、101レスポンスでプロトコルを切り替えて開いたままになります。使うのは、クライアントが要求していないデータをサーバーが送る必要がある場合や、リクエストごとのオーバーヘッドが問題になるほど頻繁にメッセージが行き交う場合に限りましょう。
WebSocketを使ったWebRTCの接続確立
発信側：オファーとデータチャネルを作成
WebSocketは接続確立用のメッセージを転送するだけです。STUNのURLは、選んだサーバーに置き換えるためのプレースホルダーです。
着信側：アンサーを返してチャネルを受け取る
相手側はチャネルを自分で作らず、datachannelイベントで受け取ります。
ゲーム状態用の順序なし・再送なしのチャネル
maxRetransmitsとmaxPacketLifeTimeは同時に設定できません。どちらか一方を選んでください。
WebhookとWebSocketの比較早見表
WebhookとWebSocketの比較
- 接続の主体
- あるサーバーが別のサーバーを呼び出す
- クライアントがサーバーとの回線を開いたままにする
- 存続期間
- イベントごとにHTTPリクエスト1回
- どちらかが閉じるまで開いたまま
- 主な用途
- 決済、リポジトリ、フォームのイベント
- ライブチャット、ダッシュボード、プレゼンス
HTTPとWebSocketの比較早見表
HTTPとWebSocketの比較
- メッセージを始める側
- 常にクライアント
- どちらの側でも可
- 接続
- リクエストの後にレスポンス
- 101でアップグレードし、その後は開いたまま
- キャッシュ
- GETとHEADのレスポンスはキャッシュ可能
- なし
- URLスキーム
- ws://（ポート80）、wss://（ポート443）
2人でのビデオ通話
WebRTC（シグナリングにWebSocketを併用）
音声と映像は低遅延で通話者間を直接流れるべきです。接続確立中のオファー、アンサー、候補の受け渡しは、小さなWebSocketサーバーが担います。
Webアプリのグループチャットルーム
WebSocket
メッセージは保存、モデレーションし、ルームの全員に送る必要があるため、いずれにせよサーバーに置くべきものです。ユーザーごとに1本のソケットがシンプルで適しています。
友人のブラウザーへ大きなファイルを送る
WebRTCデータチャネル
信頼性と順序保証のあるデータチャネルでピア間に直接データを送るため、TURNが必要にならない限り、サーバーがファイルを保存や中継することはありません。
高速な2人対戦ゲームの操作
WebRTCデータチャネル（順序なし）
順序保証をオフにして再送もなしにすると、失われた位置更新は新しい更新を待たせずにスキップされます。審判役のサーバーが必要なら、代わりにそのサーバーへのWebSocketを使いましょう。
決済プロバイダーが注文を確定する
Webhook
支払いが成功すると、プロバイダーのサーバーがあなたのサーバーのURLを呼び出します。ブラウザーは関与せず、接続を開いたままにする必要もありません。
商品ページとそのデータを読み込む
通常のHTTP
リクエストとレスポンスだけで十分で、GETのレスポンスはキャッシュできます。持続的な接続はコストが増えるだけで利点がありません。
何を作っていますか？
機能を選択
おすすめ
無料で始める · クレジットカード不要
関連: ガイド｜Webマーケティングと集客を学ぶ
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る