RFC 8835 - Transports for WebRTC
- ステータス: Proposed Standard
- 発行日: January 2021
- ストリーム: IETF
- エラッタ: エラッタなし
基本情報
- RFC番号: 8835
- タイトル: Transports for WebRTC
- 日本語タイトル: WebRTCのトランスポート層
- 公開日: 2021年1月
- ステータス: PROPOSED STANDARD (提案標準)
- 著者: H. Alvestrand (Google)
概要 (Abstract)
本仕様は、WebRTCが使用するトランスポートプロトコルスタックを記述します。これには、ICE、DTLS、SRTPなどのコアトランスポートコンポーネントが含まれます。WebRTCはUDPを介してメディアとデータを伝送し、ICEを使用してNATトラバーサルを行い、DTLSを使用してセキュアな接続を確立し、SRTPを使用してメディアストリームを暗号化します。
WebRTCトランスポートスタックの概要
完全なプロトコルスタック
WebRTCプロトコルスタック (上から下へ):
┌─────────────────────────────────────────┐
│ アプリケーション層 (Application) │
│ - オーディオ/ビデオストリーム │
│ - データチャネル (DataChannel) │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ RTP/RTCP (リアルタイム転送プロトコル) │
│ - メディア転送 │
│ - 制御情報 │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ SRTP/SRTCP (セキュアRTP) │
│ - 暗号化されたメディアストリーム │
│ - 認証 │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ DTLS (データグラムTLS) │
│ - 鍵交換 │
│ - エンドツーエンド暗号化 │
│ - 証明書検証 │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ ICE (インタラクティブ接続確立) │
│ - NATトラバーサル │
│ - 候補アドレス収集 │
│ - 接続性チェック │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ UDP (ユーザーデータグラムプロトコル) │
│ - 基底トランスポート │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ IP (インターネットプロトコル) │
│ - IPv4 / IPv6 │
└─────────────────────────────────────────┘
データチャネル追加スタック:
┌─────────────────────────────────────────┐
│ DataChannel API │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ SCTP (ストリーム制御伝送プロトコル) │
│ - 信頼性のある転送 │
│ - メッセージ境界 │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ DTLS │
└─────────────────────────────────────────┘
↓
(ICE + UDP + IP)
なぜUDP?
WebRTCにおけるUDP vs TCP:
TCPの問題点:
❌ ヘッドオブラインブロッキング (Head-of-Line Blocking)
- 1つのパケット損失が全体のストリームをブロック
- リアルタイム音声/映像では許容できない
❌ 接続確立が遅い
- スリーウェイハンドシェイクの遅延
- TLSハンドシェイクの遅延
❌ 柔軟性のない輻輳制御
- 固定アルゴリズム
- リアルタイムメディアに最適化できない
UDPの利点:
✓ ヘッドオブラインブロッキングなし
- 独立したデータパケット
- パケット損失が後続パケットに影響しない
✓ 低レイテンシ
- 確認応答を待つ必要なし
- 即座に送信
✓ 柔軟な制御
- アプリケーション層での輻輳制御
- メディアに最適化
WebRTCの選択:
UDP + アプリケーション層の信頼性
→ メディアはSRTP (非信頼性)
→ データはSCTP (オプションで信頼性)
ICE (Interactive Connectivity Establishment)
ICEの役割
問題: NATトラバーサル
シナリオ:
ユーザーA (192.168.1.100) ← NAT1 ← インターネット → NAT2 → ユーザーB (192.168.1.200)
プライベートIP プライベートIP
問題:
- AはBのプライベートIPに到達する方法がわからない
- BはAのプライベートIPに到達する方法がわからない
- NATが外部接続をブロック
ICEソリューション:
1. 候補の収集 (Candidates)
- Hostキャンディデート: ローカルIP
- Server Reflexiveキャンディデート: NAT公開IP (STUNを介して)
- Relayキャンディデート: リレーアドレス (TURNを介して)
2. 候補の交換 (シグナリングを介して)
3. 接続性チェック (Connectivity Checks)
- すべての候補ペアを試す
- 最適なパスを見つける
4. 接続を確立
候補タイプ
// Hostキャンディデート (ローカルアドレス)
{
type: 'host',
ip: '192.168.1.100',
port: 54321,
protocol: 'udp',
priority: 2130706431,
foundation: '1',
component: 1
}
// Server Reflexiveキャンディデート (STUNで取得した公開アドレス)
{
type: 'srflx',
ip: '203.0.113.1', // 公開IP
port: 12345, // NATマッピングされたポート
protocol: 'udp',
priority: 1694498815,
foundation: '2',
relatedAddress: '192.168.1.100', // ローカルIP
relatedPort: 54321
}
// Relayキャンディデート (TURNリレーアドレス)
{
type: 'relay',
ip: '198.51.100.1', // TURNサーバーIP
port: 3478,
protocol: 'udp',
priority: 16777215,
foundation: '3',
relatedAddress: '203.0.113.1',
relatedPort: 12345
}
優先順位:
Host > Server Reflexive > Relay
(直接接続を優先、リレーは最後の手段)
DTLS (Datagram Transport Layer Security)
DTLSの役割
なぜDTLSが必要か:
問題:
- UDPは安全ではない
- RTPメディアストリームは暗号化が必要
- 鍵交換が必要
DTLSソリューション:
✓ セキュアな接続を確立
✓ 暗号化鍵を交換
✓ 相手を認証
✓ 完全性保護
DTLS vs TLS:
TLS (TCPベース):
- 信頼性のあるトランスポート
- 順序付き配送
- ストリームトランスポート
DTLS (UDPベース):
- 非信頼性トランスポート
- 順序が乱れる可能性
- データグラムトランスポート
→ パケット損失と再順序付けの追加処理が必要
DTLSバージョン:
WebRTC要件: DTLS 1.2以上
推奨: DTLS 1.3
SRTP (Secure RTP)
SRTP暗号化
SRTP = RTP + 暗号化 + 認証
RTPパケット構造:
┌──────────────────────────────────────┐
│ RTPヘッダー (12+バイト) │
│ - V, P, X, CC, M, PT, Seq, TS, SSRC │
├──────────────────────────────────────┤
│ RTPペイロード (メディアデータ) │
│ - オーディオサンプルまたはビデオフレーム │
└──────────────────────────────────────┘
SRTPパケット構造:
┌──────────────────────────────────────┐
│ RTPヘッダー (平文) │
├──────────────────────────────────────┤
│ 暗号化されたペイロード (暗号化) │
│ - 暗号化されたメディアデータ │
├──────────────────────────────────────┤
│ 認証タグ (Authentication Tag) │
│ - HMAC-SHA1または他 │
└──────────────────────────────────────┘
暗号化される内容:
✓ RTPペイロード (メディアデータ)
✗ RTPヘッダー (非暗号化 - ルーティング用)
認証される内容:
✓ RTPヘッダー + 暗号化されたペイロード
データチャネル (DataChannel)
SCTP over DTLS over UDP
データチャネルプロトコルスタック:
アプリケーション層: DataChannel API
↓
トランスポート層: SCTP (Stream Control Transmission Protocol)
↓
セキュリティ層: DTLS
↓
ネットワーク層: ICE + UDP + IP
なぜSCTP?
✓ メッセージ境界を保持 (TCPストリームと異なる)
✓ オプションの信頼性 (再送信を設定可能)
✓ オプションの順序 (ソートを設定可能)
✓ マルチストリームサポート (1つの接続で複数のストリーム)
✓ 輻輳制御
SCTP機能:
1. 信頼性あり/なし オプション
2. 順序あり/なし オプション
3. メッセージ境界
4. 多重化
まとめ
重要ポイント
✓ WebRTCはUDPトランスポートを使用
✓ ICEがNATトラバーサルを処理
✓ DTLSが暗号化を提供
✓ SRTPがメディアを保護
✓ SCTPがデータチャネルをサポート
トランスポートスタック:
アプリケーション → RTP/SCTP → SRTP/DTLS → ICE → UDP → IP
候補タイプ:
Host > Server Reflexive > Relay
暗号化:
DTLSが鍵を交換 → SRTPがメディアを暗号化
データチャネル:
信頼性あり/なし 設定可能
順序あり/なし 設定可能
輻輳制御:
GCCアルゴリズム
帯域幅探索
レート適応
参考文献
関連RFC:
- [RFC 8835] Transports for WebRTC ← 本文書
- [RFC 8445] ICE
- [RFC 6347] DTLS 1.2
- [RFC 3711] SRTP
- [RFC 4960] SCTP
- [RFC 8831] WebRTC Data Channels
まとめ: WebRTCトランスポートスタックは、ICE、DTLS、SRTPの巧妙な組み合わせにより、非信頼性のUDP上に安全で効率的なリアルタイム通信インフラストラクチャを構築します。これらのトランスポート層プロトコルを理解することが、WebRTCをマスターする鍵です!