---
title: WebRTC
url: https://doc.liz6.com/ja/networking/10-real-time-communication/01-WebRTC
locale: ja
area: networking
tags:
- WebRTC
- signaling
- SDP
- ICE
- Trickle ICE
- STUN
- TURN
- DTLS-SRTP
- SCTP
- Data Channel
- GCC
- simulcast
- SVC
- SFU
- MCU
- mesh
- Opus
- networking
- real-time-communication
date: 2026-06-30
modified: 2026-07-19
description: ブラウザ間での直接オーディオ・ビデオ転送——WebRTCはSDPでメディアパラメータを交渉し、ICEでNATトラバーサルを行い、DTLS-SRTPで暗号化転送を行います。P2Pの「サーバーを経由しない」ことは性能上の利点であると同時に、デバッグの悪夢でもあります。
---
# WebRTC
> ブラウザ間での直接オーディオ・ビデオ転送——WebRTCはSDPでメディアパラメータを交渉し、ICEでNATトラバーサルを行い、DTLS-SRTPで暗号化転送を行います。P2Pの「サーバーを経由しない」ことは性能上の利点であると同時に、デバッグの悪夢でもあります。
## 概要
WebRTC（2011年）はブラウザに組み込まれたリアルタイム通信の標準規格であり、プラグインなしでビデオ通話、画面共有、P2Pデータ転送を実現します。複数のプロトコルを組み合わせています：SDPによるメディア交渉、ICEによるNAT透過、DTLS-SRTPによるメディア暗号化、SCTPによるデータチャネル。WebRTCの接続確立は非同期で行われ、candidateが一つずつ到着し、一つずつ検証されます。Trickle ICEにより接続時間が大幅に短縮されます。
## アーキテクチャスタック
## シグナリング: 意図的に空白とされた一环
WebRTC は**シグナリングを規定していません**——両端がSDPとICE candidateをどのように交換するかは標準では一切規定されず、WebSocket/HTTP/任意のチャネルを使って自分で実装する必要があります。これは意図的な設計です：メディアパスはP2Pである必要がありますが、「まだ接続していない2者が最初にどのように接触するか」には、双方から到達可能なサードパーティが必要です。
まずシグナリングによってoffer/answerが渡され、初めてICEが接続可能なcandidateを持てる——これがWebRTCにおける「鶏が先か卵が先か」の問題である。
## SDP 交渉
```
Caller → Callee (Offer):
v=0
o=- 1234567890 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video data ← 同一トランスポートパスでのマルチプレクス
m=audio 49170 UDP/TLS/RTP/SAVPF 111 103
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtcp-mux ← RTPとRTCPを同一ポートで共有
a=ice-ufrag:8sdf7g
a=ice-pwd:asd88fg
a=fingerprint:sha-256 AB:CD:... ← DTLS証明書ハッシュ
Callee → Caller (Answer):
m=audio 49180 UDP/TLS/RTP/SAVPF 111 ← 選択されたポート + コーデック
...
→ 双方の交渉完了 → ICEによる接続チェック開始
```
## ICE
各peerは3種類のcandidateを収集する：
1. **host**: ローカルIP:port
2. **srflx** (server reflexive): STUNサーバーから返されるパブリックIP:port
3. **relay** (relayed): TURNサーバーが割り当てる中継アドレス
各(local candidate + remote candidate)のペアに対して接続チェック(STUN binding)を実行し → 最適な利用可能なペアを選択する（優先度は host > srflx > relay、つまり「直結可能なら中継を使わない」）。
**STUNとTURNの役割分担**：STUNは単に「自分のパブリックマッピングを問い合わせているだけ」であり、メディアを転送せず、ほぼコストゼロです。しかし、両端が対称型NATの背後にあり、NATトラバーサルが失敗した場合、**TURN中継**にフォールバックする必要があります——すべてのメディアがそれを介して転送され、帯域幅のコストが高くなります。これはデプロイにおいて唯一避けられないサーバーコストです。本番環境での経験則：接続の約10〜20%が最終的にTURNに到達します。
**Trickle ICE**：すべてのcandidateの収集が完了するのを待ってからofferを送信する必要はありません。candidateは発見次第シグナリングを通じて相手側に送信され、接続チェックが行われます。これにより、接続確立時間が「最も遅いcandidateを待つ」状態から「最初の利用可能なペアが準備できるまで」に短縮され——これがWebRTCの高速接続確立の鍵です。
## DTLS-SRTP
DTLSハンドシェイク(TLS 1.2をUDP上で動作させるもの) → ハンドシェイク完了後、双方はDTLSからSRTP鍵を派生する(追加の交換は行わない)：
## Data Channel
DTLS上に覆いかぶさるSCTP (Stream Control Transmission Protocol)：
```
TCPと比較して：
- マルチストリーム (HOLブロッキングなし)
- メッセージ境界を保持
- 設定可能：信頼性あり (reliable) / 部分的信頼性 (timed reliability)
適した用途：ファイル転送、ゲームステート、チャット
```
## 輻輳制御とSimulcast
リアルタイムメディアはTCPのようにパケット損失と再送に頼ることができない——フレームのデッドラインはわずか十数ミリ秒であり、再送を待つと必ずタイムアウトする。WebRTCは**GCC (Google Congestion Control)**を使用する：RTPパケットの到着に基づく**レイテンシ勾配**で輻輳を予測する（キューが増加中 → 早期にビットレートを低下）、実際にパケットが損失するのを待つのではなく、送信側はこれに基づいてエンコードビットレートを動的に調整する。
**Simulcast / SVC** は、マルチユーザー会議における異種帯域幅の問題を解決する：同じカメラ入力から**複数の品質レベル**（例：180p/360p/720p）を同時にエンコードし、ミドルウェアサーバーが各受信者のネットワーク状況に応じて適切な品質レベルを個別に配信する——これが以下のSFUが「視聴者ごとに品質を選択できる」前提である。
## SFU / MCU / Mesh — マルチユーザートポロジー
WebRTCは本来P2Pであるが、マルチユーザーの場合P2Pはスケーラビリティに欠けるため、サーバーの導入が必須となる。3つのトポロジー（[ストリーミングプロトコル](/networking/10-real-time-communication/02-streaming-protocols.md)における配信のトレードオフと同根）：
**なぜWebRTCはHLSのようにCDNで展開しにくいのか**：各接続には状態がある（ICE/DTLS/SRTPのコンテキスト + リアルタイムの輻輳制御フィードバック）ため、キャッシュ可能なファイルではない。大規模展開はエッジキャッシュではなくSFUのカスケードによってのみ可能——これは「サブ秒のリアルタイム性」がもたらす根本的な代償である。
## 参考
- **webrtc.org**: webrtc.googlesource.com
- **ツール**: `chrome://webrtc-internals`
*Keywords: WebRTC, signaling, SDP, ICE, Trickle ICE, STUN, TURN, DTLS-SRTP, SCTP, Data Channel, GCC, simulcast, SVC, SFU, MCU, mesh, Opus*