8K Views
May 23, 14
スライド概要
2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp
HTTP/2 ⼊入⾨門
⽯石澤 基 CMO室 エンジニア
この資料料の内容 • HTTP/2 の歴史 • HTTP/2 の特徴 • HTTP/2 の最新動向
HTTP/2 の歴史
現在までの流流れ 2012/01: IETF HTTPbis WGで次世代のHTTPの話が出始める 2012/06: HTTP/2の議論論を開始するための草案が提出される 2012/11: SPDYを議論論の開始点として策定が始まる 2013/01: 最初の草案がリリースされる 2013/08: 最初の実装向け草案がリリースされる 2014/05: <今はココ!> 2014/07: 最終草案リリース (WGラストコール) (予定)
SPDY? Webページの読み込みレイテンシを削減することを目標として、 Googleが開発している実験用の転送プロトコルです。 ! Googleは自社サイトとChromeにSPDYを適用することで、プロトコル の評価を進めていました。そのような実績が高く評価され、HTTP/2の 議論の出発点として、SPDYが採用されました。 ! 現在では、TwitterやFacebookといったサービスをはじめ、Firefox、 Internet ExplorerといったブラウザもSPDYをサポートしています。
よくある質問 ? 現在のHTTPにあるような、リクエストやレスポンス、 ヘッダーなどの仕組みそのものに変更更はありますか?
よくある質問 ! いいえ、変更更はありません。 (一部の例外は除く)
よくある質問 “ This document addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection. ― HTTP/2 Draft, Introduction
HTTP/2 の⽬目的 HTTPの構文に最適化された転送手段を提供することで、従来のHTTPで おきていたパフォーマンス上の問題を解決します。 • よりスケーラブルに処理理可能なメッセージ構造の提供 • 単⼀一の接続上で複数のリクエストを送信する仕組みの提供 • 冗⻑⾧長なヘッダーに対する効率率率のよい符号化⽅方式の提供
HTTP/2 の特徴
接続の開始 HTTP/2では、今まで通り http:// および https:// のURLを使用します。 そのため、HTTP/2の接続を開始するためには、プロトコルを切り替える 仕組みが必要となっています。 ALPN https:// から始まるURLで使⽤用します。SSLハンドシェイクの際にアプ リケーションが使⽤用するプロトコルを決定します。 ! HTTP Upgrade http:// から始まるURLで使⽤用します。最初にHTTP/1.1のリクエストを 送信してから、以降降の通信をHTTP/2に切切り替えます。
Application Layer Protocol Negotiation (ALPN) クライアント サーバー ClientHello ALPN Extension HTTP/1 SPDY/3 h2 ServerHello ALPN Extension Selected Protocol h2 SSL ハンドシェイク
HTTP Upgrade
クライアント
リクエスト
GET /index.html HTTP/1.1
Host: www.yahoo.co.jp
Connection: Upgrade, HTTP2-Settings
Upgrade: h2
HTTP2-Settings: 4389978938ab379
レスポンス
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2
!
<HTTP/2 データ....>
HTTP Upgrade
サーバー
バイナリフレーム HTTP/1.xまでは全てのデータがテキストで送信されていましたが、 HTTP/2では全てバイナリフレームと呼ばれる単位に分割されます。 バイナリフレームの種類 フレームタイプ 概要 DATA リクエストボディや、レスポンスボディを転送するフレーム HEADERS 圧縮済みのHTTPヘッダーを転送するフレーム PRIORITY ストリームの優先度を変更するフレーム RST̲STREAM ストリームの終了を通知するフレーム SETTINGS 接続に関する設定を変更するフレーム PUSH̲PROMISE サーバーからのリソースのプッシュを通知するフレーム PING 接続状況を確認するフレーム GOAWAY 接続を終了するフレーム WINDOW̲UPDATE フロー制御ウインドウを更新するフレーム CONTINUATION HEADERSフレームやPUSH̲PROMISEフレームの続きのデータを転送するフレーム ALTSVC 代替サービスの情報を提供するフレーム BLOCKED 送信がブロックされていることを通知するフレーム
バイナリフレーム HTTP/1.1 リクエスト POST /upload HTTP/1.1 Host: www.yahoo.co.jp Content-Type: image/jpeg Content-Length: 123 ! {バイナリデータ} HTTP/2 フレーム HEADERS :method: POST :scheme: http :authority: www.yahoo.co.jp :path: /upload content-‐‑‒type: image/jpeg content-‐‑‒length: 123 DATA {バイナリデータ}
バイナリフレーム HTTP/1.1 レスポンス HTTP/1.1 200 OK Content-Type: image/jpeg Content-Length: 123 ! {バイナリデータ} HTTP/2 フレーム HEADERS :status: 200 content-‐‑‒type: image/jpeg content-‐‑‒length: 123 DATA {バイナリデータ}
バイナリフレーム フレームヘッダー 0 1 2 3! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! | R | Length (14) | Type (8) | Flags (8) |! +-+-+-----------+---------------+-------------------------------+! |R| Stream Identifier (31) |! +-+-------------------------------------------------------------+! | Frame Payload (0...) ...! +---------------------------------------------------------------+ HEADERSフレーム ペイロード 0 1 2 3! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! | [Pad High(8)] | [Pad Low (8)] |X| [Priority (31)] ...! +---------------+---------------+-+-----------------------------+! ...[Priority] | Header Block Fragment (*) ...! +-------------------------------+-------------------------------+! | Header Block Fragment (*) ...! +---------------------------------------------------------------+! | Padding (*) ...! +---------------------------------------------------------------+!
ストリームによる多重化 HTTP/2 接続 ストリーム #1 レスポンス ストリーム #3 クライアント リクエスト ストリーム #5 リクエスト サーバー
ストリームによる多重化 クライアント サーバー リクエスト #1 レスポンス #1 クライアント サーバー リクエスト #1 リクエスト #2 リクエスト #3 リクエスト #2 レスポンス #1 レスポンス #2 レスポンス #2 レスポンス #3 HTTP/1.x HTTP/1.x (パイプライン)
ストリームによる多重化 クライアント サーバー リクエスト #1 リクエスト #2 リクエスト #3 レスポンス #2 レスポンス #3 レスポンス #1 HTTP/2
ヘッダー圧縮 HTTP 1.xでは、UserAgentやCookieといったHTTPヘッダーが何度度も同 じ内容で送信されており、オーバーヘッドが⽣生じていることが分かって います。 ! SPDYではHTTPヘッダーをgzip圧縮することで、これに対処しました。 しかし、CRIMEと呼ばれる攻撃⼿手法が⾒見見つかったため、圧縮率率率を下げざ るをえなくなってしまいました。 ! そこで、HTTP/2では、ヘッダーの差分だけを送るアルゴリズムを使っ たHPACKと呼ばれるヘッダー圧縮機構を採⽤用しています。
HPACK HPACKで使われる⽤用語を簡単に理理解しておきましょう。 Reference Set 前回送信したヘッダー名/値ペアのセットです。 クライアントやサーバーは、ヘッダーの差分を計算するために接続ごと にリファレンスセットを保持します。 Static Table よく送信されるヘッダー名/値ペアにIDを設定したものを管理するテーブ ルです。クライアントとサーバーの両方で保持されます。送信するヘッ ダーがこのテーブルに含まれていた場合は、設定されたIDを使用してヘッ ダーを送信することができます。
HPACK 送信するヘッダー (1回⽬目) :method: GET :scheme: http :path: / :authority: www.yahoo.co.jp user-agent: chrome ③エンコード エンコード済みヘッダー 1 2 3 4: www.yahoo.co.jp user-agent: chrome ①差分確認 Reference Set なし ②検索索 Static Table ID ヘッダー名 値 1 :method GET 2 :scheme http 3 :path / 4 :authority
HPACK 送信するヘッダー (2回⽬目) ①差分確認 :method: GET :scheme: http :path: / :authority: www.yahoo.co.jp user-agent: chrome :method: GET :scheme: http :path: /css/yahoo.css :authority: www.yahoo.co.jp user-agent: chrome custom: yahoo ②検索索 ③エンコード エンコード済みヘッダー 3: /css/yahoo.css custom: yahoo Reference Set Static Table ID ヘッダー名 値 1 :method GET 2 :scheme http 3 :path / 4 :authority
サーバープッシュ あるレスポンスに必要なリソースを事前にサーバーから送信するための仕 組みです。事前に送られたリソースはクライアント側でキャッシュされ るため、クライアントはリクエストを送信する必要がなくなります。 クライアント index.html をください サーバー リクエスト サーバープッシュ #1 サーバープッシュ #2 レスポンス index.html を表⽰示するには、 yahoo.css が必要だから先に送るね index.html を表⽰示するには、 logo.png も必要だから先に送るね index.html を送るね
サーバープッシュの活⽤用例例 トランシーバーアプリの「Voxer」ではSPDYのサーバープッシュの機能 を活用して、音声メッセージのプッシュを実現しているそうです。 クライアントA 私宛のメッセージが あればプッシュして ください サーバー クライアントB リクエスト リクエスト Aさんに メッセージを送信 サーバープッシュ Bさんからの メッセージを受信 レスポンス 送信完了了!
ストリーム優先度度 特定のリソースを優先的に取得したいような場合、クライアントはフレー ムに優先度情報を含めることで、サーバーの処理順序を制御することが できる可能性があります。 クライアント サーバー リクエスト #1 2つめのリクエストを優先で 処理理してください。 リクエスト #2 (+優先度度情報) レスポンス #2 レスポンス #1 2つめのリクエストを優先した ので先に返します。
HTTP/2 の最新動向
HTTP/2 に対応した実装 HTTP/2プロトコルを実装したライブラリは既に複数公開されています。 これらのライブラリを使用すれば、HTTP/2の検証やテストをはじめる ことができます。 実装 言語 ロール 対応する草案 nghttp2 C クライアント、サーバー、プロキシ Draft 12 http2-katana C# サーバー Draft 09 node-http2 Node.js サーバー、クライアント Draft 12 Netty Java サーバー、クライアント Draft 12 Wireshark C その他 Draft 12 Okhttp Java クライアント (Android) Draft 12 curl / libcurl C クライアント Draft 12
各社の動向 Mozilla 仕様策定と実装で積極的に参加しています。最新のドラフト版に対応し たFirefoxが開発されており、実際に使って試すことができます。 Microsoft 仕様策定と実装で積極的に参加しています。C#で実装されたKatanaサー バーのHTTP/2対応をしたり、IEについても「HTTP/2に備える」とブロ グで発信するなど、積極的にサポートしていくようです。 Twitter 実装に積極的に参加しています。HPACKのJava実装を公開したり、サー ビスの本番環境ですでにHTTP/2をデプロイするなど、積極的にパフォー マンスなどを調査しています。
参考情報 http://www.oreilly.co.jp/books/9784873116761/
Enjoy HTTP/2 :)