最新Webプロトコル傾向と対策

29,109 views
29,175 views

Published on

0 Comments
51 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
29,109
On SlideShare
0
From Embeds
0
Number of Embeds
23,268
Actions
Shares
0
Downloads
122
Comments
0
Likes
51
Embeds 0
No embeds

No notes for slide

最新Webプロトコル傾向と対策

  1. 1. 最新Webプロトコル 傾向と対策 HTML5 conference 2013 NTT communications こまつけんさく
  2. 2. 自己紹介  名前:小松健作  所属:NTT communications  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 UDP (for WebRTC reliable data channel )  QUIC
  4. 4. なぜ こんなに?
  5. 5. HTTP/1.1 Browser Server request response
  6. 6. HTTP/1.1 Browser Server Round Trip Tiime
  7. 7. Concurrent HTTP Browser Server
  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 … NO  TCPの制限が原因  Webの進化によりTCPの制限にぶつか るようになった HTTP / HTTPS SPDY, WebSocket HTTP2.0 TCP TCP IP IP Layer Dependency
  27. 27. TCP alternative  SCTP over UDP  QUIC
  28. 28. TCP alternativeはいつ? Access NW Browser Load Balancer FireWall Server CGN インターネット上のあらゆる機器に影響が出てくる・・・ ルーム5C:17:15〜のキャリアパネルでこの辺の話が聞けるかも
  29. 29. 速度って何?  SPDYの特徴は、スピードだけではない  絶対的なスピード競争に目を奪われてはいけない  ユーザーの体感スピードをあげることが重要  User Experience
  30. 30. 体感速度を早くする  1st view のレンダリングを高速化する  1st viewに関係ない画像やスクリプトなどは、後でダ ウンロードすればいい。
  31. 31. Resource Priorities
  32. 32. 例 Attribute = lazyload <img class='Backgrounds' id='BackgroundLevel1' src='Background1.png' /> <img class='Backgrounds' id='BackgroundLevel2' src='Background2.png' lazyload />
  33. 33. WebRTC的な話
  34. 34. WebRTCの特徴 WebRTC WebSocket Server Server Browser Browser Browser Browser
  35. 35. P2Pを実現するには? 相手のIPアドレ ス、ポート番 号が必要 Browser Browser
  36. 36. NATがある場合 実際のアドレス、 ポート番号は分か らない NAT Browser NAT Browser
  37. 37. アドレス、ポート番号を知る ために : STUN STUN NAT Browser 実際のアドレス、 ポート番号をブラ ウザに返す NAT Browser
  38. 38. フルコーンNAT STUN ポート番号だけを見て変換 (UDP Hole Punching) NAT Browser NAT STUNに教えても らった情報を使い 通信 Browser
  39. 39. シンメトリックNAT STUN アドレスが違うの でブロック NAT Browser NAT STUNに教えても らった情報を使い 通信 Browser
  40. 40. TURN TURN NAT Browser サーバーを中継す るため、シンメト リックNATでもOK NAT Browser
  41. 41. 同一セグメント内ならICEは STUN, TURNは不要 Broadband Router LAN Browser Browser
  42. 42. 同一セグメントでも・・・ Wireless Controller 公衆無線LAN セキュリティの観 点からセグメント 内 P2Pを禁止 TURNが必要 Browser Browser
  43. 43. IPv6になったらSTUNは不要? STUN FWに穴を開けるために 必要 FW Browser FW Browser
  44. 44. 宣伝 SkyWay WebRTC BaaS 日本で、もっとWebRTCを! 近日 preview release 予定
  45. 45. Thank You!! @komasshu

×