最新Webプロトコル 傾向と対策
第43回 HTML5とか勉強会
こまつけんさく
自己紹介
 名前:小松健作





HTML5の研究開発
HTML5の啓蒙・コミュニティ運営
html5jスタッフ
カンファレンスのNW(ケーブル)頑張ってひきま
した。

 Google Developer Expert (HT...
最新Webプロトコルが続々と
 WebSocket
 SPDY, HTTP2.0
 WebRTC
 Raw Socket API
 SCTP over DTLS (for WebRTC reliable data channel )
...
なぜ
こんなに?
HTTP/1.1
Browser

GET /index.html

Server
index.ht
ml

GET /style.css
style.css

画像素材:http://www.emstudio.jp/free/data1030...
HTTP/1.1
Browser

GET /index.html

Server
index.ht
ml

GET /style.css
style.css
Round Trip Tiime
Concurrent HTTP
 複数のTCPを同時に用いることで高速化
 車の例で言えば、道路の車線を増やすことに相当
Concurrent HTTP
Browser

Server

超えられないGAP
リソースも多く使う
Gap を超えるために
 複数リソースを一つのセッションにまとめる。
Browser

Server

まとめたリクエスト
を送る
Gapを超えるpractice
 CSS sprite
もっと
Genericに!
SPDYの考え方
 複数リソースを一つのTCPにまとめている
Browser

Server
DEMO
SPDY使えば何も考え
なくてもいい?
リソースサイズを変えてみる
更に、ネットワークをエミュ
レート(MacOS)

sudo ipfw add pipe 1 ip from any to any
sudo ipfw pipe 1 config delay 50ms
エミュレート環境で
測ってみる
リソースサイズ、latency

SPDY

HTTPS
TCP : Long Fat Pipe
Browser

ACKが返ってくるま
で、データを送信で
Server
きない
計測データ
総データ送信量

ACK time
(100ms)

データ送信量
about
15KB
SPDYとHTTPSの違い
 SPDY
 複数リソースダウンロードをを一つのTCPで
 Long Fat Pipeの制限が顕著となる

 HTTPS
 Long Fat Pipeは、個々のTCPに対して起こる
 TCPの数だけ早くな...
何が言えるか?
 Latencyが多い環境
 ACKの待ち時間が支配的
 リソースサイズが増えるに従い、顕著となる
 SPDYより、HTTPSのほうが早いケースも
Head of Line Blocking
Browser

Server
HTTPSでは、HoLの影響を受け
づらい
Browser

Server
計測データ
ケアしたほうがいいこと
 SPDYを使う際は
 大容量のファイルが多量に存在する場合
 モバイル環境(ロスもlatencyも大きい)でのテスト
に注意したほうがいい

ファイルサイズの最小化など、従来からのプラクティス・サイト設計は
引き...
何が原因?
 SPDY, WebSocket … NO
 TCPの制限が原因
 Webの進化によりTCPの制限にぶつか
るようになった

HTTP / HTTPS

SPDY, WebSocket
HTTP2.0

TCP

TCP

I...
TCP alternative
 SCTP over DTLS
 QUIC
TCP alternativeはいつ?
Access
NW

Browser

Load
Balancer
FireWall

Server

CGN

インターネット上のあらゆる機器に影響が出てくる・・・
WebRTC的な話
WebRTCの特徴
WebRTC

WebSocket

Server

Server

Browser

Browser

Browser

Browser
P2Pを実現するには?
相手のIPアドレ
ス、ポート番
号が必要

Browser

Browser
NATがある場合
実際のアドレス、
ポート番号は分か
らない

NAT

Browser

NAT

Browser
アドレス、ポート番号を知る
ために : STUN
STUN

NAT

Browser

実際のアドレス、
ポート番号をブラ
ウザに返す

NAT

Browser
フルコーンNAT
STUN
ポート番号だけを見て変換
(UDP Hole Punching)

NAT

Browser

NAT

STUNに教えても
らった情報を使い
通信

Browser
シンメトリックNAT
STUN
アドレスが違うの
でブロック

NAT

Browser

NAT

STUNに教えても
らった情報を使い
通信

Browser
TURN
TURN

NAT

Browser

サーバーを中継す
るため、シンメト
リックNATでもOK

NAT

Browser
同一セグメント内ならICEは
STUN, TURNは不要
Broadband
Router

LAN

Browser

Browser
同一セグメントでも・・・
Wireless
Controller

公衆無線LAN

セキュリティの観
点からセグメント
内
P2Pを禁止
TURNが必要

Browser

Browser
WebRTCもうちょっと詳しく
サーバーサイド
コーディング

セッション情
報の交換

Broker
Server

Stun
server
NATのhole
punching
NAT

WebRTC
Web
app

NAT

WebRTC...
WebRTCもうちょっと詳しく
セッション情
報の交換

Broker
Server
Stun
server

とにかくめんどくさい

NATのhole
punching

NAT

WebRTC
Web
app

NAT

WebRTC
We...
ふつーに書くと
(browser side)

https://github.com/KensakuKOMATSU/rtc_datachannel/blob/master/
public/javascripts/script.js
ふつーに書くと
(server side)

https://github.com/KensakuKOMATSU/rtc_datachannel/blob/mast
er/app.js
毎回こんなコード書い
てられない・・・
wrapper
 Peer.js

http://peerjs.com/
SkyWay (preview release!)

Peerjs互換

http://nttcom.github.io/skyway/
WebRTCを簡単に使えるBaaS
サーバーサイド Broker
コーディング Server

セッション情
報の交換

Stun
server

NAT

WebRTC
Web
app

NATのhole
punching

NAT

Web...
コードの短縮化

220 line => 50 line

サンプルレベル
ならサーバーサ
イドコーディン
グは不要!!

https://gist.github.com/KensakuKOMATSU/5377673
SkyWay (PeerJS) のコーディ
ングパターン
 WebSocketと若干コーディングパターンが変わる
WebSocket
サーバー

SkyWay
サーバー
(裏側で接続制御)

サーバーに接続すれば、お互
いが自動的につながる
...
SkyWay (PeerJS)のコーディ
ングパターン
SkyWay
サーバー
最初にSkyWay
サーバーに接続

SkyWay
サーバー
接続先IDを
指定して
p2p接続

caller

(裏側でうまいこと
橋渡し)

callee
DataChannelの相互接続性問
題
DataChannelのreliable通信の実装がブラ
ウザ(バージョン)ごとに異なる
 当面はsctpをオフにしたほうがベター
 util.supports.sctp = false;
より詳しくは・・・

http://nttcom.github.io/skyway/docs/
Preview releaseにつき無料!!

http://nttcom.github.io/skyway/registration.html
Pull request, Issueお待ちしてい
ます!!

https://github.com/nttcom/peerjs
Thank You!!
@komasshu
第43回HTML5とか勉強会 最新webプロトコル傾向と対策
Upcoming SlideShare
Loading in...5
×

第43回HTML5とか勉強会 最新webプロトコル傾向と対策

2,596

Published on

第43回HTML5とか勉強会でのセッション資料

spdyやWebSocketに対するLong Fat PipeやHead of Line Blockingの影響や、WebRTC BaaS SkyWayの説明など

Published in: Technology
0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,596
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
25
Comments
0
Likes
14
Embeds 0
No embeds

No notes for slide

第43回HTML5とか勉強会 最新webプロトコル傾向と対策

  1. 1. 最新Webプロトコル 傾向と対策 第43回 HTML5とか勉強会 こまつけんさく
  2. 2. 自己紹介  名前:小松健作     HTML5の研究開発 HTML5の啓蒙・コミュニティ運営 html5jスタッフ カンファレンスのNW(ケーブル)頑張ってひきま した。  Google Developer Expert (HTML5)  Microsoft Most Valuable Professional(IE)
  3. 3. 最新Webプロトコルが続々と  WebSocket  SPDY, HTTP2.0  WebRTC  Raw Socket API  SCTP over DTLS (for WebRTC reliable data channel )  QUIC
  4. 4. なぜ こんなに?
  5. 5. HTTP/1.1 Browser GET /index.html Server index.ht ml GET /style.css style.css 画像素材:http://www.emstudio.jp/free/data1030/
  6. 6. HTTP/1.1 Browser GET /index.html Server index.ht ml GET /style.css style.css Round Trip Tiime
  7. 7. Concurrent HTTP  複数のTCPを同時に用いることで高速化  車の例で言えば、道路の車線を増やすことに相当
  8. 8. Concurrent HTTP Browser Server 超えられないGAP リソースも多く使う
  9. 9. Gap を超えるために  複数リソースを一つのセッションにまとめる。 Browser Server まとめたリクエスト を送る
  10. 10. Gapを超えるpractice  CSS sprite
  11. 11. もっと Genericに!
  12. 12. SPDYの考え方  複数リソースを一つのTCPにまとめている Browser Server
  13. 13. DEMO
  14. 14. SPDY使えば何も考え なくてもいい?
  15. 15. リソースサイズを変えてみる
  16. 16. 更に、ネットワークをエミュ レート(MacOS) sudo ipfw add pipe 1 ip from any to any sudo ipfw pipe 1 config delay 50ms
  17. 17. エミュレート環境で 測ってみる
  18. 18. リソースサイズ、latency SPDY HTTPS
  19. 19. TCP : Long Fat Pipe Browser ACKが返ってくるま で、データを送信で Server きない
  20. 20. 計測データ 総データ送信量 ACK time (100ms) データ送信量 about 15KB
  21. 21. SPDYとHTTPSの違い  SPDY  複数リソースダウンロードをを一つのTCPで  Long Fat Pipeの制限が顕著となる  HTTPS  Long Fat Pipeは、個々のTCPに対して起こる  TCPの数だけ早くなる
  22. 22. 何が言えるか?  Latencyが多い環境  ACKの待ち時間が支配的  リソースサイズが増えるに従い、顕著となる  SPDYより、HTTPSのほうが早いケースも
  23. 23. Head of Line Blocking Browser Server
  24. 24. HTTPSでは、HoLの影響を受け づらい Browser Server
  25. 25. 計測データ
  26. 26. ケアしたほうがいいこと  SPDYを使う際は  大容量のファイルが多量に存在する場合  モバイル環境(ロスもlatencyも大きい)でのテスト に注意したほうがいい ファイルサイズの最小化など、従来からのプラクティス・サイト設計は 引き続き重要 ※ WebSocketについても同様のことが言えます。(場合によっては、 WebSocket 複数コネクション使ったほうがいいかも!?)
  27. 27. 何が原因?  SPDY, WebSocket … NO  TCPの制限が原因  Webの進化によりTCPの制限にぶつか るようになった HTTP / HTTPS SPDY, WebSocket HTTP2.0 TCP TCP IP IP Layer Dependency
  28. 28. TCP alternative  SCTP over DTLS  QUIC
  29. 29. TCP alternativeはいつ? Access NW Browser Load Balancer FireWall Server CGN インターネット上のあらゆる機器に影響が出てくる・・・
  30. 30. WebRTC的な話
  31. 31. WebRTCの特徴 WebRTC WebSocket Server Server Browser Browser Browser Browser
  32. 32. P2Pを実現するには? 相手のIPアドレ ス、ポート番 号が必要 Browser Browser
  33. 33. NATがある場合 実際のアドレス、 ポート番号は分か らない NAT Browser NAT Browser
  34. 34. アドレス、ポート番号を知る ために : STUN STUN NAT Browser 実際のアドレス、 ポート番号をブラ ウザに返す NAT Browser
  35. 35. フルコーンNAT STUN ポート番号だけを見て変換 (UDP Hole Punching) NAT Browser NAT STUNに教えても らった情報を使い 通信 Browser
  36. 36. シンメトリックNAT STUN アドレスが違うの でブロック NAT Browser NAT STUNに教えても らった情報を使い 通信 Browser
  37. 37. TURN TURN NAT Browser サーバーを中継す るため、シンメト リックNATでもOK NAT Browser
  38. 38. 同一セグメント内ならICEは STUN, TURNは不要 Broadband Router LAN Browser Browser
  39. 39. 同一セグメントでも・・・ Wireless Controller 公衆無線LAN セキュリティの観 点からセグメント 内 P2Pを禁止 TURNが必要 Browser Browser
  40. 40. WebRTCもうちょっと詳しく サーバーサイド コーディング セッション情 報の交換 Broker Server Stun server NATのhole punching NAT WebRTC Web app NAT WebRTC Web app データの交換 http://blog.livedoor.jp/kotesaki/archives/1794148.html
  41. 41. WebRTCもうちょっと詳しく セッション情 報の交換 Broker Server Stun server とにかくめんどくさい NATのhole punching NAT WebRTC Web app NAT WebRTC Web app データの交換
  42. 42. ふつーに書くと (browser side) https://github.com/KensakuKOMATSU/rtc_datachannel/blob/master/ public/javascripts/script.js
  43. 43. ふつーに書くと (server side) https://github.com/KensakuKOMATSU/rtc_datachannel/blob/mast er/app.js
  44. 44. 毎回こんなコード書い てられない・・・
  45. 45. wrapper  Peer.js http://peerjs.com/
  46. 46. SkyWay (preview release!) Peerjs互換 http://nttcom.github.io/skyway/
  47. 47. WebRTCを簡単に使えるBaaS サーバーサイド Broker コーディング Server セッション情 報の交換 Stun server NAT WebRTC Web app NATのhole punching NAT WebRTC Web app この部分は、 SkyWayが提供 (気にしなくて いい) ブラウザ部分の 開発に集中 データの交換
  48. 48. コードの短縮化 220 line => 50 line サンプルレベル ならサーバーサ イドコーディン グは不要!! https://gist.github.com/KensakuKOMATSU/5377673
  49. 49. SkyWay (PeerJS) のコーディ ングパターン  WebSocketと若干コーディングパターンが変わる WebSocket サーバー SkyWay サーバー (裏側で接続制御) サーバーに接続すれば、お互 いが自動的につながる 相手先のPeer IDを指定して、 明示的に繋がる(呼ばれる側 はサーバー的なコーディング が必要)
  50. 50. SkyWay (PeerJS)のコーディ ングパターン SkyWay サーバー 最初にSkyWay サーバーに接続 SkyWay サーバー 接続先IDを 指定して p2p接続 caller (裏側でうまいこと 橋渡し) callee
  51. 51. DataChannelの相互接続性問 題 DataChannelのreliable通信の実装がブラ ウザ(バージョン)ごとに異なる  当面はsctpをオフにしたほうがベター  util.supports.sctp = false;
  52. 52. より詳しくは・・・ http://nttcom.github.io/skyway/docs/
  53. 53. Preview releaseにつき無料!! http://nttcom.github.io/skyway/registration.html
  54. 54. Pull request, Issueお待ちしてい ます!! https://github.com/nttcom/peerjs
  55. 55. Thank You!! @komasshu
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×