リモートワークやテレワークが一般化した昨今。社内でのミーティングや社外との打ち合わせで、ビデオ通話をつないで行うWeb会議・テレビ会議を活用している方も多いのではないでしょうか。

そのようなオンライン会議に使用されているツールの多くは、「WebRTC」と呼ばれる技術によって実現しています。

今回はこのWebRTCについて、どのような仕組みで通信を実現しているのか、わかりやすく解説します。

そもそもWebRTCとは？

WebRTCは「Web Real-Time Communication」の略称で、Webブラウザ間で音声やビデオ、データなどをリアルタイムにやり取りする際に用いられる技術です。

リモートワークが一般的となってきた近年、Web会議システムやライブストリーミング・動画配信サービスなどで活用される場面が増えてきています。

WebRTCの対応ブラウザ例

WebRTCは、対応しているブラウザさえあれば誰でも使えるという特徴があります。2021年10月時点では、以下のブラウザがWebRTCに対応しています。

• Google Chrome
• Microsoft Edge
• Mozilla Firefox
• Safari
• Opera

WebRTCの仕組み

WebRTCでリアルタイム通信の実現を可能にしているのは、P2P（Peer to Peer）と呼ばれる通信方式です。ここではWebブラウザ同士が直接通信するために必要な技術であるP2Pについて解説します。

P2P方式について

P2P方式は、ネットワーク上の機器同士が直接接続・通信するための方式のひとつです。

従来のネットワーク通信では、データを提供する「サーバー」と提供されたデータを利用する「クライアント」に役割が分かれるクライアント・サーバー方式が一般的でした。

しかしこの方式では、特定のサーバーに負担が集中して問題が生じた際、すべてのクライアントに影響が及んでしまうという問題がありました。

そこでP2P方式では、機器同士が役割を持たずに直接データをやり取りするため、各クライアントに負担が分散されます。またサーバーのように重要な役割を持った機器が存在しないため、障害が発生したとしても、他の機器同士の通信に影響を与えません。

P2P通信に必要な情報

Webブラウザ同士でP2Pの通信を行うためには、通信相手のIPアドレスなど、接続先の情報が必要です。

ここではWebRTCでP2P通信を行うまでにWebブラウザ間でやり取りされる情報について、詳しく解説します。

Session Description Protocol（SDP）

Session Description Protocol（SDP）は、P2P通信のための基本情報をWebブラウザ間で共有しあうために決められた、情報交換用のプロトコルです。SDPを使って共有される情報は、大きく2つあります。

このように、双方がお互いに接続先の情報や扱える映像や音声の情報を確認し、相互に通信するための準備を行います。

Interactive Connectivity Establishment（ICE）

SDPを利用してお互いのネットワーク情報がわかったら、継続して接続するための経路を見つける必要があります。Interactive Connectivity Establishment（ICE）は、通信可能な経路を確認するためのプロトコルです。

ICEはお互いのネットワーク情報を確認した後、ブラウザ同士が通信するために利用できる通信経路をピックアップします。ICEによって導き出された接続経路の候補は「ICE Candidate」と呼ばれます。

WebRTCでは通信を開始する際、ICE Candidateが見つかった順に接続を試みて、最初につながった経路を採用して通信を行います。

シグナリングサーバー

WebRTC単体では、通信相手の情報を取得・共有できません。そのため「シグナリングサーバー」と呼ばれるサーバーを利用して、相手のユーザー名や通信に必要な情報を取得できるようにしています。

P2P通信を実現するには？

P2Pの通信を行うためには、お互いにIPアドレスの情報を交換し、通信可能な接続経路を決定する必要があります。しかし異なるNAT内の端末は、相手のプライベートIPアドレスを知ることはできません。

このNATをまたぐ接続のことを「NAT越え」と呼び、P2P通信を行ううえでの課題とされています。

NATについて

NATは、組織内ネットワークでのみ使用できる「プライベートIPアドレス」と、世界中のインターネットとつながる「グローバルIPアドレス」を変換する機能のことをいいます。

パソコンからインターネットに接続する場合、プライベートIPアドレスをグローバルIPアドレスに変換する必要があります。その役割を担う機器として挙げられるのが、自宅やオフィスで使われているルーターです。

ルーターを経由するインターネット接続の例

組織内のパソコンなど、プライベートIPアドレスを割り振られている端末は、ルーターを経由してインターネット上に出ていきます。

1. ルーターがパソコンのIPアドレスを、自身の持つグローバルIPアドレスに変換してデータを送り出す。
2. 接続先からルーター宛にデータが返ってくると、ルーターは接続先をパソコンのIPアドレスに変換し、データを返す。

NATを介したネットワークでは、P2P通信が難しい

つまり同一のネットワーク内にない端末同士が接続を行う場合、双方はルーターのグローバルIPアドレスに接続することになります。ルーターにデータが到達したとしても、その先にあるパソコンのプライベートIPアドレスまでは不明なため、インターネット上から直接パソコンに接続することはできません。

この仕組みによって、ブラウザ同士でP2P通信を行おうとした場合にも、インターネット上からの接続が拒否されてしまう問題が発生します。

STUNサーバーとTURNサーバー

互いのIPアドレス情報を交換しなければならない性質上、P2P通信をNATを介したネットワークで行うのは困難です。しかし現在多くのWeb会議システムに使われているWebRTCは、NAT越えを実現しています。

この技術は「STUNサーバー」と「TURNサーバー」と呼ばれる、2種類のサーバーを利用することで可能になります。

STUNサーバー

STUNサーバーは「自端末の外部ネットワークから見たIPアドレスを教えてくれる」役割を持ちます。利用者のパソコンからSTUNサーバーにアクセスすると、STUNサーバーから見たパソコンのIPアドレスとポート番号を返してくれるのです。

パソコンはSTUNサーバーから返ってきた結果から、自身がインターネットに接続する際にNATによってIPアドレスが変換されているかを判断できます。またインターネットから見たパソコン自身のIPアドレスとポート番号のセットがわかるため、P2P通信の相手に接続先情報として共有できます。

TURNサーバー

特に企業のネットワークでは、セキュリティ対策の一環としてファイアウォールが設置されているケースがほとんどです。STUNサーバーを利用して通信したい相手の情報を把握し、直接通信しようとしても、ファイアウォールによって遮断されてしまいます。ここでTURNサーバーが活躍します。

TURNサーバーはP2P通信を行うWebブラウザ間に入り、通信を中継する役割を持っています。

それぞれのWebブラウザは、NATを経由して通信しているつもりでTURNサーバーへ通信を行います。Aのブラウザからきた通信をBのブラウザに中継し、Bのブラウザから返ってきた通信をAのブラウザに返す……という処理を繰り返すのです。

このようにSTUNサーバーとTURNサーバーを組み合わせて使うことで、NATを利用したP2P通信が可能となります。

P2P通信が成立するまでの流れ

複数のWebブラウザ間で通信するためには、SDPを利用して接続するための情報交換を行うなどの準備が必要です。

事前に接続先の情報がわかっている場合、WebRTCのP2P通信が成立するまでの流れは次のようになります。

①ブラウザの準備

Webブラウザでカメラやマイクなどを利用する準備を整えます。

②通信の開始処理

SDPを利用して、接続先の情報を交換します。

③ICEを使って通信経路を設定

ICEの仕組みを利用して、接続相手との接続可能な経路を探します。

④P2P通信開始

相互接続する経路が確定したら、P2P通信が開始されます。

WebRTCで多拠点接続を行う方法

WebRTCでは機器同士が直接接続・通信を行います。そのため接続数が増えると各クライアントの通信量も比例して増加し、リアルタイムで処理することが難しくなるというデメリットがあります。

つまりP2P方式だけで通信を行う場合、接続可能な拠点数に限りがあるということになります。WebRTCで多拠点接続をするには、補助機能を利用する必要があるのです。

ここでは多拠点接続を実現するための、2種類の補助機能を紹介します。

SFU方式

SFU（Selective Forwarding Unit）方式は、すべての通信がサーバーを経由して行われる、クライアント・サーバー方式の通信方法です。

1台のクライアントから送られた通信をSFUサーバーが受け取って、他の拠点へそのまま転送します。これによって各クライアントはSFUサーバーとだけ通信すればよいため、拠点数が増えても負担が増えることはありません。

MCU方式

MCU（Multipoint Control Unit）方式は、SFU方式と同じく、MCUサーバーがすべての通信を中継するクライアント・サーバー方式の通信方法です。

SFU方式との違いは、クライアントから受け取ったデータをそのまま転送するのではなく、合成・変換してから送る点です。これによってMCU方式では、送信元のクライアントに関わらず、すべてのクライアントが同じ方式のデータを受け取れます。

一見MCU方式の方が優れているように見えますが、データを変換する際の負荷が大きいため、利用できる設備のリソースによって適した方式は変わります。