Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ハイパフォーマンスブラウザネットワーキング 12章「HTTP 2.0」と現在の仕様

ハイパフォーマンスブラウザネットワーキング勉強会の発表資料です

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

ハイパフォーマンスブラウザネットワーキング 12章「HTTP 2.0」と現在の仕様

  1. 1. ハイパフォーマンスブラウザネッ トワーキング勉強会 12章 「HTTP 2.0」と現在の仕様 2014-08-28 @hagino3000
  2. 2. 最初に 本文中にあるHTTP 2.0という表記は既に無くなっ たので引用以外の箇所はHTTP/2でいきます。 ! 2014/08/28現在の仕様を反映した感じ(ラスト コールとなったdraft 14ベース)で説明をします。
  3. 3. HTTP/2の歴史とSPDY • SPDYの目標 • HTTP 1.1のパフォーマンスの制限に対処する事で、Webページのロー ディングで発生するレイテンシを削減する事 • PLT 50%削減 • Webサイト開発者によるコンテンツの変更を発生させない • ネットワークインフラの変更を避ける • オープンソースコミュニティと強力して新たなプロトコルを開発する • 実世界のパフォーマンスデータを収集し、この実験的プロトコルを検証 抜粋:: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https:// itunes.apple.com/WebObjects/MZStore.woa/wa/
  4. 4. SPDYの普及 • chrome://net-internals/#spdy 参照 • Twitter, Googleのサービスは対応しているのがわかる • ChromeのStable版だとSPDY3.1が使われる
  5. 5. HTTP/2 • TCPを使用するHTTP 1.1と比較して、ほとんどの場合にエンドユーザが認識するレイテンシ に劇的かつ測定可能な改善をもたらす。 • HTTPのHoLブロッキングに対処する。 • 並列性を確保するために複数の接続に頼らない。特に輻輳制御においてTCPの使用を改善す る。 • →HTTP 1.1のパフォーマンスの制限を取りはらう • HTTP 1.1の様式を保持する。HTTPメソッド、ステータスコード、URI、そして必要な場合 はヘッダフィールドなどを含む、既存のドキュメンテーションを活用する。 • →HTTP 1.1の文法は変えない • HTTP 2.0とHTTP 1.xの相互作用を明確に定義する。特に中間装置での扱いについて。 • →中間装置での扱い?? (^ω^;) • 新しい拡張ポイントがあればそれを明確に定義し、その適切な使用法のポリシーを確立する 抜粋:: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https:// itunes.apple.com/WebObjects/MZStore.woa/wa/
  6. 6. つまり • HTTP 1.1のパフォーマンスの制限を解決する • インタフェース(HTTPの文法)は変えない • Webサイトのコンテンツに変更は必要ない • HTTPSの様に、透過的に処理される
  7. 7. HTTP/2 draft 14 2014年8月1日、HTTP/2仕様はdraft14でラストコールに。Chrome Canary, Firefox Nightlyで試せる。 日本語訳 http://summerwind.jp/docs/draft-ietf-httpbis-http2-14/
  8. 8. ストリーム・メッセージ・フレーム ストリーム双方メッセージを長す仮想チャネル メッセージ個々のHTTPリクエスト、レスポンス フレーム HTTP/2の最小の通信単位 (HEADERS, DATA ,GOAWAY, PING, SETTING etc) 単一のTCP接続を使い、複数の論理的なHTTPのメッセージを 運ぶための仕組み。
  9. 9. 抜粋:: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https:// itunes.apple.com/WebObjects/MZStore.woa/wa/
  10. 10. 抜粋:: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https:// itunes.apple.com/WebObjects/MZStore.woa/wa/
  11. 11. Why • ブロックする事なく、複数の並列リクエストを インターリーブするため • ブロックする事なく、複数の並列レスポンスを インターリーブするため • HTTPのHoL Blockingの回避
  12. 12. 1オリジンに1接続 • 従来の複数接続を貼る方法に比べてサーバーの負荷が小さい • HTTP/2の接続は再利用される • GOAWAYフレームが届くまで切断しない、Keep Aliveよ りも強力なオーバヘッド削減効果 • だが、TCPの制限を受けるケースではその影響が顕著に • TCPレベルのHoLブロッキング • 1個のパケットロスが全てのストリームを遅延させる
  13. 13. HTTP/2 over X もありうる “HTTP 2.0は以前のHTTPプロトコルと同 様、必ずしもTCPを使用する必要がないこと を認識しておくことも重要です。UDPなど他 のトランスポートにも可能性があるのです。” • 次のボトルネックはTCP • SPDYはQUICでも動作する • chrome://net-internals/#quic
  14. 14. ヘッダ圧縮 • 仕様はHTTP/2とは別にHPACKとして策定 • http://tools.ietf.org/html/draft-ietf-httpbis- header-compression-09 • Draft 9でラストコール
  15. 15. 図12-5の差分符号化は 無かった事に HPACK draft 9で削除、よかったですね。
  16. 16. ヘッダ圧縮はどうなった • 次の3つは残った • Static Table • Header Table • Huffman Encoding
  17. 17. Static Table よく使うヘッダのKey, Valueの組のインデックス を持っておいて。マッチする場合はインデックス だけ送る Index Header Name Header Value 1 :authority GET 2 :method GET 3 :method POST 4 :path / … http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09#appendix-B
  18. 18. サーバープッシュ • サーバーは1つのリクエストに対して、複数のレ スポンスを返す事ができる • プッシュされたコンテンツは、クライアントに キャッシュされる。 • 例: index.htmlがリクエストされた時に index.htmlとfavicon.icoとstyle.css を返す
  19. 19. サーバープッシュ • リソースのインライン化と似ている • 画像のBase64化 • CSSスタイルをHTML内にインライン展開 • リソース結合(CSSスプライト)の様な手間が不要 になる (はず)
  20. 20. フロー制御 • WINDOW_UPDATEフレームで、ストリーム 毎、接続全体の受信可能なバイト数を通知でき る
  21. 21. フロー制御 “フロー制御はホップ単位で行なわれ、エンドツーエンドではな い。” “[†2] 訳注 ホップ単位のフロー制御は、必ずしも送信者を直 接制御することではありません。受信者のフロー制御の結果が 経路上の次の中間装置を制御し、その影響が伝播することで最 終的に送信者に影響を与えます。また、HTTPにおける「ホッ プ」はプロキシなどHTTPを理解する中間装置単位です。” どういう事?????
  22. 22. HTTP/2とTLS “HTTP 2.0はエンドツーエンドでサポートされている必要があり、 中間装置が1つでも対応していない場合は接続が成功しません。 HTTP 2.0自体はTLSの使用を必須としていませんが、上記の理由 のため、既存の中間装置が多数存在するような状況下においては TLSの利用が最も安全なデプロイメントの方法です。” • TLSを使えば、中間装置からは唯のTLS通信にしか見えないので安全。 • ChromeとFirefoxは平文HTTP/2は実装してない • TLSの終端はどこが良いの?
  23. 23. HTTP/2のアップグレードフロー • あと10年はHTTP 1.xのサポートもしないといけない。 • サーバーがHTTP/2に対応しているか不明な場合 • HTTP 1.xで開始して、クライアントがHTTP/2に対応してい る事をサーバーに伝える • ALPN • 事前にわかっている場合 • コネクションプリフェイス後にHTTP/2フレームを送って良い
  24. 24. バイナリフレーム フレーム長のフィールドは draft 14で24bitに
  25. 25. 参考 • HTTP/2 spec draft 14日本語訳 • http://summerwind.jp/docs/draft-ietf-httpbis-http2- 14/ • HPACK spec draft 9 • http://tools.ietf.org/html/draft-ietf-httpbis-header-compression- 09 • QUIC • https://docs.google.com/document/d/ 1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/ mobilebasic

×