WebSocket / WebRTCの技術紹介
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

WebSocket / WebRTCの技術紹介

on

  • 6,028 views

WebSocket及びWebRTCの技術紹介資料です。 ...

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

Statistics

Views

Total Views
6,028
Views on SlideShare
5,743
Embed Views
285

Actions

Likes
26
Downloads
64
Comments
0

5 Embeds 285

https://twitter.com 271
http://s.deeeki.com 8
https://kcw.kddi.ne.jp 3
https://www.chatwork.com 2
https://www.docsnode.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

WebSocket / WebRTCの技術紹介 Presentation Transcript

  • 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/