P2P通信の標準化 WebRTCを知ろう 高橋 晶 (Akira Takahashi) [email protected] Preferred Networks, Inc. 2025/07/18 (金) C++ MIX #15 

WebRTC (Web Real-Time communication) とは • P2P通信の規格・技術・ライブラリ • W3CとIETFで標準化されている • サーバー経由でクライアント同士の通信をするのではなく、クライアント同士 で直接接続する • サーバー経由で通信すると、遅い、サーバー負荷が高いという問題がある • 基本的にUDPで通信する • ビデオ、オーディオ、データ (テキスト、バイナリ) などを 高速に送受信できる • 昔ながらのP2Pは、Bluetoothやローカルネットワーク内のWi-Fi接続が使われ ていたが、インターネットを介したデバイス間通信が広まっている 

WebRTCを使っている主要サービス ビデオ会議・音声チャットの開発に向いている • Google Meet • Zoom • Slack • Discord • Facebook Messenger • Microsoft Teams • Steamリモートプレイ • DJIドローン (遠くまで飛ばすのでBluetoothではないらしい) 

P2P通信の一番の課題 • P2Pで一番むずかしいのは「接続 (NAT越え)」 • 異なるプライベートネットワークの人同士を接続する際には、 ルーターやファイアウォールを突破しないといけない • WebRTCでは、相手と接続するために、2種類のサーバーを使用する • STUNサーバー • TURNサーバー 

STUNサーバー • UDPで接続して、P2P接続できそうな自分の グローバルIP・ポート番号のリストを返してくれる • クライアント同士は、offer側とanswer側に分かれ、 STUNサーバーからもらった接続できそうなIP・ポートリストを、 接続できそうな順に接続を試みていく • Googleが無料のSTUNサーバーを公開してくれている 

TURNサーバー • P2P接続がむずかしい場合 (NAT越えできない場合) に使われるサーバー • 使わないという選択もできる • すべての通信をTURNサーバー経由で相手に送る • すべての通信を中継するので負荷がとても高い • 無料のTURNサーバーはないので、自分でTURNプロトコルをサポートするサーバーを 立てる必要がある • coTurnなど、オープンソースになっているTURNサーバーを実行する • WebRTCの設定で、複数のTURNサーバーを指定できて自動で分散してくれる • 異なるTURNサーバーを使っている同士でも通信できる • TURNサーバー経由でも接続できない場合はある 

NAT越えができないケース • 対称NAT (Symmetric NAT) が使われている • 宛先ごとに外部ポート番号が割り当てられる • 多段NAT • 家庭用ルーター -> 上位ルーターのように複数段になっている場合 • 最も外側のアドレスしかわからないので無理 • UDP通信がブロックされている • プロキシ経由の通信 • 環境としては、 • 職場、学校、寮、ホテル、公共Wi-FiなどでNAT越えできないことが多い 

使用するポートの共通化 • 使用するポート数が多いとそれだけ接続がむずかしくなる • WebRTCではポート番号をひとつだけ使い、 複数ストリームでの通信でもポートを共有する 

通信データ • 基本的にUDPで通信するので、パケットロスが起こる可能性がある • TCP • 順序保証あり • 自動再送信する (パケットロスなし) • UDP • 順序保証なし • 自動再送信しない (パケットロスする) • WebRTCでは、UDP通信でもTCPと同等の保証をオプションでつけられ る • データごとにいつでも切り替えられる • ゲーム用途だと消えてもいいデータ、消えると困るデータ両方があるので便利 

WebRTCの実装 • Googleがオープンソースで、C++実装とJavaScript実装 (ブラウザ用) を公開している • ゲーム用途ならUnity社がcom.unity.webrtcというC#ラッパーを公開し ている • 非同期をawaitで書けるようにしたくらいのラップ 

WebRTC (C++) の例 – Offer側 auto pc = CreatePeerConnection(factory, config); pc->CreateOffer(CreateSessionDescObserver::Create([pc](auto* desc){ pc->SetLocalDescription(SetDescObserver::Create(), desc); std::string sdp; desc->ToString(&sdp); // sdpを相手に送る }), PeerConnectionInterface::RTCOfferAnswerOptions()); • WebRTCでの接続は、Offer側とAnswer側に分かれる • Offer側で作られたSDPという形式の文字列を、サーバーなどを介して Answer側に伝え、それをアドレス代わりにして接続する 

WebRTC (C++) の例 – Answer側 auto pc = CreatePeerConnection(factory, config); // offer側が作ったsdp文字列を受け取る auto desc = CreateSessionDescription("offer", sdp); pc->SetRemoteDescription(SetDescObserver::Create(), desc); pc->CreateAnswer(CreateSessionDescObserver::Create([pc](auto* desc){ pc->SetLocalDescription(SetDescObserver::Create(), desc); }), PeerConnectionInterface::RTCOfferAnswerOptions()); • このあとにIce Candidateと呼ばれるプロトコル・IPアドレス・ポート 番号の組み合わせの交換が行われ、接続できそうな組み合わせが順に 試行されて、接続される 

Google独自のビルドシステム • WebRTC (C++) を自分でビルドするのはわりとたいへん • 独自のビルドスクリプトGN (Generate Ninja) • CMakeは未サポート • GNは.ninjaファイルを生成してくれる手続き型っぽい言語 • 独自のパッケージマネージャDepot Tools (gclient) • 時雨堂が各PC・スマートフォンプラットフォーム向けに ビルドバイナリを提供してくれている • https://github.com/shiguredo-webrtc-build/webrtc-build • それ以外の環境向けにはビルドをがんばらないといけない (一部の機能を無効にしたりとかも) 

じつは昔からWebRTCっぽいP2P通信は行われていた • WebRTCではないが、STUN / TURNサーバーというアイディアは 以前から使われていた • 「モンスターストライクのリアルタイム通信を支える技術 - logmi」 • https://logmi.jp/main/technology/321751 • Skype • 独自プロトコルのSTUNサーバーっぽいものを使っていた • WebRTCライブラリを使わずに、STUNサーバーだけを使うこともでき る (UDPでSTUNプロトコルに従って通信すればよい) • WebRTC / STUN / TURN規格ができたことで、P2P接続を独自で がんばらなくてもよくなった 

まとめ • WebRTCは、P2P通信の規格・技術・ライブラリです • P2P通信で一番むずかしい接続の部分をがんばってくれます • これまで独自でがんばっていた部分が標準化されました • P2P接続できない場合のフォールバックとしてサーバー経由の通信も用意されています • 動画やその他データ配信の便利・安全な機能がついています • QUICベースの新しい規格の策定も進められています • WebTransport、Media over QUIC Transport (MOQT) • 時雨堂が入門資料を書いてくれてたりするので、 よりくわしい情報はそちらを見てください • 時雨堂 WebRTC 入門 (講師資料) v2024-02 • https://gist.github.com/voluntas/b67af408b8950b568e750918920016d8 • WebRTC Meetupというイベントも東京 (品川) で開催されています