[WebRTC]Turnサーバの利用が必須の状況をテストする
WebRTC (Web Real-Time Communication) は、ブラウザ間でのビデオ、オーディオ、データ通信を可能にする技術ですが、NAT (Network Address Translation) やファイアウォールの影響で、通信が直接確立できない場合があります。このような場合に TURN (Traversal Using Relays around NAT) サーバが必要になります。
本記事では、WebRTC の通信において TURN サーバの利用が必須となる状況をシミュレーションし、テストする方法を解説します。
1. WebRTC の基本的な接続フロー
WebRTC の接続は以下の流れで行われます。
- シグナリング: Peer 間で SDP (Session Description Protocol) を交換。
- ICE (Interactive Connectivity Establishment) 候補の交換: STUN / TURN サーバを利用して通信可能なネットワーク経路を探索。
- ピア接続の確立: 最適な通信経路を選択し、データ通信開始。
通常、STUN サーバが利用可能であれば直接通信 (P2P) できますが、ファイアウォールや対称型 NAT の影響で直接通信が困難な場合は、TURN サーバを介したリレー通信が必要になります。
2. TURNサーバが必須となるケース
TURNサーバが必須となる状況には以下のようなケースがあります。
- 対称型NAT (Symmetric NAT)
- 送信元IPアドレスとポートが変化するため、STUNによるアドレス検出が不可能。
- 厳格なファイアウォール
- UDP通信をすべてブロックする環境。
- 指定ポート以外の通信を許可しないポリシー。
- 企業ネットワーク / 公共Wi-Fi
- ネットワーク管理者がP2P通信を制限している場合。
3. TURNサーバの利用が必須の状況をテストする
WebRTCを用いたアプリ開発においてTURNサーバが必須の状況下でのテストを実施する必要があるかと思います。
STUN/TURNサーバがサードパーティなどを使用していてサーバサイドでの制限が難しい場合、弊社では以下の方法を用いてテストを行います。
① ネットワークの設定によりUDPポートをブロックする
② 端末の設定によりUDPポートをブロックする
これにより、UDPベースの WebRTC 通信が失敗し、TURN サーバ経由の TCP 通信が強制されます。
WebRTC では、通常 UDP を使用して P2P 通信を確立します。UDP はリアルタイム通信に適しており、パケットの順序制御や再送制御が不要なため、低遅延での通信が可能です。
しかし、UDP がブロックされると、WebRTC は TCP を用いた TURN リレー経由の通信へフォールバックするようになります。この動作を利用して、TURN サーバ経由の通信を強制し、その挙動をテストすることができます。
さいごに
弊社では、WebRTCを活用した開発案件を承っております。
音声・映像通信システムの開発に関するご相談がございましたら、問い合わせフォームよりお気軽にお問い合わせください。