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

ハイパフォーマンスブラウザネッ
トワーキング読書会
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の相互作用を明確に定義する。特に中間装置での扱いについて。
• →中間装置での扱い?? (^ω^;)
• 新しい拡張ポイントがあればそれを明確に定義し、その適切な使用法のポリシーを確立する

つまり
• 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/

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

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

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

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

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

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

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

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (14)

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

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

Mehr von hagino 3000

Mehr von hagino 3000 (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

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