HTTP/2 入門

8.5K Views

May 23, 14

スライド概要

profile-image

2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

HTTP/2  ⼊入⾨門

2.

⽯石澤  基   CMO室  エンジニア

3.

この資料料の内容 • HTTP/2  の歴史   • HTTP/2  の特徴   • HTTP/2  の最新動向

4.

HTTP/2  の歴史

5.

現在までの流流れ 2012/01:  IETF  HTTPbis  WGで次世代のHTTPの話が出始める   2012/06:  HTTP/2の議論論を開始するための草案が提出される   2012/11:  SPDYを議論論の開始点として策定が始まる   2013/01:  最初の草案がリリースされる   2013/08:  最初の実装向け草案がリリースされる   2014/05:  <今はココ!>   2014/07:  最終草案リリース  (WGラストコール)  (予定)

6.

SPDY? Webページの読み込みレイテンシを削減することを目標として、 Googleが開発している実験用の転送プロトコルです。 ! Googleは自社サイトとChromeにSPDYを適用することで、プロトコル の評価を進めていました。そのような実績が高く評価され、HTTP/2の 議論の出発点として、SPDYが採用されました。 ! 現在では、TwitterやFacebookといったサービスをはじめ、Firefox、 Internet ExplorerといったブラウザもSPDYをサポートしています。

7.

よくある質問 ? 現在のHTTPにあるような、リクエストやレスポンス、   ヘッダーなどの仕組みそのものに変更更はありますか?

8.

よくある質問 ! いいえ、変更更はありません。 (一部の例外は除く)

9.

よくある質問 “ This document addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection. ― HTTP/2 Draft, Introduction

10.

HTTP/2  の⽬目的 HTTPの構文に最適化された転送手段を提供することで、従来のHTTPで おきていたパフォーマンス上の問題を解決します。 • よりスケーラブルに処理理可能なメッセージ構造の提供   • 単⼀一の接続上で複数のリクエストを送信する仕組みの提供   • 冗⻑⾧長なヘッダーに対する効率率率のよい符号化⽅方式の提供

11.

HTTP/2  の特徴

12.

接続の開始 HTTP/2では、今まで通り http:// および https:// のURLを使用します。 そのため、HTTP/2の接続を開始するためには、プロトコルを切り替える 仕組みが必要となっています。 ALPN   https://  から始まるURLで使⽤用します。SSLハンドシェイクの際にアプ リケーションが使⽤用するプロトコルを決定します。   ! HTTP  Upgrade   http://  から始まるURLで使⽤用します。最初にHTTP/1.1のリクエストを 送信してから、以降降の通信をHTTP/2に切切り替えます。

13.

Application  Layer  Protocol  Negotiation  (ALPN) クライアント サーバー ClientHello ALPN Extension HTTP/1 SPDY/3 h2 ServerHello ALPN Extension Selected Protocol h2 SSL  ハンドシェイク

14.
[beta]
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

サーバー

15.

バイナリフレーム HTTP/1.xまでは全てのデータがテキストで送信されていましたが、 HTTP/2では全てバイナリフレームと呼ばれる単位に分割されます。 バイナリフレームの種類 フレームタイプ 概要 DATA リクエストボディや、レスポンスボディを転送するフレーム HEADERS 圧縮済みのHTTPヘッダーを転送するフレーム PRIORITY ストリームの優先度を変更するフレーム RST̲STREAM ストリームの終了を通知するフレーム SETTINGS 接続に関する設定を変更するフレーム PUSH̲PROMISE サーバーからのリソースのプッシュを通知するフレーム PING 接続状況を確認するフレーム GOAWAY 接続を終了するフレーム WINDOW̲UPDATE フロー制御ウインドウを更新するフレーム CONTINUATION HEADERSフレームやPUSH̲PROMISEフレームの続きのデータを転送するフレーム ALTSVC 代替サービスの情報を提供するフレーム BLOCKED 送信がブロックされていることを通知するフレーム

16.

バイナリフレーム 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 {バイナリデータ}

17.

バイナリフレーム 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 {バイナリデータ}

18.

バイナリフレーム フレームヘッダー 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 (*) ...! +---------------------------------------------------------------+!

19.

ストリームによる多重化 HTTP/2  接続 ストリーム  #1 レスポンス     ストリーム  #3 クライアント リクエスト     ストリーム  #5 リクエスト     サーバー

20.

ストリームによる多重化 クライアント サーバー リクエスト  #1 レスポンス  #1 クライアント サーバー リクエスト  #1 リクエスト  #2 リクエスト  #3 リクエスト  #2 レスポンス  #1 レスポンス  #2 レスポンス  #2 レスポンス  #3 HTTP/1.x HTTP/1.x  (パイプライン)

21.

ストリームによる多重化 クライアント サーバー リクエスト  #1 リクエスト  #2 リクエスト  #3 レスポンス  #2 レスポンス  #3 レスポンス  #1 HTTP/2

22.

ヘッダー圧縮 HTTP  1.xでは、UserAgentやCookieといったHTTPヘッダーが何度度も同 じ内容で送信されており、オーバーヘッドが⽣生じていることが分かって います。   ! SPDYではHTTPヘッダーをgzip圧縮することで、これに対処しました。 しかし、CRIMEと呼ばれる攻撃⼿手法が⾒見見つかったため、圧縮率率率を下げざ るをえなくなってしまいました。   ! そこで、HTTP/2では、ヘッダーの差分だけを送るアルゴリズムを使っ たHPACKと呼ばれるヘッダー圧縮機構を採⽤用しています。

23.

HPACK HPACKで使われる⽤用語を簡単に理理解しておきましょう。 Reference  Set 前回送信したヘッダー名/値ペアのセットです。 クライアントやサーバーは、ヘッダーの差分を計算するために接続ごと にリファレンスセットを保持します。 Static  Table よく送信されるヘッダー名/値ペアにIDを設定したものを管理するテーブ ルです。クライアントとサーバーの両方で保持されます。送信するヘッ ダーがこのテーブルに含まれていた場合は、設定されたIDを使用してヘッ ダーを送信することができます。

24.

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

25.

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

26.

サーバープッシュ あるレスポンスに必要なリソースを事前にサーバーから送信するための仕 組みです。事前に送られたリソースはクライアント側でキャッシュされ るため、クライアントはリクエストを送信する必要がなくなります。 クライアント index.html  をください サーバー リクエスト サーバープッシュ  #1 サーバープッシュ  #2 レスポンス index.html  を表⽰示するには、 yahoo.css  が必要だから先に送るね index.html  を表⽰示するには、 logo.png  も必要だから先に送るね index.html  を送るね

27.

サーバープッシュの活⽤用例例 トランシーバーアプリの「Voxer」ではSPDYのサーバープッシュの機能 を活用して、音声メッセージのプッシュを実現しているそうです。 クライアントA 私宛のメッセージが   あればプッシュして   ください サーバー クライアントB リクエスト リクエスト Aさんに   メッセージを送信 サーバープッシュ Bさんからの   メッセージを受信 レスポンス 送信完了了!

28.

ストリーム優先度度 特定のリソースを優先的に取得したいような場合、クライアントはフレー ムに優先度情報を含めることで、サーバーの処理順序を制御することが できる可能性があります。 クライアント サーバー リクエスト  #1 2つめのリクエストを優先で   処理理してください。 リクエスト  #2  (+優先度度情報) レスポンス  #2 レスポンス  #1 2つめのリクエストを優先した ので先に返します。

29.

HTTP/2  の最新動向

30.

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

31.

各社の動向 Mozilla 仕様策定と実装で積極的に参加しています。最新のドラフト版に対応し たFirefoxが開発されており、実際に使って試すことができます。 Microsoft 仕様策定と実装で積極的に参加しています。C#で実装されたKatanaサー バーのHTTP/2対応をしたり、IEについても「HTTP/2に備える」とブロ グで発信するなど、積極的にサポートしていくようです。 Twitter 実装に積極的に参加しています。HPACKのJava実装を公開したり、サー ビスの本番環境ですでにHTTP/2をデプロイするなど、積極的にパフォー マンスなどを調査しています。

32.

参考情報 http://www.oreilly.co.jp/books/9784873116761/

33.

Enjoy  HTTP/2  :)