WebSocket / WebRTCの技術紹介
-
Upload
yasuhiro-mawarimichi -
Category
Technology
-
view
9.151 -
download
3
description
Transcript of WebSocket / WebRTCの技術紹介
WebSocket / WebRTCの技術紹介
2014/02/24
情報機器テクノロジセンタ 回り道 康博
公開版
本日のテーマ
WebSocket WebRTC
2
まずはWebSocket
3
の前に HTTPのおさらい
4
HTTP• Webにおける通信の基本 • HTTPリクエスト=レスポンスのやり取りの繰り返し
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
(並列読み込みによる時間短縮は本題でないので割愛) 5
HTTP• Webにおける通信の基本 • HTTPリクエスト=レスポンスのやり取りの繰り返し
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
(並列読み込みによる時間短縮は本題でないので割愛)
HTML、JavaScript、CSS、…を順に要求
5
HTTP• Webにおける通信の基本 • HTTPリクエスト=レスポンスのやり取りの繰り返し
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
(並列読み込みによる時間短縮は本題でないので割愛)
HTML、JavaScript、CSS、…を順に要求
5
HTTP• Webにおける通信の基本 • HTTPリクエスト=レスポンスのやり取りの繰り返し
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
(並列読み込みによる時間短縮は本題でないので割愛)
HTML、JavaScript、CSS、…を順に要求
5
HTTP• Webにおける通信の基本 • HTTPリクエスト=レスポンスのやり取りの繰り返し
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
…
(並列読み込みによる時間短縮は本題でないので割愛)
HTML、JavaScript、CSS、…を順に要求
5
HTTP• Webにおける通信の基本 • HTTPリクエスト=レスポンスのやり取りの繰り返し
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
…
(並列読み込みによる時間短縮は本題でないので割愛)
HTML、JavaScript、CSS、…を順に要求
描画
5
HTTPの欠点1. リソース(URI)単位でしか要求・取得ができない • 100リソースあったら、100回リクエストとレスポンスを繰り返す
2. 要求をクライアントからしか送れない • 素の方法ではサーバからPUSHできない
3. HTTPヘッダが大きい • 小さいデータを送ると、HTTPヘッダが相対的に大きい
6
HTTPの欠点への対策1. リソース(URI)単位でしか要求・取得ができない
7
HTTPの欠点への対策1. リソース(URI)単位でしか要求・取得ができない
ファイル数を減らす まとめられるファイルをまとめる
7
HTTPの欠点への対策2. 要求をクライアントからしか送れない
8
HTTPの欠点への対策2. 要求をクライアントからしか送れない
PUSH手法を導入する ポーリング、Comet…
8
HTTPの欠点への対策
3. HTTPヘッダが大きい
9
HTTPの欠点への対策
3. HTTPヘッダが大きい
お手上げ 9
で、新しい仕様1. リソース(URI)単位でしか要求・取得ができない
2. 要求をクライアントからしか送れない
3. HTTPヘッダが大きい
10
で、新しい仕様1. リソース(URI)単位でしか要求・取得ができない
2. 要求をクライアントからしか送れない
3. HTTPヘッダが大きい
SPDY≒HTTP 2.0(まだdraft※)
※ 2014/02/13版 http://tools.ietf.org/html/draft-ietf-httpbis-http2-10 10
で、新しい仕様1. リソース(URI)単位でしか要求・取得ができない
2. 要求をクライアントからしか送れない
3. HTTPヘッダが大きい WebSocket
SPDY≒HTTP 2.0(まだdraft※)
※ 2014/02/13版 http://tools.ietf.org/html/draft-ietf-httpbis-http2-10 10
で、新しい仕様1. リソース(URI)単位でしか要求・取得ができない
2. 要求をクライアントからしか送れない
3. HTTPヘッダが大きい WebSocket
SPDY≒HTTP 2.0(ヘッダサイズ圧縮) WebSocket(HTTPを使わない)
SPDY≒HTTP 2.0(まだdraft※)
※ 2014/02/13版 http://tools.ietf.org/html/draft-ietf-httpbis-http2-10 10
改めてWebSocket
11
お話しすること• 概要 • 標準化状況 • 通信イメージ • HTTPとWebSocketの通信量の比較 • 同じくPUSH方式の比較 • ブラウザの対応状況
12
お話ししないこと
• データ形式、パラメータ • 最新の標準化状況 • 現在進行形で新しいドラフトが出ている…
13
WebSocketの概要• HTTPと同じくクライアント=サーバ型 • WebSocketクライアントとWebSocketサーバのペアで動作
• アプリケーション層のプロトコル、下位層はTCP • これもHTTPと同様
• クライアントとサーバの双方からデータを送受信
14
WebSocketの概要• URIスキーム • ws://~(HTTPの「http://~」相当) • wss://~(HTTPの「https://~」相当)
• WebSocketプロトコルに未対応のネットワーク機器が多い • TLS/SSLの上をhttps://~のフリをしてこっそり流すのが常套
15
ws://~
16
TCPHTTP
http://~
WebSocket
ws://~
HTTPプロトコルと異なるデータが流れてくるので 通信経路上のネットワーク機器が通信を遮断する可能性
wss://~
17
TCPTLS/SSL
HTTP
https://~
WebSocket
wss://~
wss://~
17
TCPTLS/SSL
HTTP
https://~
暗号化
WebSocket
wss://~
wss://~
17
TCPTLS/SSL
HTTP
https://~
暗号化
WebSocket
wss://~
暗号化後のレイヤなので、通信経路上では見分けがつかない
wss://~
17
TCPTLS/SSL
HTTP
https://~
暗号化
WebSocket
wss://~
暗号化後のレイヤなので、通信経路上では見分けがつかないws://~より引っかかりにくい
WebSocketの標準化状況• WebSocketプロトコル(@IETF、RFC6455) • Proposed Standard • 通信規格側の仕様 • http://tools.ietf.org/html/rfc6455
• WebSocket API(@W3C) • Candidate Recommendation • Web API側(JavaScriptから使う側)の仕様 • http://www.w3.org/TR/websockets/
18
WebSocketを端的に表すと
Web上でソケット通信っぽいことをするための規格
19
WebSocket通信のイメージ
WebSocket
メッセージ
クライアント サーバ
20
WebSocket通信のイメージ
WebSocket
メッセージ
WebSocketの確立 (HTTPからUPGRADE)
クライアント サーバ
20
WebSocket通信のイメージ
WebSocket
メッセージ
WebSocketの確立 (HTTPからUPGRADE)
クライアント サーバ
20
WebSocket通信のイメージ
WebSocket
メッセージ
WebSocketの確立 (HTTPからUPGRADE)
クライアント サーバ
20
WebSocket通信のイメージ
WebSocket
メッセージ
WebSocketの確立 (HTTPからUPGRADE)
クライアント サーバ
20
WebSocket通信のイメージ
WebSocket
メッセージ
WebSocketの確立 (HTTPからUPGRADE)
クライアント サーバ
双方から任意のデータを送信
20
WebSocket通信のイメージ
WebSocket
メッセージ
クライアント サーバ
21
WebSocket通信のイメージ
WebSocket
メッセージ
クライアント サーバ
送信完了前に別の送信を開始しても可
21
WebSocket通信のイメージ
WebSocket
メッセージクロスしても可
クライアント サーバ
送信完了前に別の送信を開始しても可
21
WebSocket通信のイメージ
WebSocket
メッセージ 22
WebSocketのフレーム• 制御フレーム • Closeフレーム • Pingフレーム • Pongフレーム
• データフレーム • Textフレーム • Binaryフレーム
• 継続フレーム 23
WebSocketのフレームサイズ4 byte
フラグ+基本ペイロード長 (2 byte) 拡張ペイロード長 (0 or 2 or 8 byte) Masking-key (0 or 4 byte) !合計 最小2 byte~最大14 byte
ペイロードデータ(データ格納部) ~8 EiB
24
一方、HTTPレスポンスヘッダAccept-Ranges:bytes Age:243815 Content-Length:371 Content-Type:text/css Date:Thu, 13 Feb 2014 07:14:14 GMT ETag:"a7ac8-173-4a66f8ada8500" Last-Modified:Fri, 24 Jun 2011 06:45:08 GMT Server:Apache …
25
一方、HTTPレスポンスヘッダAccept-Ranges:bytes Age:243815 Content-Length:371 Content-Type:text/css Date:Thu, 13 Feb 2014 07:14:14 GMT ETag:"a7ac8-173-4a66f8ada8500" Last-Modified:Fri, 24 Jun 2011 06:45:08 GMT Server:Apache …
ここだけで約20 byte
25
一方、HTTPレスポンスヘッダAccept-Ranges:bytes Age:243815 Content-Length:371 Content-Type:text/css Date:Thu, 13 Feb 2014 07:14:14 GMT ETag:"a7ac8-173-4a66f8ada8500" Last-Modified:Fri, 24 Jun 2011 06:45:08 GMT Server:Apache …
上記で約200 byte (一般に数百 byteのオーダー)
ここだけで約20 byte
25
HTTPとWebSocketの通信量
• 以下の仮定を置いて比較 • HTTPはヘッダ長は200 byte • WebSocketはマスクあり(4 byteのMasking-keyあり)
26
本文が10 byteの場合• HTTP • 200(byte) + 10(byte) = 210(byte)
!
• WebSocket • 基本ペイロード長の範囲に収まる • 6(byte) + 10(byte) = 16(byte)
27
本文が10 byteの場合• HTTP • 200(byte) + 10(byte) = 210(byte)
!
• WebSocket • 基本ペイロード長の範囲に収まる • 6(byte) + 10(byte) = 16(byte)
圧倒的な差
27
本文が1024 byteの場合• HTTP • 200(byte) + 1024(byte) = 1224(byte)
!
• WebSocket • 拡張ペイロード長で+2 byte • 8(byte) + 1024(byte) = 1032(byte)
28
本文が1024 byteの場合• HTTP • 200(byte) + 1024(byte) = 1224(byte)
!
• WebSocket • 拡張ペイロード長で+2 byte • 8(byte) + 1024(byte) = 1032(byte)
これでも差が大きい
28
通信量はWebSocketが有利
• 本文が小さいほどHTTPとの差が顕著 • 小さいメッセージを頻繁にやり取りするケースで、WebSocketは特に有利
29
話は変わって Webの世界のサーバPUSH
30
PUSH方式の変遷
31
PUSH方式の変遷
ポーリング
31
PUSH方式の変遷
ポーリング
Comet(※)
※ Comet: Ajax+ロングポーリングによるサーバPUSHの総称 31
PUSH方式の変遷
ポーリング
Server Sent Events
Comet(※)
※ Comet: Ajax+ロングポーリングによるサーバPUSHの総称 31
PUSH方式の変遷
ポーリング
Server Sent Events WebSocket
Comet(※)
※ Comet: Ajax+ロングポーリングによるサーバPUSHの総称 31
ポーリングによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH Ajax
32
ポーリングによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH Ajax
32
ポーリングによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH Ajax
32
ポーリングによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
画面を更新
• クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH Ajax
32
ポーリングによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
画面を更新
…
• クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH Ajax
32
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
画面を更新
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
次のPUSH用の リクエストを投げる
画面を更新
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
次のPUSH用の リクエストを投げる
画面を更新
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
次のPUSH用の リクエストを投げる
画面を更新
33
CometによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH データ発生まで
レスポンスを保留
この辺でデータが発生するとラグ
次のPUSH用の リクエストを投げる
画面を更新
33
Server Sent EventsによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
34
Server Sent EventsによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
34
Server Sent EventsによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH データ発生のたびに
送信する
34
Server Sent EventsによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
分割(chunked)データ扱い
データ発生のたびに送信する
34
Server Sent EventsによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
分割(chunked)データ扱い
データ発生のたびに送信する
画面を更新
34
Server Sent EventsによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
分割(chunked)データ扱い
クローズしていないのでさらに送れる
データ発生のたびに送信する
画面を更新
34
Server Sent EventsによるPUSH
クライアント サーバ
HTTPリクエスト
HTTPレスポンス
• Cometを洗練させたWeb標準(W3C CR) • 本格的なPUSH
分割(chunked)データ扱い
クローズしていないのでさらに送れる
データ発生のたびに送信する
画面を更新
34
WebSocketによるPUSH
サーバ
• HTTPの縛りを外して作られたWeb標準 • 本格的なPUSH
WebSocket
メッセージ 35
WebSocketによるPUSH
サーバ
• HTTPの縛りを外して作られたWeb標準 • 本格的なPUSH
WebSocket
メッセージ 35
WebSocketによるPUSH
サーバ
• HTTPの縛りを外して作られたWeb標準 • 本格的なPUSH
WebSocket
メッセージ 35
データ発生のたびに送信する
WebSocketによるPUSH
サーバ
• HTTPの縛りを外して作られたWeb標準 • 本格的なPUSH
画面を更新
WebSocket
メッセージ 35
データ発生のたびに送信する
WebSocketによるPUSH
サーバ
• HTTPの縛りを外して作られたWeb標準 • 本格的なPUSH
画面を更新
WebSocket
メッセージ 35
データ発生のたびに送信する
PUSH方式まとめ
ポーリング
Comet
Server Sent Events WebSocket 36
PUSH方式まとめ
ポーリング
Comet
Server Sent Events WebSocket新
旧
36
PUSH方式まとめ
ポーリング
Comet
Server Sent Events WebSocket新
旧
HTTPの拡張で進化
36
PUSH方式まとめ
ポーリング
Comet
Server Sent Events WebSocket新
旧
HTTPの拡張で進化 突然変異
36
ブラウザのWeb Socket API対応状況ブラウザ名 対応状況
Internet Explorer 10以降Chrome 13以降Firefox 11以降Opera 12.10以降
iOS (UIWebView) 6.0以降iOS (Safari Mobile) 同上Android (WebView) 4.4Android (Chrome) 18以降
• PCの現行ブラウザは基本的に使用可能(但しIE9以下は×) • モバイルはAndroidのWebView(アプリ組み込み用エンジン)が難 • なおWebSocketクライアントが必ずしもブラウザである必要はない
37
WebSocketのまとめ• Webでソケット通信的なことを行うための規格 • WebSocketプロトコルとWebSocket APIから成る • 通信量はHTTPで同内容を送るより少ない • 双方向通信に向いている • モダンブラウザの多くで対応済み • 但しAndroidのWebViewは未
38
続いてWebRTC
39
お話しすること• 概要 • 標準化状況 • 音声・映像通信までの流れ • PeerConnectionの課題 • WebRTCの利用事例 • ブラウザの対応状況
40
お話ししないこと
• MediaCaptureの利用事例 • MediaCaptureはカメラやマイクの入力をキャプチャするための仕様
• MediaCaptureと別のメディア操作用APIを組み合わせることでいろいろ応用できる
41
概要• RTC=Real-Time Communication • 音声/ビデオチャット、データ通信を使ったリアルタイムコミュニケーション • WebRTCは単一の規格でなく、WebでRTCを行うための仕様群
42
表現を変えると
• Web標準でSkype等の機能を実現するための仕様群 • OS毎にネイティブアプリを作らずに • Flashやブラウザプラグインを使わずに
43
WebRTCの標準化状況•WebRTC (@W3C)
• Working Draft • PeerConnectionとDataChannel、DTMFなども • http://www.w3.org/TR/webrtc/
• Media Capture and Streams(@W3C) • Working Draft • ブラウザから動画(カメラ)や音声(マイク)へアクセスするための仕様 • http://www.w3.org/TR/mediacapture-streams/
• RTCWEB(@IETF) • draft • プロトコルやコーデックの取り決め等々 • https://tools.ietf.org/wg/rtcweb/ 以下の各ドラフト
44
WebRTCの利用例
• 1対1のビデオチャット • 画面共有、ファイル共有 • コンタクトセンタ • グループチャット • 他のコミュニケーション規格(SIP、PSTN、…)と相互接続
Dialogicのサイトより引用 https://www.dialogic.com/ja/landing/webrtc.aspx
45
WebRTCの利用例
• 1対1のビデオチャット • 画面共有、ファイル共有 • コンタクトセンタ • グループチャット • 他のコミュニケーション規格(SIP、PSTN、…)と相互接続
この辺からハードルが高い
Dialogicのサイトより引用 https://www.dialogic.com/ja/landing/webrtc.aspx
45
WebRTCを構成する仕様
•PeerConnection • DataChannel •MediaStream
46
PeerConnection
• クライアント同士をP2Pで接続するための仕様 • 下位層はUDP
47
DataChannel
• 任意のデータをPeerConnection経由で送るための仕様 • テキストメッセージとか写真とか資料とか、使い方は自由
48
MediaCapture• 正確にはWebRTCの一部ではない • Specificationも別
• ブラウザからマイクやカメラへアクセスするための仕様 • MeiaCaptureで取得したStreamをPeerConnection経由で通信相手とやり取り • 単独で使える
49
PeerConnectionの流れ
50
一般的な流れWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
• Webアプリ • シグナリング機能
51
一般的な流れWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ①クライアントはSTUNサーバで自身のグローバルIP/Portを確認
• Webアプリ • シグナリング機能
51
一般的な流れWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
②クライアントは自分のIP/Portやアプリ用情報を添えて接続要求を送信
①クライアントはSTUNサーバで自身のグローバルIP/Portを確認
• Webアプリ • シグナリング機能
51
一般的な流れWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
②クライアントは自分のIP/Portやアプリ用情報を添えて接続要求を送信
③繋ぎたい相手のIP/Portをシグナリング機能で確認して接続
①クライアントはSTUNサーバで自身のグローバルIP/Portを確認
• Webアプリ • シグナリング機能
51
STUN• STUN=Simple Traversal of UDP through NAT • またの名をUDPホールパンチング • NATの内側にあるノードからグローバルのIP/Port(トランスポートアドレス)を確認して「穴」を開ける仕組み
52
前述の流れで繋がらないケースWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
53
前述の流れで繋がらないケースWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
ルータのNAT機能やファイアウォールにガードされて、外から中に入れない →シンメトリックNATの可能性
×
53
「シンメトリックNAT」 以外のNAT
• NATの内側のノードが外へアクセスする時、NATは内側と外側のIP/Port同士をマッピングする • リクエストを投げると、外からレスポンスが帰ってこれる
• かつ任意のアドレスから「マッピング済みのIP/Port」へアクセスするとクライアントへ転送してくれる
• なのでSTUNサーバから取得したIP/Portを使って、第三者であるクライアントBがAへ接続できる
54
一般的な流れ(改)Webアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
STUNサーバで確認した IP/Port
55
一般的な流れ(改)Webアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
STUNサーバから見えるIP/Portは第三者も使える →同じIP/PortでBもアクセスできる
STUNサーバで確認した IP/Port
55
シンメトリックNAT• 「内側から外へアクセスした時の相手先からのアクセス」のみポートマッピングが有効 • それ以外は遮断される
• STUNサーバでないクライアントBは、STUNサーバ向けに開けられたIP/Portを使ってもAへ接続できない
56
シンメトリックNATでの流れWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
STUNサーバで確認した IP/Port
57
シンメトリックNATでの流れWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
STUNサーバから見えるIP/PortはSTUNサーバ専用 →Bからはアクセスできない
STUNサーバで確認した IP/Port
57
シンメトリックNAT vs TURNWebアプリケーションサーバ
クライアントA
クライアントB
TURNサーバ向けの IP/Port
58
シンメトリックNAT vs TURNWebアプリケーションサーバ
クライアントA
クライアントB
TURNサーバ
TURNサーバ経由でAとBを接続
TURNサーバ向けの IP/Port
58
シンメトリックNAT vs TURNWebアプリケーションサーバ
クライアントA
クライアントB
TURNサーバ
TURNサーバ経由でAとBを接続
TURNサーバ向けの IP/Port
TURNサーバからの接続なので通れる=勝利 58
TURN• Traversal Using Relay NAT • NATの内側にあるノードに対して透過的な経路(トンネル)を提供する • すべての通信をパススルーするので、ノードが増えるほどTURNサーバの帯域が消費される • STUNサーバに比べて運用コストが高い
59
ICE• Interactive Connectivity Establishment • 常にSTUNを使うとシンメトリックNATの時に到達できない
• 常にTURNを使うとコストが高い • ICEは、STUNが使えない時だけTURNへフォールバックする • WebRTCのPeerConnectionはICEに対応
60
PeerConnectionのまとめ
ネットワーク周りの ハードルが高い
普通のWeb APIと勝手が違うポイント 61
ここでスライドを振り返るWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
②クライアントは自分のIP/Portやアプリ用情報を添えて接続要求を送信
③繋ぎたい相手のIP/Portをシグナリング機能で確認して接続
①クライアントはSTUNサーバで自身のグローバルIP/Portを確認
• Webアプリ • シグナリング機能
62
ここでスライドを振り返るWebアプリケーションサーバ
クライアントA
クライアントB
STUNサーバ
②クライアントは自分のIP/Portやアプリ用情報を添えて接続要求を送信
③繋ぎたい相手のIP/Portをシグナリング機能で確認して接続
①クライアントはSTUNサーバで自身のグローバルIP/Portを確認
• Webアプリ • シグナリング機能
62
ここにWebSocketを使うことが多い
WebRTCとWebSocket• WebRTCはシグナリングが必要だが、シグナリングの手段は任意(仕様外)
• WebSocketはリアルタイムPUSHに向いている • WebRTCに対応しているブラウザはWebSocketにも対応している
63
WebRTCとWebSocket• WebRTCはシグナリングが必要だが、シグナリングの手段は任意(仕様外)
• WebSocketはリアルタイムPUSHに向いている • WebRTCに対応しているブラウザはWebSocketにも対応している
ということでWebSocketが使われる 63
WebRTCの利用事例• PeerConnection周りを肩代わりするサービス • PeerJS • SkyWay
• WebRTCを使ったコミュニケーションプラットフォーム • OpenTok(TokBox)
• WebRTCとSIP等を相互接続する製品 • PowerMedia XMS(Dialogic社)
64
PeerJS• http://peerjs.com/ • OSS(MIT License) • クライアント用ライブラリ(WebRTCのラッパ)の提供 • 対になるサーバの提供(クラウドサービス) !
• 通信周りの実装が簡単に • ブラウザ間の実装差を吸収
65
SkyWay
• http://nttcom.github.io/skyway/ • NTTコミュニケーションズが提供 • PeerJSベース • APIキー(Webアプリ)毎のアクティブ接続状況を確認する機能
66
字幕付きボイスチャット• SkyWayのデモアプリの一つ • Web Speech API(※)を組み合わせて、声をテキスト化して画面に表示 ※ Chromeに実装されている、音声認識のAPI
67
字幕付きボイスチャット• SkyWayのデモアプリの一つ • Web Speech API(※)を組み合わせて、声をテキスト化して画面に表示 ※ Chromeに実装されている、音声認識のAPI
音声チャットの内容がその場でテキスト化されて画面に表示される
67
OpenTok• http://tokbox.com/opentok • TokBox社 • 多者間通話 • 録画 • WebRTC単体ではP2P=1対1、多者間通話の実現はWebアプリ開発者による作り込みが必要
• TokBoxはプラットフォーム機能として提供、簡単に機能を組み込めるように
68
PowerMedia XMS• https://www.dialogic.com/ja/products/media-server-software/xms.aspx • Dialogic社 • メディアサーバ • WebRTCと別のメディア(SIP等)を相互接続 • ラッパライブラリによるWebRTC接続とUI部品
• 音声/動画コーデックを相互変換
69
PowerMedia XMS
PowerMedia XMS
Web Portal
SRTP
Signaling over WebSocket
Agent
IP/PSTN Network
Application Server
RTP
SIP
Media Ctrl
• 既存オペレーターサービスのWebRTCへの置換 • ユーザーはスマホから電話発信及び受信 • Dialogic JS APIを利用してApp. Serverと接続
• XMS Highlights: • オペレーションコストの削減 • WebRTC JS APIの簡便さ • SIP/WebRTCのインターワーキング • WebRTC通話
http://ngw.ntt-at.co.jp/product/media/products/PowerMedia_XMS.html
SIPクライアントとWebRTCクライアントを相互接続 音声/動画コーデックを変換
Dialogic WebRTC JS API
70
ブラウザのWebRTC対応状況ブラウザ名 PeerConnection DataChannel MediaStream
Internet Explorer × 同左 同左Chrome ○/prefixed(※) 同左 同左Firefox ○/prefixed(※) 同左 同左Opera ○/prefixed(※) 同左 同左
iOS (UIWebView) × 同左 同左iOS (Mobile Safari) × 同左 同左Android (WebView) × 同左 同左Android (Chrome) ○/prefixed(※) 同左 同左• Chrome、Firefox、Operaが対応 • APIが流動的なため、各ブラウザともベンダプレフィックス付き • 実装が過渡的なため、本資料ではバージョン番号を明記しない
71
2014/02/24現在
WebRTCの問題• 仕様が流動的 • ブラウザ間、あるいは同一ブラウザでもバージョンによって実装に差異がある
• 当面はPeerJS等のライブラリに依存せざるを得ない • Webアプリ開発者が個別に対応するのは辛い
• IE(Microsoft)とSafari(Apple)が未対応 • 国内ではあまり活発でない • 日本はテレビ電話/ビデオチャットを使う文化が弱い…らしい
72
NTTアドバンステクノロジ株式会社 情報機器テクノロジセンタ 〒212-0014 神奈川県川崎市幸区大宮町1310 ミューザ川崎セントラルタワー
TEL : 044-589-6094 FAX : 044-541-1381 http://www.ntt-at.co.jp/