📹
WebRTCはどう動くのか？
ブラウザ間の直接映像/音声/データ転送
WebRTC（Web Real-Time Communication）はブラウザ間のP2P通信標準です。接続確立プロセスは複雑ですが、一度接続されればサーバーを経由せずに直接メディア/データを転送します。シグナリングサーバー（WebSocketなど）でSDP（セッション記述）とICE candidateを交換し、STUNサーバーでグローバルIPを確認し、直接接続が不可能な場合はTURNサーバーが中継します。
構造ダイアグラム
シグナリングフェーズ（接続準備）
💻
Peer A
SDP Offer生成
① Offer
→
📡
シグナリングサーバー
(WebSocket)
② 転送
→
💻
Peer B
SDP Answer生成
NAT探索 + P2P接続
💻
Peer A
自分のグローバルIPは？
③ STUNリクエスト
↔
STUN
グローバルIP返却
④ P2P直接接続！
ICE candidate交換 → 最適経路選択
💻
Peer B
直接接続できない場合？
→
TURNサーバー
がメディアを中継（relay）
接続完了後
💻
Peer A
映像
音声
データ
↔ サーバー経由なしで直接転送
💻
Peer B
動作フロー
1
Peer Aがシグナリングサーバーに接続（WebSocket）
2
Peer AがRTCPeerConnectionを生成、SDP Offerを生成しシグナリングで送信
3
Peer BがSDP Offerを受信、SDP Answerを生成しシグナリングで応答
4
双方がICE candidateを収集（STUNサーバーでグローバルIPを確認）
5
ICE candidate交換 → 最適経路選択 → P2P直接接続確立
6
直接接続不可時にTURNサーバーがメディアを中継（relay）
メリット
- ✓ サーバーコスト最小化（P2P直接転送）
- ✓ 低遅延通信
- ✓ ブラウザ内蔵API
- ✓ 別途プラグイン不要
デメリット
- ✗ シグナリングサーバーが別途必要
- ✗ NAT/ファイアウォール問題（STUN/TURNが必要）
- ✗ TURNサーバーコスト（中継時）
- ✗ ブラウザ互換性の問題
ユースケース
Google Meet / Zoom（Web版）
ブラウザビデオ通話
画面共有
P2Pファイル転送
リアルタイムゲーム（DataChannel）