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

1. ハイパフォーマンスブラウザネッ
トワーキング読書会
12章 「HTTP 2.0」と現在の仕様
2014-08-28
@hagino3000

2. 最初に
本文中にあるHTTP 2.0という表記は既に無くなっ
たので引用以外の箇所はHTTP/2でいきます。
!
2014/08/28現在の仕様を反映した感じ(ラスト
コールとなったdraft 14ベース)で説明をします。

3. HTTP/2の歴史とSPDY
• SPDYの目標
• HTTP 1.1のパフォーマンスの制限に対処する事で、Webページのロー
ディングで発生するレイテンシを削減する事
• PLT 50%削減
• Webサイト開発者によるコンテンツの変更を発生させない
• ネットワークインフラの変更を避ける
• オープンソースコミュニティと強力して新たなプロトコルを開発する
• 実世界のパフォーマンスデータを収集し、この実験的プロトコルを検証
抜粋：: Ilya Grigorik. “ハイパフォーマンス ブラウザネットワーキング”。 iBooks. https://
itunes.apple.com/WebObjects/MZStore.woa/wa/

4. SPDYの普及
• chrome://net-internals/#spdy 参照
• Twitter, Googleのサービスは対応しているのがわかる
• ChromeのStable版だとSPDY3.1が使われる

6. 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/

7. つまり
• HTTP 1.1のパフォーマンスの制限を解決する
• インタフェース(HTTPの文法)は変えない
• Webサイトのコンテンツに変更は必要ない
• HTTPSの様に、透過的に処理される

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

9. ストリーム・メッセージ・フレーム
ストリーム双方メッセージを長す仮想チャネル
メッセージ個々のHTTPリクエスト、レスポンス
フレーム
HTTP/2の最小の通信単位 (HEADERS,
DATA ,GOAWAY, PING, SETTING
etc)
単一のTCP接続を使い、複数の論理的なHTTPのメッセージを
運ぶための仕組み。

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

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

12. Why
• ブロックする事なく、複数の並列リクエストを
インターリーブするため
• ブロックする事なく、複数の並列レスポンスを
インターリーブするため
• HTTPのHoL Blockingの回避

13. 1オリジンに1接続
• 従来の複数接続を貼る方法に比べてサーバーの負荷が小さい
• HTTP/2の接続は再利用される
• GOAWAYフレームが届くまで切断しない、Keep Aliveよ
りも強力なオーバヘッド削減効果
• だが、TCPの制限を受けるケースではその影響が顕著に
• TCPレベルのHoLブロッキング
• 1個のパケットロスが全てのストリームを遅延させる

14. HTTP/2 over X もありうる
“HTTP 2.0は以前のHTTPプロトコルと同
様、必ずしもTCPを使用する必要がないこと
を認識しておくことも重要です。UDPなど他
のトランスポートにも可能性があるのです。”
• 次のボトルネックはTCP
• SPDYはQUICでも動作する
• chrome://net-internals/#quic

15. ヘッダ圧縮
• 仕様はHTTP/2とは別にHPACKとして策定
• http://tools.ietf.org/html/draft-ietf-httpbis-
header-compression-09
• Draft 9でラストコール

16. 図12-5の差分符号化は
無かった事に
HPACK draft 9で削除、よかったですね。

17. ヘッダ圧縮はどうなった
• 次の3つは残った
• Static Table
• Header Table
• Huffman Encoding

18. 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

19. サーバープッシュ
• サーバーは1つのリクエストに対して、複数のレ
スポンスを返す事ができる
• プッシュされたコンテンツは、クライアントに
キャッシュされる。
• 例: index.htmlがリクエストされた時に
index.htmlとfavicon.icoとstyle.css を返す

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

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

22. HTTP/2とTLS
“HTTP 2.0はエンドツーエンドでサポートされている必要があり、
中間装置が1つでも対応していない場合は接続が成功しません。
HTTP 2.0自体はTLSの使用を必須としていませんが、上記の理由
のため、既存の中間装置が多数存在するような状況下においては
TLSの利用が最も安全なデプロイメントの方法です。”
• TLSを使えば、中間装置からは唯のTLS通信にしか見えないので安全。
• ChromeとFirefoxは平文HTTP/2は実装してない

23. HTTP/2のアップグレードフロー
• あと10年はHTTP 1.xのサポートもしないといけない。
• サーバーがHTTP/2に対応しているか不明な場合
• HTTP 1.xで開始して、クライアントがHTTP/2に対応してい
る事をサーバーに伝える
• ALPN
• 事前にわかっている場合
• コネクションプリフェイス後にHTTP/2フレームを送って良い

24. バイナリフレーム
フレーム長のフィールドは draft 14で24bitに

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