ハイパフォーマンスブラウザネットワーキング勉強会

12章 「HTTP 2.0」と現在の仕様

2014-08-28 @hagino3000

本文中にあるHTTP 2.0という表記は既に無くなったので引用以外の箇所はHTTP/2でいきます。 !

2014/08/28現在の仕様を反映した感じ(ラストコールとなったdraft 14ベース)で説明をします。

最初に

HTTP/2の歴史とSPDY• SPDYの目標

• HTTP 1.1のパフォーマンスの制限に対処する事で、Webページのローディングで発生するレイテンシを削減する事

• PLT 50%削減

• Webサイト開発者によるコンテンツの変更を発生させない

• ネットワークインフラの変更を避ける

• オープンソースコミュニティと強力して新たなプロトコルを開発する

• 実世界のパフォーマンスデータを収集し、この実験的プロトコルを検証

抜粋：: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/

SPDYの普及

• chrome://net-internals/#spdy 参照

• Twitter, Googleのサービスは対応しているのがわかる

• ChromeのStable版だとSPDY3.1が使われる

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/

つまり

• HTTP 1.1のパフォーマンスの制限を解決する

• インタフェース(HTTPの文法)は変えない

• Webサイトのコンテンツに変更は必要ない

• HTTPSの様に、透過的に処理される

HTTP/2 draft 14

2014年8月1日、HTTP/2仕様はdraft14でラストコールに。Chrome Canary, Firefox Nightlyで試せる。 日本語訳 http://summerwind.jp/docs/draft-ietf-httpbis-http2-14/

ストリーム・メッセージ・フレーム

単一のTCP接続を使い、複数の論理的なHTTPのメッセージを運ぶための仕組み。

ストリーム 双方メッセージを長す仮想チャネル

メッセージ 個々のHTTPリクエスト、レスポンス

フレームHTTP/2の最小の通信単位 (HEADERS, DATA ,GOAWAY, PING, SETTING

etc)

抜粋：: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/

抜粋：: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https://itunes.apple.com/WebObjects/MZStore.woa/wa/

Why

• ブロックする事なく、複数の並列リクエストをインターリーブするため

• ブロックする事なく、複数の並列レスポンスをインターリーブするため

• HTTPのHoL Blockingの回避

1オリジンに1接続• 従来の複数接続を貼る方法に比べてサーバーの負荷が小さい

• HTTP/2の接続は再利用される

• GOAWAYフレームが届くまで切断しない、Keep Aliveよりも強力なオーバヘッド削減効果

• だが、TCPの制限を受けるケースではその影響が顕著に

• TCPレベルのHoLブロッキング

• 1個のパケットロスが全てのストリームを遅延させる

HTTP/2 over X もありうる“HTTP 2.0は以前のHTTPプロトコルと同様、必ずしもTCPを使用する必要がないことを認識しておくことも重要です。UDPなど他のトランスポートにも可能性があるのです。”

• 次のボトルネックはTCP • SPDYはQUICでも動作する

• chrome://net-internals/#quic

ヘッダ圧縮

• 仕様はHTTP/2とは別にHPACKとして策定

• http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09

• Draft 9でラストコール

図12-5の差分符号化は 無かった事に

HPACK draft 9で削除、よかったですね。

ヘッダ圧縮はどうなった

• 次の3つは残った

• Static Table

• Header Table

• Huffman Encoding

Static Tableよく使うヘッダのKey, Valueの組のインデックスを持っておいて。マッチする場合はインデックスだけ送る

Index Header Name Header Value1 :authority GET2 :method GET3 :method POST4 :path /…

http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09#appendix-B

サーバープッシュ• サーバーは1つのリクエストに対して、複数のレスポンスを返す事ができる

• プッシュされたコンテンツは、クライアントにキャッシュされる。

• 例: index.htmlがリクエストされた時にindex.htmlとfavicon.icoとstyle.css を返す

サーバープッシュ• リソースのインライン化と似ている

• 画像のBase64化

• CSSスタイルをHTML内にインライン展開

• リソース結合(CSSスプライト)の様な手間が不要になる (はず)

フロー制御

• WINDOW_UPDATEフレームで、ストリーム毎、接続全体の受信可能なバイト数を通知できる

フロー制御“フロー制御はホップ単位で行なわれ、エンドツーエンドではない。”

“[†2] 訳注　ホップ単位のフロー制御は、必ずしも送信者を直接制御することではありません。受信者のフロー制御の結果が経路上の次の中間装置を制御し、その影響が伝播することで最終的に送信者に影響を与えます。また、HTTPにおける「ホップ」はプロキシなどHTTPを理解する中間装置単位です。”

どういう事?????

HTTP/2とTLS“HTTP 2.0はエンドツーエンドでサポートされている必要があり、中間装置が1つでも対応していない場合は接続が成功しません。

HTTP 2.0自体はTLSの使用を必須としていませんが、上記の理由のため、既存の中間装置が多数存在するような状況下においてはTLSの利用が最も安全なデプロイメントの方法です。”

• TLSを使えば、中間装置からは唯のTLS通信にしか見えないので安全。

• ChromeとFirefoxは平文HTTP/2は実装してない

• TLSの終端はどこが良いの?

HTTP/2のアップグレードフロー

• あと10年はHTTP 1.xのサポートもしないといけない。

• サーバーがHTTP/2に対応しているか不明な場合

• HTTP 1.xで開始して、クライアントがHTTP/2に対応している事をサーバーに伝える

• ALPN

• 事前にわかっている場合

• コネクションプリフェイス後にHTTP/2フレームを送って良い

バイナリフレーム

フレーム長のフィールドは draft 14で24bitに

参考• 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