【要約】WebRTCの基本：接続の仕組みとP2P・SFUの使い分けについて整理してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がWebRTCを用いたリアルタイム通信を実装する際、ブラウザ間での直接通信を確立するためのネットワーク障壁や、多人数接続時のスケーラビリティ確保に直面する。具体的には以下の課題が存在する。
- ・NATやファイアウォールの存在により、端末同士が直接通信できない。
- ・通信相手のIPアドレスや通信条件を事前に共有する仕組みが必要となる。
- ・接続人数が増加した際、各端末のCPUや帯域が通信負荷に耐えられなくなる。
// Approach
WebRTCの接続プロセスと、要件に応じた2つの主要なアーキテクチャ（P2PとSFU）を提示することで、通信経路の確立とスケーラビリティの問題を解決する。具体的な手法は以下の通りである。
- ・シグナリングサーバーを用いて、通信相手の特定と情報の交換を行う。
- ・STUN/TURNサーバーを活用し、NAT環境下での経路確保を実現する。
- ・SDPを用いて、映像形式や解像度などの通信条件を合意する。
- ・用途に応じて、低コストなP2P方式か、高負荷耐性を持つSFU方式を選択する。
// Result
通信要件に基づいた適切なアーキテクチャの選択指針が得られる。具体的な成果は以下の通りである。
- ・1対1の通信には、低遅延かつ低コストなP2P方式（Amazon Kinesis Video Streams等）が適している。
- ・大人数でのビデオ会議には、端末負荷を抑えられるSFU方式（Amazon Chime SDK等）が適している。
- ・設計段階で、インフラコストと端末負荷のトレードオフを考慮した判断が可能になる。
Senior Engineer Insight
> WebRTCの実装において、単なる「接続」だけでなく「経路確保」と「負荷分散」の設計が成否を分ける。P2Pはインフラコストを抑えられるが、多人数接続時の端末リソース枯渇は致命的だ。一方、SFUはサーバーコストが増大するが、スケーラビリティは高い。実務では、Amazon KVSやChime SDKのようなマネージドサービスの特性を理解し、コストとユーザー体験のバランスを冷徹に判断すべきである。