Downloaded 28 times
Uploaded byKensaku Komatsu
第43回HTML5とか勉強会 最新webプロトコル傾向と対策
第43回HTML5とか勉強会でのセッション資料 spdyやWebSocketに対するLong Fat PipeやHead of Line Blockingの影響や、WebRTC BaaS SkyWayの説明など
第43回HTML5とか勉強会 最新webプロトコル傾向と対策
- 1.
- 2. 自己紹介 名前：小松健作 HTML5の研究開発 HTML5の啓蒙・コミュニティ運営 html5jスタッフ カンファレンスのNW（ケーブル）頑張ってひきま した。 GoogleDeveloper 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.
- 6.
- 7. Concurrent HTTP 複数のTCPを同時に用いることで高速化 車の例で言えば、道路の車線を増やすことに相当
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. 更に、ネットワークをエミュ レート(MacOS) sudo ipfw addpipe 1 ip from any to any sudo ipfw pipe 1 config delay 50ms
- 18.
- 19.
- 20. TCP : LongFat Pipe Browser ACKが返ってくるま で、データを送信で Server きない
- 21.
- 22. SPDYとHTTPSの違い SPDY 複数リソースダウンロードをを一つのTCPで Long Fat Pipeの制限が顕著となる HTTPS Long Fat Pipeは、個々のTCPに対して起こる TCPの数だけ早くなる
- 23. 何が言えるか？ Latencyが多い環境 ACKの待ち時間が支配的 リソースサイズが増えるに従い、顕著となる SPDYより、HTTPSのほうが早いケースも
- 24. Head of LineBlocking Browser Server
- 25.
- 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 SCTPover DTLS QUIC
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49. コードの短縮化 220 line =>50 line サンプルレベル ならサーバーサ イドコーディン グは不要！！ https://gist.github.com/KensakuKOMATSU/5377673
- 50. SkyWay (PeerJS) のコーディ ングパターン WebSocketと若干コーディングパターンが変わる WebSocket サーバー SkyWay サーバー （裏側で接続制御） サーバーに接続すれば、お互 いが自動的につながる 相手先のPeer IDを指定して、 明示的に繋がる（呼ばれる側 はサーバー的なコーディング が必要）
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.