Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
公 開 版 WebSocket / WebRTCの技術紹介 2014/02/24 情報機器テクノロジセンタ 回り道 康博
本日のテーマ WebSocket WebRTC 2
まずはWebSocket 3
の前に HTTPのおさらい 4
HTTP • Webにおける通信の基本 • HTTPリクエスト＝レスポンスのやり取りの繰り返し クライアント サーバ HTTPリクエスト HTTPレスポンス （並列読み込みによる時間短縮は本題でないので割愛） 5
HTTP • Webにおける通信の基本 • HTTPリクエスト＝レスポンスのやり取りの繰り返し クライアント HTML、JavaScript、 CSS、…を順に要求 サーバ HTTPリクエスト HTTPレスポンス （並列読み込みに...
HTTP • Webにおける通信の基本 • HTTPリクエスト＝レスポンスのやり取りの繰り返し クライアント HTML、JavaScript、 CSS、…を順に要求 サーバ HTTPリクエスト HTTPレスポンス （並列読み込みに...
HTTP • Webにおける通信の基本 • HTTPリクエスト＝レスポンスのやり取りの繰り返し クライアント HTML、JavaScript、 CSS、…を順に要求 サーバ HTTPリクエスト HTTPレスポンス （並列読み込みに...
HTTP • Webにおける通信の基本 • HTTPリクエスト＝レスポンスのやり取りの繰り返し クライアント HTML、JavaScript、 CSS、…を順に要求 サーバ … HTTPリクエスト HTTPレスポンス （並列読み...
HTTP • Webにおける通信の基本 • HTTPリクエスト＝レスポンスのやり取りの繰り返し クライアント … 描画 HTML、JavaScript、 CSS、…を順に要求 サーバ HTTPリクエスト HTTPレスポンス （...
HTTPの欠点 1. リソース（URI）単位でしか要求・取得ができ ない • 100リソースあったら、100回リクエストとレスポンス を繰り返す 2. 要求をクライアントからしか送れない • 素の方法ではサーバからPUSHできない 3....
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）単位でしか要求・取得ができ ない SPDY HTTP 2.0（まだdraft※） 2. 要求をクライアントからしか送れない 3. HTTPヘッダが大きい ※ 2014/02/13版 http://too...
で、新しい仕様 1. リソース（URI）単位でしか要求・取得ができ ない SPDY HTTP 2.0（まだdraft※） 2. 要求をクライアントからしか送れない WebSocket 3. HTTPヘッダが大きい ※ 2014/02/13版...
で、新しい仕様 1. リソース（URI）単位でしか要求・取得ができ ない SPDY HTTP 2.0（まだdraft※） 2. 要求をクライアントからしか送れない WebSocket 3. HTTPヘッダが大きい SPDY HTTP 2.0...
改めてWebSocket 11
お話しすること • 概要 • 標準化状況 • 通信イメージ • HTTPとWebSocketの通信量の比較 • 同じくPUSH方式の比較 • ブラウザの対応状況 12
お話ししないこと • データ形式、パラメータ • 最新の標準化状況 • 現在進行形で新しいドラフトが出ている… 13
WebSocketの概要 • HTTPと同じくクライアント＝サーバ型 • • アプリケーション層のプロトコル、下位層 はTCP • • WebSocketクライアントとWebSocketサーバの ペアで動作 これもHTTPと同様 ...
WebSocketの概要 • URIスキーム • • • ws://∼（HTTPの「http://∼」相当） wss://∼（HTTPの「https://∼」相当） WebSocketプロトコルに未対応のネッ トワーク機器が多い • ...
ws://∼ HTTPプロトコルと異なるデータが流れてくるので 通信経路上のネットワーク機器が通信を遮断する可能性 HTTP WebSocket TCP http://∼ ws://∼ 16
wss://∼ HTTP WebSocket TLS/SSL TCP https://∼ wss://∼ 17
wss://∼ HTTP WebSocket TLS/SSL 暗号化 TCP https://∼ wss://∼ 17
wss://∼ 暗号化後のレイヤなので、通信経路上では見分けがつかない HTTP WebSocket TLS/SSL 暗号化 TCP https://∼ wss://∼ 17
wss://∼ ws://∼より引っかかりにくい 暗号化後のレイヤなので、通信経路上では見分けがつかない HTTP WebSocket TLS/SSL 暗号化 TCP https://∼ wss://∼ 17
WebSocketの標準化状況 • WebSocketプロトコル（@IETF、RFC6455） • • 通信規格側の仕様 • • Proposed Standard http://tools.ietf.org/html/rfc645...
WebSocketを端的に表すと Web上でソケット通信っぽい ことをするための規格 19
WebSocket通信のイメージ クライアント サーバ WebSocket メッセージ 20
WebSocket通信のイメージ WebSocketの確立 （HTTPからUPGRADE） クライアント サーバ WebSocket メッセージ 20
WebSocket通信のイメージ WebSocketの確立 （HTTPからUPGRADE） クライアント サーバ WebSocket メッセージ 20
WebSocket通信のイメージ WebSocketの確立 （HTTPからUPGRADE） クライアント サーバ WebSocket メッセージ 20
WebSocket通信のイメージ WebSocketの確立 （HTTPからUPGRADE） クライアント サーバ WebSocket メッセージ 20
WebSocket通信のイメージ WebSocketの確立 （HTTPからUPGRADE） クライアント 双方から任意のデータを送信 サーバ WebSocket メッセージ 20
WebSocket通信のイメージ クライアント サーバ WebSocket メッセージ 21
WebSocket通信のイメージ 送信完了前に別の送信を開始しても可 クライアント サーバ WebSocket メッセージ 21
WebSocket通信のイメージ 送信完了前に別の送信を開始しても可 クライアント サーバ WebSocket クロスしても可 メッセージ 21
WebSocket通信のイメージ WebSocket メッセージ 22
WebSocketのフレーム • 制御フレーム • • Pingフレーム • • Closeフレーム Pongフレーム データフレーム • • • Textフレーム Binaryフレーム 継続フレーム 23
WebSocketのフレームサイズ 4 byte フラグ＋基本ペイロード長 (2 byte) 拡張ペイロード長 (0 or 2 or 8 byte) Masking-key (0 or 4 byte) ! 合計 最小2 byte∼最大14 by...
一方、HTTPレスポンスヘッダ Accept-Ranges:bytes Age:243815 Content-Length:371 Content-Type:text/css Date:Thu, 13 Feb 2014 07:14:14 GMT...
一方、HTTPレスポンスヘッダ Accept-Ranges:bytes Age:243815 ここだけで約20 byte Content-Length:371 Content-Type:text/css Date:Thu, 13 Feb 201...
一方、HTTPレスポンスヘッダ Accept-Ranges:bytes Age:243815 ここだけで約20 byte Content-Length:371 Content-Type:text/css Date:Thu, 13 Feb 201...
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(...
本文が10 byteの場合 • HTTP • 200(byte) + 10(byte) = 210(byte) ! • WebSocket • 基本ペイロード長の範囲に収まる • 圧倒的な差 6(byte) + 10(byte...
本文が1024 byteの場合 • HTTP • 200(byte) + 1024(byte) = 1224(byte) ! • WebSocket • 拡張ペイロード長で+2 byte • 8(byte) + 1024(byt...
本文が1024 byteの場合 • HTTP • 200(byte) + 1024(byte) = 1224(byte) ! • WebSocket これでも差が大きい • 拡張ペイロード長で+2 byte • 8(byte...
通信量はWebSocketが有利 • 本文が小さいほどHTTPとの差が顕著 • 小さいメッセージを頻繁にやり取りす るケースで、WebSocketは特に有利 29
話は変わって Webの世界のサーバPUSH 30
PUSH方式の変遷 31
PUSH方式の変遷 ポーリング 31
PUSH方式の変遷 ポーリング Comet（※） ※ Comet: Ajax＋ロングポーリングによるサーバPUSHの総称 31
PUSH方式の変遷 ポーリング Comet（※） Server Sent Events ※ Comet: Ajax＋ロングポーリングによるサーバPUSHの総称 31
PUSH方式の変遷 ポーリング Comet（※） Server Sent Events WebSocket ※ Comet: Ajax＋ロングポーリングによるサーバPUSHの総称 31
ポーリングによるPUSH • クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH クライアント Ajax サーバ HTTPリクエスト HTTPレスポンス 32
ポーリングによるPUSH • クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH クライアント Ajax サーバ HTTPリクエスト HTTPレスポンス 32
ポーリングによるPUSH • クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH クライアント Ajax サーバ HTTPリクエスト HTTPレスポンス 32
ポーリングによるPUSH • クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH Ajax 画面を更新 クライアント サーバ HTTPリクエスト HTTPレスポンス 32
ポーリングによるPUSH • クライアント契機でHTMLやXML/jsonを取得 • 疑似PUSH Ajax 画面を更新 クライアント サーバ … HTTPリクエスト HTTPレスポンス 32
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 33
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 33
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH クライアント データ発生まで レスポンスを保留 サーバ HTTPリクエスト HTTPレスポンス 33
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH クライアント データ発生まで レスポンスを保留 サーバ HTTPリクエスト HTTPレスポンス 33
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH 画面を更新 クライアント データ発生まで レスポンスを保留 サーバ HTTPリクエスト HTTPレスポンス ...
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH 画面を更新 クライアント データ発生まで レスポンスを保留 サーバ 次のPUSH用の リクエストを投げる HT...
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH 画面を更新 クライアント データ発生まで レスポンスを保留 サーバ 次のPUSH用の リクエストを投げる HT...
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH 画面を更新 クライアント データ発生まで レスポンスを保留 サーバ 次のPUSH用の リクエストを投げる HT...
CometによるPUSH • サーバ契機でHTMLやXML/jsonを取得 • サーバからの即応性が改善された擬似PUSH 画面を更新 クライアント 次のPUSH用の リクエストを投げる データ発生まで レスポンスを保留 サーバ こ...
Server Sent Eventsによる PUSH • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 34
Server Sent Eventsによる PUSH • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH クライアント サーバ HTTPリクエスト HTTPレスポンス 34
Server Sent Eventsによる PUSH • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH クライアント データ発生のたびに 送信する サーバ HTTPリクエスト HTTPレスポンス 34
Server Sent Eventsによる PUSH • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH データ発生のたびに 送信する クライアント サーバ 分割（chunked）データ扱い HTTPリクエ...
Server Sent Eventsによる PUSH • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH データ発生のたびに 送信する 画面を更新 クライアント サーバ 分割（chunked）データ扱い H...
Server Sent Eventsによる PUSH • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH データ発生のたびに 送信する 画面を更新 クライアント サーバ 分割（chunked）データ扱い クロ...
Server Sent Eventsによる PUSH • Cometを洗練させたWeb標準（W3C CR） • 本格的なPUSH データ発生のたびに 送信する 画面を更新 クライアント サーバ 分割（chunked）データ扱い クロ...
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方式まとめ ポーリング HTTPの拡張で進化 旧 Comet Server Sent Events WebSocket 新 36
PUSH方式まとめ ポーリング HTTPの拡張で進化 Comet Server Sent Events 旧 突然変異 WebSocket 新 36
ブラウザのWeb Socket API 対応状況 ブラウザ名 対応状況 Internet Explorer 10以降 Chrome 13以降 Firefox 11以降 Opera 12.10以降 iOS (UIWebView...
WebSocketのまとめ • Webでソケット通信的なことを行うための規格 • WebSocketプロトコルとWebSocket APIから 成る • 通信量はHTTPで同内容を送るより少ない • 双方向通信に向いている • ...
続いてWebRTC 39
お話しすること • 概要 • 標準化状況 • 音声・映像通信までの流れ • PeerConnectionの課題 • WebRTCの利用事例 • ブラウザの対応状況 40
お話ししないこと • MediaCaptureの利用事例 • MediaCaptureはカメラやマイクの入力をキャ プチャするための仕様 • MediaCaptureと別のメディア操作用APIを 組み合わせることでいろいろ応用できる ...
概要 • RTC＝Real-Time Communication • 音声／ビデオチャット、データ通信を 使ったリアルタイムコミュニケーショ ン • WebRTCは単一の規格でなく、Web でRTCを行うための仕様群 42
表現を変えると • Web標準でSkype等の機能を実現する ための仕様群 • OS毎にネイティブアプリを作らずに • Flashやブラウザプラグインを使わずに 43
WebRTCの標準化状況 • WebRTC （@W3C） • • PeerConnectionとDataChannel、DTMFなども • • Working Draft http://www.w3.org/TR/webrtc/ ...
WebRTCの利用例 Dialogicのサイトより引用 https://www.dialogic.com/ja/landing/webrtc.aspx • 1対1のビデオチャット • 画面共有、ファイル共有 • コンタクトセンタ ...
WebRTCの利用例 Dialogicのサイトより引用 https://www.dialogic.com/ja/landing/webrtc.aspx • 1対1のビデオチャット • 画面共有、ファイル共有 • コンタクトセンタ ...
WebRTCを構成する仕様 • PeerConnection • DataChannel • MediaStream 46
PeerConnection • クライアント同士をP2Pで接続するた めの仕様 • 下位層はUDP 47
DataChannel • 任意のデータをPeerConnection経由 で送るための仕様 • テキストメッセージとか写真とか資料 とか、使い方は自由 48
MediaCapture • 正確にはWebRTCの一部ではない • Specificationも別 • ブラウザからマイクやカメラへアクセスする ための仕様 • MeiaCaptureで取得したStreamを PeerConnect...
PeerConnectionの流れ 50
一般的な流れ Webアプリケーションサーバ • Webアプリ • シグナリング機能 クライアントB クライアントA STUNサーバ 51
一般的な流れ Webアプリケーションサーバ • Webアプリ • シグナリング機能 クライアントB クライアントA STUNサーバ ①クライアントはSTUNサー バで自身のグローバルIP/Port を確認 51
一般的な流れ ②クライアントは自分の IP/Portやアプリ用情報を 添えて接続要求を送信 Webアプリケーションサーバ • Webアプリ • シグナリング機能 クライアントB クライアントA STUNサーバ ①クライアントはSTUNサー...
一般的な流れ ②クライアントは自分の IP/Portやアプリ用情報を 添えて接続要求を送信 Webアプリケーションサーバ • Webアプリ • シグナリング機能 クライアントB ③繋ぎたい相手のIP/Portを シグナリング機能で確認して ...
STUN • STUN＝Simple Traversal of UDP through NAT • またの名をUDPホールパンチング • NATの内側にあるノードからグローバ ルのIP/Port（トランスポートアドレ ス）を確認して「...
前述の流れで繋がらないケース Webアプリケーションサーバ クライアントB クライアントA STUNサーバ 53
前述の流れで繋がらないケース Webアプリケーションサーバ ルータのNAT機能やファイアウォールに ガードされて、外から中に入れない  →シンメトリックNATの可能性 クライアントB クライアントA STUNサーバ 53
「シンメトリックNAT」 以外のNAT • NATの内側のノードが外へアクセスする時、NAT は内側と外側のIP/Port同士をマッピングする • リクエストを投げると、外からレスポンスが帰ってこれ る • かつ任意のアドレスから「マッ...
一般的な流れ（改） Webアプリケーションサーバ STUNサーバで確認した IP/Port クライアントB クライアントA STUNサーバ 55
一般的な流れ（改） Webアプリケーションサーバ STUNサーバで確認した IP/Port STUNサーバから見えるIP/Portは第三 者も使える  →同じIP/PortでBもアクセスできる クライアントB クライアントA STUNサー...
シンメトリックNAT • 「内側から外へアクセスした時の相手 先からのアクセス」のみポートマッピ ングが有効 • • それ以外は遮断される STUNサーバでないクライアントBは、 STUNサーバ向けに開けられたIP/Port を使っても...
シンメトリックNATでの流れ Webアプリケーションサーバ STUNサーバで確認した IP/Port クライアントB クライアントA STUNサーバ 57
シンメトリックNATでの流れ Webアプリケーションサーバ STUNサーバで確認した IP/Port STUNサーバから見えるIP/PortはSTUN クライアントB サーバ専用  →Bからはアクセスできない クライアントA STUNサー...
シンメトリックNAT vs TURN Webアプリケーションサーバ TURNサーバ向けの IP/Port クライアントB クライアントA 58
シンメトリックNAT vs TURN Webアプリケーションサーバ TURNサーバ向けの IP/Port クライアントB TURNサーバ クライアントA TURNサーバ経由でAとBを接続 58
シンメトリックNAT vs TURN Webアプリケーションサーバ TURNサーバ向けの IP/Port クライアントB TURNサーバ クライアントA TURNサーバ経由でAとBを接続 TURNサーバからの接続なので通れる＝勝利 5...
TURN • Traversal Using Relay NAT • NATの内側にあるノードに対して透過 的な経路（トンネル）を提供する • すべての通信をパススルーするので、 ノードが増えるほどTURNサーバの帯 域が消費される ...
ICE • Interactive Connectivity Establishment • 常にSTUNを使うとシンメトリックNAT の時に到達できない • 常にTURNを使うとコストが高い • ICEは、STUNが使えない時だ...
PeerConnectionのまとめ ネットワーク周りの ハードルが高い 普通のWeb APIと勝手が違うポイント 61
ここでスライドを振り返る ②クライアントは自分の IP/Portやアプリ用情報を 添えて接続要求を送信 Webアプリケーションサーバ • Webアプリ • シグナリング機能 クライアントB ③繋ぎたい相手のIP/Portを シグナリング機能...
ここでスライドを振り返る ②クライアントは自分の IP/Portやアプリ用情報を 添えて接続要求を送信 Webアプリケーションサーバ • Webアプリ • シグナリング機能 クライアントB ③繋ぎたい相手のIP/Portを シグナリング機能...
WebRTCとWebSocket • WebRTCはシグナリングが必要だが、シグナリ ングの手段は任意（仕様外） • WebSocketはリアルタイムPUSHに向いている • WebRTCに対応しているブラウザはWebSocket に...
WebRTCとWebSocket • WebRTCはシグナリングが必要だが、シグナリ ングの手段は任意（仕様外） • WebSocketはリアルタイムPUSHに向いている • WebRTCに対応しているブラウザはWebSocket に...
WebRTCの利用事例 • PeerConnection周りを肩代わりするサービス • • • PeerJS SkyWay WebRTCを使ったコミュニケーションプラット フォーム • • OpenTok（TokBox） WebR...
PeerJS • http://peerjs.com/ • OSS（MIT License） • クライアント用ライブラリ（WebRTCのラッパ） の提供 • 対になるサーバの提供（クラウドサービス） ! • 通信周りの実装が...
SkyWay • http://nttcom.github.io/skyway/ • NTTコミュニケーションズが提供 • PeerJSベース • APIキー（Webアプリ）毎のアクティ ブ接続状況を確認する機能 66
字幕付きボイスチャット • SkyWayのデモアプリの一つ • Web Speech API（※）を組み合わせて、声をテキスト 化して画面に表示 ※ Chromeに実装されている、音声認識のAPI 67
字幕付きボイスチャット • SkyWayのデモアプリの一つ • Web Speech API（※）を組み合わせて、声をテキスト 化して画面に表示 ※ Chromeに実装されている、音声認識のAPI 音声チャットの内容がその場でテ キスト...
OpenTok • http://tokbox.com/opentok • TokBox社 • 多者間通話 • 録画 • WebRTC単体ではP2P＝1対1、多者間通話の実現 はWebアプリ開発者による作り込みが必要 • T...
PowerMedia XMS • https://www.dialogic.com/ja/products/ media-server-software/xms.aspx • Dialogic社 • メディアサーバ • WebRTC...
PowerMedia XMS XMS Highlights: • 既存オペレーターサービスのWebRTCへの置換 • ユーザーはスマホから電話発信及び受信 • オペレーションコストの削減 • Dialogic JS APIを利用...
ブラウザのWebRTC対応状況 ブラウザ名 PeerConnection DataChannel MediaStream Internet Explorer 同左 同左 Chrome ○/prefixed（※） 同左 同左 Fi...
WebRTCの問題 • 仕様が流動的 • ブラウザ間、あるいは同一ブラウザでもバージョンによっ て実装に差異がある • 当面はPeerJS等のライブラリに依存せざるを得ない • Webアプリ開発者が個別に対応するのは辛い • IE...
NTTアドバンステクノロジ株式会社 情報機器テクノロジセンタ 〒212-0014 神奈川県川崎市幸区大宮町1310 ミューザ川崎セントラルタワー TEL : 044-589-6094 FAX : 044-541-1381 http://www....
Upcoming SlideShare
Loading in …5
×
Technology
43,645 views
Feb. 26, 2014

WebSocket / WebRTCの技術紹介

WebSocket及びWebRTCの技術紹介資料です。
WebSocket : 概要、標準化状況、HTTPとの通信量比較、PUSH方式の比較、ブラウザの対応状況
WebRTC : 概要、標準化状況、通信（PeerConnection）確立までの流れ、利用事例、ブラウザの対応状況
（NTTアドバンステクノロジ（NTT-AT））

no profile picture user

  • Login to see the comments

Show More

WebSocket / WebRTCの技術紹介

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

×