WebRTCとは？

WebRTCの基礎

WebRTCはWeb RealTime Communicationの略称で、W3C（World Wide Web Consortium）が提唱する仕様の名称です。その名前の通り、Webブラウザ上で動作する、遠隔地同士にある複数のWebアプリケーションがリアルタイムに通信することを目的とした仕様です。このWebRTCの仕様は、同じくW3Cが提唱するHTML5の仕様の一部です。このWebRTCでの通信では、映像・音声・データをリアルタイムに送受信することが可能となっており、これらの機能は、基本的には、それぞれのWebブラウザ内に実装されています。WebRTCの仕様では、このWebブラウザ内に実装された様々な機能を使うためのAPIが定義されており、これらのAPIを使ってプログラミングを行うことで、映像・音声・データの送受信が可能となります。

従来、映像・音声・データを遠隔地のアプリケーションと送受信しようとすると、特に映像や音声を送受信する場合に、映像や音声を圧縮するためのコーデックなど、複雑な機能が必要で、なおかつそれらのコーデックを使用するためのライセンスが必要だったりと、一般のWebプログラマが容易に使うことはできませんでした。しかし、WebRTCの登場によって、これらの機能がWebブラウザ内に実装されたため、ライセンスに関しても考慮する必要が無く、そのWebブラウザ内の機能を利用するためのAPIを使うだけで、映像・音声を処理することができるようになりました。このようにWebRTCの登場により、リアルタイムに映像・音声・データを扱うアプリケーションの大幅な増加が見込まれます。

実際に、無料で使える、WebRTCを使ったビデオチャットシステムなどが各種公開されており、その数は現在でも増え続けています。従来は、WebRTCに対応していなかったビデオチャットなどのアプリケーションも、順次 WebRTCへの対応を進めています。また、商用サービスとして提供されているWebアプリケーションも増加しています。

WebRTCの通信方式 P2P

WebRTCでは、通信は基本的にはピア・ツー・ピア（P2P）方式で行われます。P2Pという通信方式は基本的にはサーバを介さずに、ピア同士、つまり端末同士で通信を行う方式です。ピア同士で通信を行う方式のメリットとしては、インターネット上の最短経路で通信を行うことが可能となるため遅延も少なく、サーバを介しないためサーバへの負荷がなく、高い費用をかけてサーバ周辺に帯域幅の大きいインターネット回線を用意する必要がありません。P2P方式の逆の方式がサーバクライアント方式ですが、サーバクライアント方式の場合には、端末の数の増加や通信量の増加にともなってサーバ周辺に大きな帯域幅を確保する必要があり、費用も高額となります。

つまり、WebRTCではP2Pの特徴を活かした通信を行うことができる仕様となっています。

しかしながら、P2Pで通信を行うためには、さまざまな制約もあります。たとえば、多くの端末はファイアウォール（あるいはNAT）の内側に存在し、内側から外部のインターネットにアクセスすることはできますが、その逆に、外部の端末からファイアウォール内の端末にアクセすることはできません。これはセキュリティのためです。しかし、P2Pの方式では、外部から内部へのアクセスが必要となってきます。これらの問題を解決するために、次の項で説明する各種のサーバを設置する必要があります。

つまり、WebRTCでは、簡単に言うと、P2Pの通信を基本としていますが、P2Pで通信できる環境では極力P2Pで通信を行い、P2Pで通信できない環境ではサーバを介した、擬似的なサーバクライアント方式で通信することになります。

WebRTCのサーバ

WebRTCを利用するには、それぞれの端末にインストールされているWebブラウザだけでなく、インターネット上のサーバが必要となります。各端末のWebブラウザは、インターネット上のサーバにアクセスすることで、WebRTCのリアルタイム通信を実行できるようになります。具体的には次のようなサーバが必要となります。

シグナリングサーバ
WebRTC でP2P通信を始めるためには、通信する相手（ピア）と情報を交換する必要があります。具体的には、セッション情報（SDP）と経路情報（ICE Candidate）です。この2種類の情報については後述します。このシグナリングサーバは、WebRTCの仕様としては定義されていません。そのため、独自に実装するか、あるいはあらかじめどこかのベンダが用意したシグナリングサーバを利用する必要があります。
STUN/TURNサーバ
WebRTCでのP2Pの通信において、各端末（ピア）はNATやファイアウォールの中に存在する場合が多くあります。この場合、内部から外部への通信は許可されていても外部から内部への通信は許可されていないため、ピア同士が直接通信することができません。そのため、その通信を介在するためにSTUNサーバおよびTURNサーバが必要となります。STUNサーバは、簡単に言うとファイアウォールやNATに穴を開ける仕組みです。穴を開けたあとはピア同士が通信できます。しかし、この穴を開けることができないファイアウォールやNATの場合、TURNサーバを用いてピア同士の通信の仲介をすることになります。

これらのサーバは独自にインターネット上に設置するか、すでに設置されたものを利用するかのどちらかになります。自由に使えるサーバとしてはNTTコミュニケーションズの「Skyway」が有名です。多数のWebRTCアプリケーションでこのSkywayが利用されています。

WebRTCアプリケーションを開発する方法

WebRTCのAPIは複雑です。そのためPeerJSというライブラリを使うのが簡単にWebRTCアプリケーションを構築する方法です。

WebRTCアプリケーションを開発する方法

WebRTCの問題点とSFU

WebRTCのAPIは複雑です。そのためPeerJSというライブラリを使うのが簡単にWebRTCアプリケーションを構築する方法です。

WebRTCの通信プロトコルがP2P方式のため、問題が生じます。問題というのは、Web会議システムなどで多人数が双方向に通信する場合、たとえば1つの会議に参加する人数が増えると、コネクションの数が指数関数的に増加することです。P2P方式で、多人数の会議室を実現する場合、メッシュ型にコネクションを張る必要が出てきます。たとえば、1対1で通信する場合には、コネクションの数は2です。AさんとBさんが話をする場合、AさんからBさんへのコネクションとBさんからAさんへのコネクションの2つになります。AさんとBさんとCさんが話をする場合、AさんからBさんへのコネクション、AさんからCさんへのコネクション、BさんからAさんへのコネクション、BさんからCさんへのコネクション、CさんからAさんへのコネクション、CさんからBさんへのコネクション・・・と、コネクション数は6になります。これが、たとえば、10人で会議をする場合には、コネクションの数は90になります。また、ネットワークの帯域も問題となります。映像をたとえば500Kbpsで配信する場合、10人の会議室で会議をしようとすると、4.5Mbpsを送信し4.5Mbpsを受信することになります。そのため、WebRTCで1対多のライブ配信を行うのは困難です。500Kbpsの映像を100人に配信しようとすると50Mbpsの帯域が必要となります。

このような問題をSFU（Selective Forwarding Unit）を利用することで解決できます。SFUとは映像を配信する装置あるいは技術を意味しています。SFUは、端末から受け取ったメディアストリームを他の端末に配信します。この場合、たとえばAさんが10人に配信を行う場合には、AさんはSFUにデータを送信し、SFUが同じデータを10人に配信します。SFUを使うことで、上りの帯域を節約することができます。