WebRTC

概要

WebRTC（Web Real-Time Communication）は、ブラウザ同士がサーバを経由せずに直接つながり、音声・映像・任意のデータをリアルタイムに送り合うための標準技術です。プラグインのインストールなしに、JavaScript の API を呼ぶだけでカメラやマイクの映像を相手のブラウザへ届けられます。Google Meet や Zoom（ブラウザ版）、Discord の通話など、ブラウザで動くビデオ会議・音声通話のほぼすべてが WebRTC の上に成り立っています。

最大の特徴は P2P（ピアツーピア）、つまり「端末同士の直接通信」を基本とすることです。通常の Web 通信はクライアントがサーバに要求して応答をもらう形ですが、WebRTC ではあなたのブラウザと相手のブラウザが直接パイプを結び、映像や音声のパケットが（うまくいけば）互いの端末間を最短経路で流れます。遅延に敏感なリアルタイム通信のために、TCP ではなく UDP を土台に選んでいる点も、Web の他の技術とは一線を画すところです。

なぜ生まれたか

WebRTC 以前、ブラウザでビデオ通話を実現するには Flash などのプラグインに頼るか、専用アプリを配布するしかありませんでした。さらに通信方式の面でも、映像・音声をすべてサーバ経由で中継すると、参加者が増えるほどサーバの帯域コストが膨らみ、中継のぶんだけ遅延も増えます。会話は 200〜300 ミリ秒の遅延でも不自然さを感じるため、「一往復余計にサーバを経由する」こと自体がユーザー体験の敵でした。

そこで 2011 年ごろから Google が中心となり、通話に必要な技術一式（音声・映像コーデック、暗号化、NAT 越え）をブラウザに標準搭載し、端末同士を直接つなぐ仕様として WebRTC が策定されました。P2P にすれば中継サーバの帯域コストが消え、経路も最短になり遅延が減る。「リアルタイム通信をプラグインなしの Web 標準にする」ことと「サーバ中継の遅延・コストをなくす」ことを同時に狙った技術です。

詳細

最大の壁 — NAT 越えと STUN / TURN / ICE

P2P の理想はシンプルですが、現実のインターネットには大きな障害があります。家庭やオフィスの端末はルーターの NAT（ネットワークアドレス変換。プライベートな IPアドレス をグローバルアドレスに変換する仕組み）の内側にいるため、端末自身は「外から見た自分の住所」を知らず、外部から内側の端末へ直接接続を張ることも原則できません。互いに NAT の内側にいる 2 台をどうやって直接つなぐか — これが WebRTC 最大の難所で、STUN・TURN・ICE という 3 つの仕組みで解決します。

STUN（Session Traversal Utilities for NAT）は「外から自分がどう見えているか」を教えてくれる軽量なサーバです。端末が STUN サーバにパケットを送ると、NAT 変換後のグローバルな IP アドレスとポート番号を返してくれます。多くの NAT では、内側から一度パケットを出すとその経路の戻り穴が開くため、双方が互いの「外から見た住所」に向けて同時にパケットを撃ち合えば、直結が成立します（ホールパンチングと呼ばれます）。

しかし企業ネットワークの厳しいファイアウォールや一部の NAT ではこの穴あけが通りません。その保険が TURN（Traversal Using Relays around NAT）で、これは開き直って「中継サーバ経由で転送する」仕組みです。P2P の利点は失われますが、確実につながります。そして ICE（Interactive Connectivity Establishment）が全体の指揮者です。ローカルアドレス・STUN で得たアドレス・TURN 経由のアドレスという複数の「経路候補」を集めて優先順に疎通確認し、つながる中で最良の経路を自動選択します。実サービスでは数％〜1 割程度の接続が TURN 中継に落ちると言われ、TURN サーバの用意は WebRTC 運用の定番コストです。

シグナリングは仕様の外 — WebSocket の出番

もうひとつ意外な設計が、「最初の待ち合わせ方法を WebRTC は規定していない」ことです。P2P を張るには、互いの経路候補や対応コーデックといった情報（SDP と呼ばれる自己紹介文）を事前に交換する必要がありますが、まだつながっていない相手にどうやって渡すのか。この交換をシグナリングと呼び、WebRTC はその手段をアプリ任せにしました。既存のインフラを自由に使えるようにするための割り切りで、実際にはシグナリング用のサーバを立てて WebSocket で中継するのが定番の慣習です。

確立後はシグナリングサーバの役目は終わり、映像も音声もデータも端末間を直接流れます。

暗号化は「任意」ではなく「必須」

WebRTC には平文モードがありません。メディアは SRTP（Secure RTP）で、データは DTLS（TLS の UDP 版）で必ず暗号化され、鍵交換も DTLS ハンドシェイクで行われます。Web で使われる HTTPS が「推奨から必須へ」と時間をかけて移行したのに対し、WebRTC は最初から「暗号化なしの選択肢を仕様上存在させない」設計を採りました。P2P では経路上にどんなネットワークが挟まるか制御できないため、この割り切りは合理的です。

メディアと DataChannel

WebRTC が運べるのは音声・映像だけではありません。MediaStream がカメラ・マイクの映像音声を運ぶ一方、DataChannel は任意のバイナリ・テキストを P2P で送れる汎用の通信路です。信頼性（再送の有無）と順序保証を用途に応じて緩められるのが特徴で、「多少落ちてもいいから最新値を速く」というゲームの位置同期のような通信も、「確実に全部届ける」ファイル転送も、同じ API で書けます。P2P ファイル共有やブラウザ間の画面共有、多人数ゲームなど、通話以外の応用もこの DataChannel が支えています。

なお、多人数のビデオ会議では全員と P2P を張るとアップロード帯域が人数分必要になり破綻するため、実際のサービスは SFU（各参加者の映像を選択的に転送する中継サーバ）を挟む構成が主流です。それでも端末と SFU の間の通信自体は WebRTC で行われており、「1 対 1 は純粋な P2P、多人数は WebRTC ベースの中継」という使い分けが現在の実務の標準形です。