第43回HTML5とか勉強会でのセッション資料 spdyやWebSocketに対するLong Fat PipeやHead of Line Blockingの影響や、WebRTC BaaS SkyWayの説明など

1. 最新Webプロトコル 傾向と対策
第43回 HTML5とか勉強会
こまつけんさく

2. 自己紹介
 名前：小松健作




HTML5の研究開発
HTML5の啓蒙・コミュニティ運営
html5jスタッフ
カンファレンスのNW（ケーブル）頑張ってひきま
した。
 Google Developer Expert (HTML5)
 Microsoft Most Valuable Professional(IE)

3. 最新Webプロトコルが続々と
 WebSocket
 SPDY, HTTP2.0
 WebRTC
 Raw Socket API
 SCTP over DTLS (for WebRTC reliable data channel )
 QUIC

4. なぜ
こんなに？

5. HTTP/1.1
Browser
GET /index.html
Server
index.ht
ml
GET /style.css
style.css
画像素材：http://www.emstudio.jp/free/data1030/

6. HTTP/1.1
Browser
GET /index.html
Server
index.ht
ml
GET /style.css
style.css
Round Trip Tiime

7. Concurrent HTTP
 複数のTCPを同時に用いることで高速化
 車の例で言えば、道路の車線を増やすことに相当

9. Concurrent HTTP
Browser
Server
超えられないGAP
リソースも多く使う

10. Gap を超えるために
 複数リソースを一つのセッションにまとめる。
Browser
Server
まとめたリクエスト
を送る

11. Gapを超えるpractice
 CSS sprite

12. もっと
Genericに!

13. SPDYの考え方
 複数リソースを一つのTCPにまとめている
Browser
Server

14. DEMO

15. SPDY使えば何も考え
なくてもいい？

16. リソースサイズを変えてみる

17. 更に、ネットワークをエミュ
レート(MacOS)
sudo ipfw add pipe 1 ip from any to any
sudo ipfw pipe 1 config delay 50ms

18. エミュレート環境で
測ってみる

19. リソースサイズ、latency
SPDY
HTTPS

20. TCP : Long Fat Pipe
Browser
ACKが返ってくるま
で、データを送信で
Server
きない

21. 計測データ
総データ送信量
ACK time
(100ms)
データ送信量
about
15KB

22. SPDYとHTTPSの違い
 SPDY
 複数リソースダウンロードをを一つのTCPで
 Long Fat Pipeの制限が顕著となる
 HTTPS
 Long Fat Pipeは、個々のTCPに対して起こる
 TCPの数だけ早くなる

23. 何が言えるか？
 Latencyが多い環境
 ACKの待ち時間が支配的
 リソースサイズが増えるに従い、顕著となる
 SPDYより、HTTPSのほうが早いケースも

24. Head of Line Blocking
Browser
Server

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

26. 計測データ

27. ケアしたほうがいいこと
 SPDYを使う際は
 大容量のファイルが多量に存在する場合
 モバイル環境（ロスもlatencyも大きい）でのテスト
に注意したほうがいい
ファイルサイズの最小化など、従来からのプラクティス・サイト設計は
引き続き重要
※ WebSocketについても同様のことが言えます。（場合によっては、
WebSocket 複数コネクション使ったほうがいいかも！？）

28. 何が原因？
 SPDY, WebSocket … NO
 TCPの制限が原因
 Webの進化によりTCPの制限にぶつか
るようになった
HTTP / HTTPS
SPDY, WebSocket
HTTP2.0
TCP
TCP
IP
IP
Layer
Dependency

29. TCP alternative
 SCTP over DTLS
 QUIC

30. TCP alternativeはいつ？
Access
NW
Browser
Load
Balancer
FireWall
Server
CGN
インターネット上のあらゆる機器に影響が出てくる・・・

31. WebRTC的な話

32. WebRTCの特徴
WebRTC
WebSocket
Server
Server
Browser
Browser
Browser
Browser

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

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

35. アドレス、ポート番号を知る
ために : STUN
STUN
NAT
Browser
実際のアドレス、
ポート番号をブラ
ウザに返す
NAT
Browser

36. フルコーンNAT
STUN
ポート番号だけを見て変換
（UDP Hole Punching)
NAT
Browser
NAT
STUNに教えても
らった情報を使い
通信
Browser

37. シンメトリックNAT
STUN
アドレスが違うの
でブロック
NAT
Browser
NAT
STUNに教えても
らった情報を使い
通信
Browser

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

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

40. 同一セグメントでも・・・
Wireless
Controller
公衆無線LAN
セキュリティの観
点からセグメント
内
P2Pを禁止
TURNが必要
Browser
Browser

41. WebRTCもうちょっと詳しく
サーバーサイド
コーディング
セッション情
報の交換
Broker
Server
Stun
server
NATのhole
punching
NAT
WebRTC
Web
app
NAT
WebRTC
Web
app
データの交換
http://blog.livedoor.jp/kotesaki/archives/1794148.html

42. WebRTCもうちょっと詳しく
セッション情
報の交換
Broker
Server
Stun
server
とにかくめんどくさい
NATのhole
punching
NAT
WebRTC
Web
app
NAT
WebRTC
Web
app
データの交換

43. ふつーに書くと
（browser side）
https://github.com/KensakuKOMATSU/rtc_datachannel/blob/master/
public/javascripts/script.js

44. ふつーに書くと
（server side）
https://github.com/KensakuKOMATSU/rtc_datachannel/blob/mast
er/app.js

45. 毎回こんなコード書い
てられない・・・

46. wrapper
 Peer.js
http://peerjs.com/

47. SkyWay (preview release!)
Peerjs互換
http://nttcom.github.io/skyway/

48. WebRTCを簡単に使えるBaaS
サーバーサイド Broker
コーディング Server
セッション情
報の交換
Stun
server
NAT
WebRTC
Web
app
NATのhole
punching
NAT
WebRTC
Web
app
この部分は、
SkyWayが提供
（気にしなくて
いい）
ブラウザ部分の
開発に集中
データの交換

49. コードの短縮化
220 line => 50 line
サンプルレベル
ならサーバーサ
イドコーディン
グは不要！！
https://gist.github.com/KensakuKOMATSU/5377673

50. SkyWay (PeerJS) のコーディ
ングパターン
 WebSocketと若干コーディングパターンが変わる
WebSocket
サーバー
SkyWay
サーバー
（裏側で接続制御）
サーバーに接続すれば、お互
いが自動的につながる
相手先のPeer IDを指定して、
明示的に繋がる（呼ばれる側
はサーバー的なコーディング
が必要）

51. SkyWay (PeerJS)のコーディ
ングパターン
SkyWay
サーバー
最初にSkyWay
サーバーに接続
SkyWay
サーバー
接続先IDを
指定して
p2p接続
caller
（裏側でうまいこと
橋渡し）
callee

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

53. より詳しくは・・・
http://nttcom.github.io/skyway/docs/

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

55. Pull request, Issueお待ちしてい
ます!!
https://github.com/nttcom/peerjs

56. Thank You!!
@komasshu