読者です 読者をやめる 読者になる 読者になる

望月いちろうのREADME.md

書き溜めておいた技術記事や旅行記のバックアップです。

WebRTCについて大まかに説明

WebRTC

WebRTCとは?

ブラウザを介したRTC通信を実現するためのフレームワーク

現在Chrome Firefox実装済み(Safari IEで使用するためのAPIも存在する)

なぜRTCなのか

WebSocketを仕様するような、サーバーを介した通信では、サーバーの計算資源を浪費して非常に高コストであり、動画や音声をやりとりするような通信は困難であったが、クライアント側が直接データ通信を行えば(つまりP2P)、この問題は解決出来る。

RTCに関わる問題

NAT 

ほとんどのクライアントは固定されたグローバルIPアドレスではなく、動的に割り当てられるプライベートIPを使用している。このためにクライアントは互いのIPアドレスを知ることが出来ず直接通信ができなかった。

STUN/TURN シグナリングサーバー

NAT越えを実現するために最低限必要なもの

シグナリングサーバー

通信するクライアント同士をマッチングさせるためのサーバー、たとえばAさんがBさんにビデオ通話をかけたい時は、AさんがシグナリングサーバーにBさんへの通信を申し込み、Bさんが応答した時に通信を許可する。この役を担っているのがシグナリングサーバーである。このときやりとりする情報は大まかに次のようなものになる。

  • セッションのコントロール 接続の開始、終了を伝える。 
  • エラーメッセージ
  • 接続に使用するメタデータ、たとえばコーデックや帯域、メディアの規格など
  • 暗号化のための鍵情報など
  • ネットワーク情報、IPやポート番号など

STUNサーバー

プライベートIPを使用しているクライアントのグローバルIPを通知する

TURNサーバー 

STUNサーバーを使っても通信を確立できなかったときに通信を仲介するサーバー

ICE 

WEBRTCで使用する通信プロトコル

手順は

  1. クライアントはお互いに自身が取得できるアドレス(プライベートIP)を送り、接続を試みる。双方がローカルネットワークの中にあるか、固定IPを使用している場合には、ここで通信が確立して成功となる。 (Hole Panching)

  2. 接続に失敗したときにはクライアントはSTUNサーバーに接続して、グローバルIPを通知してもらう。そして1で取得したIPとグローバルIPを使用して接続を試みる。このとき使用したポート番号によってNATは相手クライアントと通信をしたことがわかるため、このポートへ入ってきた通信はその通信に対する返答であると判断され。クライアントに届くはず。

  3. 複雑なファイアウォールを設定している場合には2の方法を使っても通信を確立できない場合がある。このときはサーバーを経由して通信を行う。このとき仕様するサーバーをTURNサーバーと呼ぶ。計算コストが高い(従量課金のレンタルサーバーを使用するときは注意)が仕方がない。

具体的な実装方法について

シグナリングサーバー

Node.jsのsocket.ioプラグインを使用すれば一瞬で構築可能

STUN/TURNサーバー

http://turnserver.open-sys.org/downloads/v3.2.4.1/turnserver-3.2.4.1-CentOS6.5-x86_64.tar.gz が有効?(ソースを確認しなければ)

クライアントサイドである程度コードを書く必要がありそうです

よくある誤解

WebRTCは最新の技術である。

WebRTCが使用しているクライアント同士が直接通信を行うP2Pという仕組み自体は決して新しいものではなく、オンラインゲームやネット通話などの分野では比較的古くから使用されてきた手法。新しいのはブラウザで直接P2P通信ができるようになったという点。