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