HTTP/2の現状とこれから

96,072 views

Published on

HTML5 Conference 2015 資料 「HTTP/2の現状とこれから」

Published in: Technology
0 Comments
186 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
96,072
On SlideShare
0
From Embeds
0
Number of Embeds
57,721
Actions
Shares
0
Downloads
231
Comments
0
Likes
186
Embeds 0
No embeds

No notes for slide

HTTP/2の現状とこれから

  1. 1. HTTP/2の現状とこれから 大津 繁樹 株式会社インターネットイニシアティブ(IIJ) HTML5 Conference 2015年1月25日
  2. 2. 自己紹介 • 名前: 大津 繁樹 • 所属: 株式会社インターネットイニシアティブ(IIJ) アプリケーション開発部 • Twitter: @jovi0608 • ブログ: ぼちぼち日記 http://d.hatena.ne.jp/jovi0608/ • GitHub: https://github.com/shigeki/ • 新技術の検証・評価を行ってます。 (Node.js, io.js,SPDY, HTTP/2,HTML5) • iij-http2の開発を通じてIETFのHTTP/2標準化作業に参画中
  3. 3. HTTP/2 はRFC化目前です • HTTP/2 • IESGレビュー終了。コメントを受け てドラフトを改訂。その後承認見込 • HPACK • IESG承認済(1/23) 発行プロセスが順調なら桜が咲く前にはRFC化かも Ethernet IP(v4/v6) TCP TLS HTTP/2 Frame Layer HTTP/1.1 Semantics
  4. 4. 内容 • これまで • HTTP/1.1の問題点のおさらい (+デモ) • 現状 (SPDY, HTTP/2) • SPDY, HTTP/2の対応状況 • HTTP/2の最終仕様の概要 (いくつかピックアップ) • これから • HTTP/2の拡張 → HTTP/3の展望 • HTTP/2の応用:WebPush + Push API (Service Worker+ Server Push) • 新プロトコル: QUIC (+デモ)
  5. 5. これまで (HTTP/1.1の問題点のおさらい)
  6. 6. HTTPプロトコルの年表 1990 1995 2000 2005 2010 2015 Webの 始まり HTTP/0.9 HTTP/1.0 RFC1945 HTTP/1.1 RFC2068 HTTP/1.1 RFC2616 HTTP/1.1 RFC7230-5 HTTP/2 SPDY/2 SPDY/3 SPDY/3.1 httpbis WG 暗黒の時代 HTTP-NG 中止
  7. 7. HTTP/1.1の問題点のおさらい 1. HTTP Head of Line Blocking 2. ネットワーク通信の利用が非効率 3. 曖昧でテキスト処理が煩雑
  8. 8. 1. HTTP Head of Line Blocking クライアント サーバ HTTP/1.1 1本のTCP接続 HTTP リクエスト HTTPレスポンス 待ち時間 HTTP リクエスト
  9. 9. HTTP/1.1 ブラウザは最大同時4~6TCP接続に制限 最大同時並列6
  10. 10. HTTP/2 100以上の同時リクエストが可能 全部同時
  11. 11. HTTP/2の全二重多重化通信 クライアント サーバ 1つの TCP接続 ストリーム(id:1) フレーム フレーム ストリーム(id:3) フレーム フレーム ストリーム(id:5) フレーム フレーム HTTP リクエスト レスポンス HTTP リクエスト レスポンス HTTP リクエスト レスポンス 仮想的なストリームチャンネルを生成して多重化を実現 後でデモします。
  12. 12. 2. HTTP/1.1はネットワーク通信の利用が非効率 クライアント サーバ TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 それぞれのTCP接続が独立して輻輳制御を行う
  13. 13. HTTP/1.1は非効率なプロトコル 0 10 20 30 40 50 60 10 15 20 25 30 35 40 45 輻輳ウィンドウサイズ(mss) 時間(sec) HTTP/1.1+SSLの輻輳ウィンドウサイズの変遷 SSL1 SSL2 SSL3 SSL4 SSL5 SSL6 6本のTCPがバラバラに 輻輳制御。帯域を有効 に使いきれてない
  14. 14. HTTP/2(SPDY)は効率的なプロトコル 0 10 20 30 40 50 60 60 65 70 75 80 85 90 95 輻輳ウィンドウサイズ(mss) 時間(sec) SPDY利用時の輻輳ウィンドウサイズの変遷 SPDY 1本のTCPで最高速まで利 用。帯域を最大限に効率的 に使っている。
  15. 15. 3. HTTP/1.1は処理が煩雑なテキストプロトコル HTTP/1.1 200 OK Content-Type: image/jpeg Transfer-Encoding: chunked Trailer: Foo 123 {binary data} 0 Foo: bar Status-Lineは一行目 空白は1つ ヘッダ名は大文字・小文 字区別せず ヘッダ領域の区切り はCRLF一つ :の後に空白を許可 CRLFで改行、複数行 対応は廃止 レスポンスデータがchunkedであ り、サイズはまだ不定 一番最後にFooヘッダが付与 されることを宣言 続くデータが123バイト であることを宣言 データ終了の合図 Trailヘッダ chunk終了合図 のCRLF
  16. 16. HTTP/2はきっちりしたバイナリープロトコル 00 00 00 01 01 04 00 00 1a 88 5c 82 08 ・・・・・・ 73 ff 00 00 00 01 00 00 00 00 7b {binary data} :status = 200 content-length = 123 content-type = image/jpeg trailer = Foo HEADERS DATA フレーム長:28バイト フレーム長:123バイト フレームタイプ:HEADERS, END_HEADERSフラグ ストリームID: 1 ストリームID: 1 フレームタイプ:DATA, フラグなし (* 記載スペースの都合上Trailer HEADERSは省いています) データの 位置・サイズ・型 が明確
  17. 17. デモ: HTTP/2(SPDY)は、本当にHTTP Head of Line Blocking を回避できているのか? クライアント 画像サーバA 画像サーバB Reverse Proxy HTTP/2 多重化通信 レスポンスが速い レスポンスが遅い
  18. 18. デモ: SPDY 対 SSL(HTTP/1.1) HTTP Head of Line Blocking の違い 1. 少数画像 vs 多数画像。 2. 3枚目の画像毎に3秒のレスポンス遅延を入れる。
  19. 19. 現状 (SPDY, HTTP/2)
  20. 20. SPDYのブラウザ対応状況 http://caniuse.com/#feat=spdy ほとんどのブラウザーが対応済。 HTTP/2仕様策定完了後はHTTP/2に移行見込み
  21. 21. HTTP/2の対応状況 • Firefox35: デフォルト有効(h2-14) • Chrome41: デフォルト有効(h2-14) • IE on Windows10 Technical Preview: h2-14 • Google: h2-14,h2-15 • Twitter: h2-15 (注: h2-15とh2-14は技術的に同じ仕様です)
  22. 22. HTTP/2を見るには? Chrome chrome://net-internals/#spdy Firefox デバッグログ見る しかない。 利用プロトコル名 はレスポンスヘッ ダに付与
  23. 23. HTTP/2の最終仕様概要 • 前回のHTML5 Conference でも話をしましたので、 http://www.slideshare.net/shigeki_ohtsu/html5-conf2013-http2iijohtsu 更新された中でいくつかトピックスを紹介します。
  24. 24. HTTP/2プライオリティ クライアント Reverse Proxy コンテンツ HTML 画像 CSS, jS HTML CSS JS 画像1 画像2 画像3 画像4 依存性と重みを指定 weight:16 weight:16 プライオリティのユースケース • ファイルタイプ(HTML/CSS/JS/画像)に応じ た返答順序の指定 • タブ切り替えによる重みの上げ下げ • 分割されたビデオデータなど順番が明示的 に決められている場合
  25. 25. Firefox38のプライオリティ依存機能(h2-16) Stream:0x0 Stream:0x3 Leader Stream:0x5 Unblocked Stream:0x7 Background weight:201 weight:1 weight:101 Stream:0xb Follower Stream:0x9 Speculative weight:1 weight:1 css,js ファイル html,images等 その他 XHR 非同期js 明示的な バックグラウンド リクエスト beacon等 大きなバック グラウンド リクエスト idle ストリーム
  26. 26. HTTP/1.1セマンティクスと非互換なところ • ホップ-バイ-ホップ ヘッダの利用禁止 • ホップ-バイ-ホップ間の通信制御はHTTP/2フレームの役割であるため、 HTTPヘッダによる制御を禁止。 • Connection, Transfer-Encoding, TE, Upgrade, Keep-Alive, Proxy-Connection ヘッダは利用禁止。 • TE: trailers だけ例外 • Status Code: 101 (Switching Protocols) も禁止 クライアント プロキシ プロキシ プロキシ サーバ hophop hop End-To-Endヘッダだけ許可
  27. 27. TLS利用条件の厳格化 • HTTP/2は、仕様上平文での接続(http://)も規定されており、TLS利用は 必須ではなくなりました。 • ただしChromeやFirefoxではTLS利用したHTTP/2のみサポート。MSが HTTP/2の平文通信に賛同しているが、IEでの実装はまだ。 • HTTP/2の利用は実質的にTLSを用いたものが中心になる見込み。 • 現行のTLS1.2でもまだセキュリティ的に十分でないのでTLS利用条件を 厳格化して対応 • renegotiation, compressionの禁止 • SNI利用の必須 • PFS(Perfect Forward Secrecy), AEAD利用の必須(RC4,CBCモード利用禁止) • 検討中のTLS1.3の仕様を先取りしたもの
  28. 28. これから (拡張、応用、新プロトコル)
  29. 29. HTTP/2の拡張→HTTP/3の展望 1. ALT-SVCフレーム • 負荷分散やメンテなどのサーバ切り替え、プロトコルの切り替え 2. WebSocket over HTTP/2 • HTTP/2仕様を拡張してWebSocket多重化を実現 3. 明示的プロキシ機能 • Chrome for Android の DATA Compression機能の仕組みを標準化へ • プロキシとの間をHTTP/2で接続。 平文http:// のコンテンツキャッシュ 4. 日和見暗号(opportunistic encryption) • http:// の通信でサーバ認証せずに暗号化を行う。
  30. 30. HTTP/2の応用 WebPush いろんな場面でプッシュ通知は必要 1. ブラウザ上でアプリが動作している時 • チャット等の通常のアプリ通知 2. ブラウザは立ち上げているがアプリは動作していない時 • SNSのメッセージやweb feedを受ける 3. ブラウザも立ち上げていない時 • WebRTCによる入電でウェブアプリを立ち上げる 4. 1つのブラウザでアプリを複数インスタンス立ち上げてい る。又は、異なるブラウザで同一のアプリを動作させてい る。 • そのうちの1つにだけプッシュ通知したい。 • 全部にプッシュ通知をブロードキャストしたい。 • 複数アカウントでメール利用など。
  31. 31. HTTP/2の応用 Service Worker+ Server Push プッシュサーバ アプリケーション サーバ Webアプリの通信 HTTPS必須 5. Service Worker上で Pushイベントが発生。 ArrayBuffer, blob, json, textの形式でプッシュ データを取り出せる。 2. HTTP PUTのリクエスト ボディにプッシュメッ セージを付けて送信 4. HTTP/2サーバプッシュを利用 してクライアントに通知 3. 複数アプリのプッシュ 通知をチャネルで区別し、 一つの接続上で送信 1. クライアントからプッシュサーバ名と登録IDを通知 Service Worker ウェブ アプリ ブラウザ Push API クライアント
  32. 32. Service Workerからこう見える // 登録されたService Workerのコード this.onpush = function(event) { console.log(event.data); // event.data は、ArrayBuffer, blob, json, text形式 // ここでIndexedDBにdataを書き込んだり、 // 開いているウィンドウにdataを送ったり、 // Notificationを表示したりなどができる。 } Web Pushは、複数のブラウザ、複数のアプリインスタンス、アプ リの起動・停止中等様々な場面でもプッシュ通知が行える
  33. 33. 新プロトコル: QUIC (Quic UDP Internet Connections) IP(IPv4/IPv6) UDP TCP TLS QUIC SPDY HTTP 暗号化・認証 セッション確立、フロー制御 エラー補正, 輻輳制御 • Googleが独自に開発しているプロトコル • UDP上でTCP+TLS相当+αの機能を実装 • 最短0-RTTで再接続、暗号通信を必須化 • TCPと同様の輻輳制御で帯域の公平化 • 独自の誤り訂正と再送機能でパケットロス によるTCPのHead of Line Blockingを回避 • Googleの全サービスで運用中、Chrome のフィールドテスト中(*) • Stable版: 0.2%(Desktop), 2%(Android) • Beta版: 25%(Desktop), 50%(Android) • 知らない間に使っているかも? • 今年にライブラリ化を予定 (* 割合は2014/08時点のGoogleの公表値)
  34. 34. QUICデモ パケットロス耐性 QUIC vs SPDY クライアント サーバ Ajax SPDY over TCP Ajax QUIC over UDP 30%パケットロス
  35. 35. おわり

×