Download as PDF, PPTX
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
HTTP/2 入門
- 1.
- 2. ⽯石澤 基 CMO室 エンジニア
- 3. この資料料の内容 • HTTP/2 の歴史 • HTTP/2 の特徴 • HTTP/2 の最新動向
- 4.
- 5. 現在までの流流れ 2012/01: IETF HTTPbis WGで次世代のHTTPの話が出始める 2012/06: HTTP/2の議論論を開始するための草案が提出される 2012/11: SPDYを議論論の開始点として策定が始まる 2013/01: 最初の草案がリリースされる 2013/08: 最初の実装向け草案がリリースされる 2014/05: ＜今はココ!＞ 2014/07: 最終草案リリース (WGラストコール) (予定)
- 6.
- 7.
- 8.
- 9. よくある質問 This document addressesthese issues by defining an optimized mapping of HTTP's semantics to an underlying connection. “ ― HTTP/2 Draft, Introduction
- 10. HTTP/2 の⽬目的 HTTPの構文に最適化された転送手段を提供することで、従来のHTTPで おきていたパフォーマンス上の問題を解決します。 • よりスケーラブルに処理理可能なメッセージ構造の提供 • 単⼀一の接続上で複数のリクエストを送信する仕組みの提供 • 冗⻑⾧長なヘッダーに対する効率率率のよい符号化⽅方式の提供
- 11.
- 12. 接続の開始 ALPN https:// から始まるURLで使⽤用します。SSLハンドシェイクの際にアプ リケーションが使⽤用するプロトコルを決定します。 ! HTTP Upgrade http:// から始まるURLで使⽤用します。最初にHTTP/1.1のリクエストを 送信してから、以降降の通信をHTTP/2に切切り替えます。 HTTP/2では、今まで通り http:// および https:// のURLを使用します。 そのため、HTTP/2の接続を開始するためには、プロトコルを切り替える 仕組みが必要となっています。
- 13. Application Layer Protocol Negotiation (ALPN) SSL ハンドシェイク クライアント サーバー ClientHello ServerHello ALPN Extension HTTP/1 SPDY/3 h2 ALPN Extension Selected Protocol h2
- 14. HTTP Upgrade HTTP Upgrade クライアントサーバー リクエスト レスポンス GET /index.html HTTP/1.1 Host: www.yahoo.co.jp Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: 4389978938ab379 HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h2c ! <HTTP/2 データ....>
- 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. バイナリフレーム POST /upload HTTP/1.1 Host:www.yahoo.co.jp Content-Type: image/jpeg Content-Length: 123 ! {バイナリデータ} HTTP/1.1 リクエスト 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 200 OK Content-Type:image/jpeg Content-Length: 123 ! {バイナリデータ} HTTP/1.1 レスポンス HTTP/2 フレーム HEADERS :status: 200 content-‐‑‒type: image/jpeg content-‐‑‒length: 123 DATA {バイナリデータ}
- 18. バイナリフレーム フレームヘッダー 0 1 23! 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...) ...! +---------------------------------------------------------------+ 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) |! +-+-------------+---------------+-------------------------------+! |E| Stream Dependency? (31) |! +-+-------------+-----------------------------------------------+! | Weight? (8) |! +---------------+-----------------------------------------------+! | Header Block Fragment (*) ...! +---------------------------------------------------------------+! | Padding (*) ...! +---------------------------------------------------------------+ HEADERSフレーム ペイロード
- 19. クライアント サーバー HTTP/2 接続 ストリーム #1 ストリーム #3 ストリーム #5 レスポンス リクエスト リクエスト ストリームによる多重化
- 20. ストリームによる多重化 HTTP/1.x クライアント サーバー HTTP/1.x (パイプライン) クライアントサーバー リクエスト #1 レスポンス #1 レスポンス #2 リクエスト #2 リクエスト #1 リクエスト #2 リクエスト #3 レスポンス #1 レスポンス #2 レスポンス #3
- 21. ストリームによる多重化 HTTP/2 クライアント サーバー リクエスト #1 リクエスト #2 リクエスト #3 レスポンス #1 レスポンス #2 レスポンス #3
- 22. ヘッダー圧縮 HTTP 1.xでは、UserAgentやCookieといったHTTPヘッダーが何度度も同 じ内容で送信されており、オーバーヘッドが⽣生じていることが分かって います。 ! SPDYではHTTPヘッダーをgzip圧縮することで、これに対処しました。 しかし、CRIMEと呼ばれる攻撃⼿手法が⾒見見つかったため、圧縮率率率を下げざ るをえなくなってしまいました。 ! そこで、HTTP/2では、ヘッダーの差分だけを送るアルゴリズムを使っ たHPACKと呼ばれるヘッダー圧縮機構を採⽤用しています。
- 23.
- 24. HPACK :method: GET :scheme: http :path:/ :authority: www.yahoo.co.jp user-agent: chrome 送信するヘッダー (1回⽬目) エンコード済みヘッダー 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 :method: GET :scheme: http :path:/css/yahoo.css :authority: www.yahoo.co.jp user-agent: chrome custom: yahoo 送信するヘッダー (2回⽬目) エンコード済みヘッダー 3: /css/yahoo.css custom: yahoo ③エンコード Static Table ID ヘッダー名 値 1 :method GET 2 :scheme http 3 :path / 4 :authority ②検索索 Reference Set ①差分確認 :method: GET :scheme: http :path: / :authority: www.yahoo.co.jp user-agent: chrome
- 26. サーバープッシュ あるレスポンスに必要なリソースを事前にサーバーから送信するための仕 組みです。事前に送られたリソースはクライアント側でキャッシュされ るため、クライアントはリクエストを送信する必要がなくなります。 クライアント サーバー レスポンス リクエスト サーバープッシュ #2 サーバープッシュ #1 index.html をください index.html を表⽰示するには、 yahoo.css が必要だから先に送るね index.html を表⽰示するには、 logo.png も必要だから先に送るね index.html を送るね
- 27.
- 28. ストリーム優先度度 特定のリソースを優先的に取得したいような場合、クライアントはフレー ムに優先度情報を含めることで、サーバーの処理順序を制御することが できる可能性があります。 クライアント サーバー レスポンス #2 リクエスト #1 2つめのリクエストを優先で 処理理してください。 2つめのリクエストを優先した ので先に返します。 リクエスト #2 (+優先度度情報) レスポンス #1
- 29.
- 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.
- 32.
- 33.