WebRTC(PeerJS)で遠隔作業支援システムを作る(基礎知識編)

CodeZine / 2014年9月25日 14時0分

動作検証を行ったネットワーク環境

 本連載ではTIS株式会社が提供している技術ブログ「Tech-Sketch」から「コレは!」というテーマをピックアップし、加筆修正して皆様にお届けしております。今回は「ブラウザ上で動作する遠隔作業支援システム」の構築を念頭に、WebRTCの基礎知識とPeerJSを利用するための環境準備について取り上げます。

■WebRTCとは

 WebRTCは "Web Real-Time Communication" から作られた言葉で、「ブラウザ上でリアルタイムコミュニケーションを実現するための規格」を指します。WebRTCはHTML5で新しく策定された規格で、APIレベルでの標準化はW3C、プロトコルレベルでの標準化はIETFで進められています。

 WebRTCが実装されたブラウザであれば、Adobe Flash Playerなどのプラグインなしに、ブラウザ間でカメラ映像や音声の共有、データの双方向通信などが可能です。

●WebRTCのコア機能

 WebRTCにはさまざまなAPIが定義されていますが、よく利用されるのはJavaScriptから利用できる以下のAPI群です。

ビデオデバイス/オーディオデバイスからストリームデータを取得するAPI(MediaStream API) ブラウザ間でPeer-to-Peer接続を確立するためのAPI(RTCSessionDescription APIとRTCIceCandidate API) ブラウザ間で効率的なデータストリーミングを行うためのAPI(RTCPeerConnection API) ブラウザ間でデータ交換を行うためのAPI(RTCDataChannel API)  開発者はHTML5とこれらのAPIを組み合わせ、WebRTCアプリケーションを組み立てることになります。

●WebRTCをサポートしているブラウザ

 WebRTCは、まだサポートしているブラウザが限られています。現時点(2014年8月)では、Windows/MacOS/AndroidのChrome/Firefox/Opera最新版では動作が確認されていますが、残念ながらInternet ExplorerやSafari、iOSのChromeやOpera、Safariでは動作しません。

 対応ブラウザの詳細は、caniuse.comが参考になります。

■WebRTCの特徴 - P2P通信

 「一度コネクションを確立すればリアルタイムに双方向通信ができる」という意味では、WebRTCはWebSocketと似ています。しかし決定的に異なっているのは、WebRTCはブラウザ同士が直接データをUDPで送受信するPeer-to-Peer(P2P)通信を行うという点です。

WebRTCとWebSocketの違い


 後述しますが、ネットワークの状況によってはP2P通信ができない場合もあります。

●UDPを用いたP2P通信の良い点・面倒な点

 WebRTCの特徴はUDPを用いたP2P通信にありますが、良い点もあれば面倒な点もあります。

UDPを用いたP2P通信の良い点・面倒な点   良い点 面倒な点 P2P ブラウザ同士が相互に直接接続して通信するため、最短のネットワーク経路による高速な通信が可能。WebSocketのようにサーバを経由しないため、サーバが高負荷になり処理が遅延する心配がない。 ブラウザ同士を相互接続するための、経路確立や通信スペックの交換等の準備(シグナリング処理/注1)が必要だが、WebRTC自身はシグナリング処理のプロトコルを定義していないため、何らかの手段で実装しなければならない。 UDP TCPに比べてオーバーヘッドが少ないため、映像や音声といったある程度のパケットロスを許容してでもリアルタイム性を確保したいデータの交換がしやすい。 パケットのロスや順序逆転が致命的な破損を引き起こす場合、伝送されたデータの信頼性を担保する工夫(注2)が必要。UDPの制限である64KBを越えるデータを送信したい場合、データを自力でチャンクに分解する必要もある。

注1 シグナリング処理
 ブラウザ間を直接接続する際、各ブラウザが直接ルーティング可能なネットワークに所属していれば、ブラウザが動作しているPCのIPアドレスやポートを相互に伝え合うだけで通信できます。しかしブラウザが所属するネットワークセグメントが異なり、経路間にFirewallやNATなどが挟まっている場合、お互いへ通信可能な経路を探し出して共有しなければなりません。

 また適切なデータ交換をするためには、通信経路だけでなく、通信に使うプロトコルや帯域、コーデックといった情報もブラウザ間で共有する必要があります。このような、P2P通信を開始するために必要な一連の事前処理のことをシグナリング処理と言います。





注2 データの信頼性を担保する工夫
 WebRTCでデータ交換に用いるRTCDataChannel APIは、通信プロトコルとしてSCTPを採用することで信頼性を確保する規格になっています。しかしRTCDataChannel APIの実装状況はブラウザによって差異があるため、SCTPがうまく動作しない場合には、UDP上で自力で信頼性を確保する実装を行う必要があります。



SCTP(Stream Control Transmission Protocol)とは
 SCTPは、UDPのようにメッセージフレーミングを持ち、かつTCPとほぼ同様のエンドポイント間の安定した順序どおりのデータ配送も実現する、可用性と信頼性の高いトランスポート層のプロトコルです。



●シグナリング処理の詳細

 上述したシグナリング処理について、もう少し詳しく説明しましょう。

 WebRTCのシグナリングは、電話をかける手続きと似ています。ブラウザ間を仲立ちする交換手としてシグナリングサーバが必要ですが、接続元ブラウザ(Caller)から受け取った要求を接続したいブラウザ(Callee)へ受け流すことがシグナリングサーバの仕事です。

シグナリング処理


●Session Description Protocol(SDP)の交換

 SDPとは、P2Pで接続するメディアの種類(音声、映像)やメディアの形式(コーデック)、転送プロトコル 、自身のIPアドレスやUDPポート番号などを記した文字列のことを指します。P2P接続するブラウザは、お互いにこのSDPを交換しなければなりません。これはシグナリングサーバを介して、OfferとAnswerを交換することで実現されます。

(1)Callerが自身のSDPを付けSignaling ServerへOffer送信 (2)Signaling ServerはCalleeにOffer転送 (3)Calleeが自身のSDPを付けてSignaling ServerへAnswer送信 (4)Signaling ServerはCallerにAnswer転送 ●ICE Candidateの共有

 ICE Candidateは、P2Pで接続するブラウザの通信経路の情報を示した文字列です。複数の通信経路が取り得る場合、複数のICE Candidateが交換されます。

(1)CallerからCalleeへ到達できる経路情報(ICE Candidate)をSignaling Serverへ送信 (2)Signaling ServerはCalleeにICE Candidate転送 (3)CalleeからCallerへのIce CandidateをSignaling Serverへ送信 (4)Signaling ServerはCallerにAnswer転送

CodeZine

トピックスRSS

ランキング