Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a HTTP/2の現状とこれから
Semelhante a HTTP/2の現状とこれから (20)
Mais de shigeki_ohtsu
Mais de shigeki_ohtsu (16)
HTTP/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. 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. 内容 • これまで • 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 （+デモ）
- 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. HTTP/1.1の問題点のおさらい 1. HTTP Head of Line Blocking 2. ネットワーク通信の利用が非効率 3. 曖昧でテキスト処理が煩雑
- 8. 1. HTTP Head of Line Blocking クライアント サーバ HTTP/1.1 1本のTCP接続 HTTP リクエスト HTTPレスポンス 待ち時間 HTTP リクエスト
- 12. 2. HTTP/1.1はネットワーク通信の利用が非効率 クライアント サーバ TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 それぞれのTCP接続が独立して輻輳制御を行う
- 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. 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. 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. 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. デモ： HTTP/2(SPDY)は、本当にHTTP Head of Line Blocking を回避できているのか？ クライアント 画像サーバA 画像サーバB Reverse Proxy HTTP/2 多重化通信 レスポンスが速い レスポンスが遅い
- 18. デモ: SPDY 対 SSL(HTTP/1.1) HTTP Head of Line Blocking の違い 1. 少数画像 ｖｓ 多数画像。 2. 3枚目の画像毎に3秒のレスポンス遅延を入れる。
- 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は技術的に同じ仕様です)
- 23. HTTP/2の最終仕様概要 • 前回のHTML5 Conference でも話をしましたので、 http://www.slideshare.net/shigeki_ohtsu/html5-conf2013-http2iijohtsu 更新された中でいくつかトピックスを紹介します。
- 24. HTTP/2プライオリティ クライアント Reverse Proxy コンテンツ HTML 画像 CSS, jS HTML CSS JS 画像１ 画像2 画像3 画像4 依存性と重みを指定 weight:16 weight:16 プライオリティのユースケース • ファイルタイプ(HTML/CSS/JS/画像）に応じ た返答順序の指定 • タブ切り替えによる重みの上げ下げ • 分割されたビデオデータなど順番が明示的 に決められている場合
- 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. 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の仕様を先取りしたもの
- 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. HTTP/2の応用 WebPush いろんな場面でプッシュ通知は必要 1. ブラウザ上でアプリが動作している時 • チャット等の通常のアプリ通知 2. ブラウザは立ち上げているがアプリは動作していない時 • SNSのメッセージやweb feedを受ける 3. ブラウザも立ち上げていない時 • WebRTCによる入電でウェブアプリを立ち上げる 4. １つのブラウザでアプリを複数インスタンス立ち上げてい る。又は、異なるブラウザで同一のアプリを動作させてい る。 • そのうちの１つにだけプッシュ通知したい。 • 全部にプッシュ通知をブロードキャストしたい。 • 複数アカウントでメール利用など。
- 31. HTTP/2の応用 Service Worker+ Server Push プッシュサーバ アプリケーション サーバ Webアプリの通信 ＨＴＴＰＳ必須 5. Service Worker上で Pushイベントが発生。 ArrayBuffer, blob, json, textの形式でプッシュ データを取り出せる。 2. HTTP PUTのリクエスト ボディにプッシュメッ セージを付けて送信 4. HTTP/2サーバプッシュを利用 してクライアントに通知 3. 複数アプリのプッシュ 通知をチャネルで区別し、 一つの接続上で送信 1. クライアントからプッシュサーバ名と登録IDを通知 Service Worker ウェブ アプリ ブラウザ Push API クライアント
- 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. 新プロトコル: 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. QUICデモ パケットロス耐性 QUIC vs SPDY クライアント サーバ Ajax SPDY over TCP Ajax QUIC over UDP 30%パケットロス
- 35. おわり