Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

第43回HTML5とか勉強会 SPDY/QUICデモ

3,348 views

Published on

Published in: Technology
  • Be the first to comment

第43回HTML5とか勉強会 SPDY/QUICデモ

  1. 1. HTTP/2.0がもたらす Webサービスの進化 HTTP/2.0でWebはどう進化するのか? (+SPDYデモ+ QUICも?) IIJ 大津 繁樹 2013年12月16日 第43回HTLM5とか勉強会
  2. 2. 自己紹介 • 大津繁樹 株式会社インターネットイニシアティブ(IIJ) プロダクト本部戦略的開発部 新技術の検証評価 – – – – SPDY,HTTP/2.0 HTML5 Node.js Kinect/Leap Motion
  3. 3. HTTP/2.0とは、 • HTTP/1.1 の策定(1999年)から14年。 • IETF httpbis WGで HTTP/1.1仕様改 訂の見込みがたった。 • 新しい仕様を作る動きが開始 • 従来のHTTP/1.1のセマンティクス維 持。互換性保持。 • HTTP/2.0でフレーム化、新しいシン タックスを導入。 • SPDYをアイデアにしているが、仕様 提案を一般公募して決定。 • 2014年春の仕様化完了に向けて絶 賛開発中 HTTP/1.1 Semantics HTTP/2.0 Frame Layer TLS TCP IP(v4/v6) Ethernet
  4. 4. HTTP/2.0の主な技術的な特徴 • • • • • • • クライアント・サーバのTCP接続数を1つに限定 3種類・2段階の初期接続方法(HTTP/HTTPS) バイナリープロトコル 優先度付全2重多重化通信 フロー制御(コネクション・ストリームレベル) サーバプッシュ機能 HTTPヘッダに特化したデータの圧縮手法 (HPACK) (注:青:SPDYから変更されてる項目 ,赤:SPDYの異なる項目)
  5. 5. 単純なHTTP/2.0のストリームフロー 初期ハンドシェイク (HTTP/2.0の利用を合意) HEADERS (id=0x1, END_HEADERS) HTTPリクエストヘッダ情報を送信 HEADERS (id=0x1, END_HEADERS) クライアント HTTPレスポンスヘッダ情報を送信 DATA (id=0x1, END_STREAM) HTTPレスポンスボディを送信 (ストリーム 0x1 を終了) サーバ
  6. 6. サーバプッシュ機能(予約機能) ストリーム(0x1) 予約されたリクエ ストは新しくリクエ ストしない。 HEADERS (id=0x1,index.html) PUSH_PROMISE 先読みさせるリ クエストヘッダと ストリームIDをク ライアントに予約 プロミスID: 0x2 リクエストヘッダ (/images/pic1.png) DATA(index.htmlのコンテンツ) クライアント ストリーム(0x2) サーバ HEADERS キャッシュ レスポンスヘッダ DATA レスポンスボディ サーバがコンテンツをプッシュしてクライアントにキャッシュ
  7. 7. HPACK:新しいヘッダ圧縮仕様 GET / HTTP/1.1 host: www.example.com 1. 2. 3. 4. 平均20~30%デー タ量を削減 CRIME脆弱性対応 2番の:method GETを追加 7番の:scheme http を追加 6番の :path / を追加 4番の : authority に www.example.com をハフマン符号化して追加 (ヘッダの差分情報を符号化して やり取りする) 送信前ヘッダテーブル 1. :authority, 2. :method, GET 3. :method, POST 4. :path, / 5. :path, /index.html 6. :scheme, http ・・・・ 0x82 0x87 0x86 0x04 0x8b 0 xdb 0x6d 0x88 0x3e 0x68 0xd1 0xcb 0x12 0x25 0xba 0x7f (実際に送信するヘッダ情報) 受信後ヘッダテーブル 1. :authority, www.example.com 2. :path, / 3. :scheme, http 4. :method, GET ・・・・
  8. 8. デモンストレーション#1 Server Push を見つけてみる。 • HTTP/2.0は開発中であるため、SPDYでデモン ストレーションを行います。 • SSL、SPDY, SPDY+サーバプッシュ の3通りで同 じコンテンツをアクセスしてみます。 • 違いがわかるでしょうか?
  9. 9. デモンストレーション#2 世界のナベアツで起こる HTTP Head of Line Blocking • イメージ3の倍数の数のイメージアクセスがあ るとその数番目のイメージだけレスポンスを3 秒遅延させる。 • HTTP/1.1(SSL)とSPDYの比較、どうなるでしょ う?
  10. 10. HTTP Head of Line Blocking HTTP/1.1 TCP#1 GET TCP#2 GET TCP#3 GET TCP#4 ブロックされる と次のリクエス トできない。 GET クライアント TCP#5 GET TCP#6 GET サーバ
  11. 11. HTTP Head of Line Blocking SPDY・HTTP/2.0 TCP#1 クライアント GET GET GET GET GET GET GET GET GET GET サーバ ブロックされな い
  12. 12. QUIC
  13. 13. QUICアーキテクチャ HTTP SPDY TLS 暗号化・認証 QUIC セッション確立・フロー制御 エラー訂正・輻輳制御 TCP UDP IP (IPv4/IPv6)
  14. 14. QUICの特徴 Googleの本番の全サービスで試験中 1. TLSによく似た高セキュリティ 2. TCP Fast Open と TLS Snapstart を組み合わせた ような(だいたい 0-RTTの)素早い接続 3. パケットロスを低減するパケット速度調整 4. 再送頻度を低減するパケットのエラー補正 5. TCP のHead-of-Lineブロッキング(先頭詰り)を回 避するUDPトランスポート 6. モバイルクライアントのために再接続を削減す る接続ID 7. 取り替え可能(pluggable)な輻輳制御メカニズム
  15. 15. QUICシーケンス QUICサーバー QUICクライアント (1)STREAM_FRAME(CRYPT_FRAME) 送信 (stream id =1 CHLO) udp: 80, 443 (2)STREAM_FRAME(CRYPT_FRAME) 送信 (stream id =1 SHLO) 暗号化 ハンドシェ イク (3)STREAM_FRAME送信 (stream id =奇数 SPDY SYN_STREAM) GET / HTTP/1.1 (4)STREAM_FRAME送信 (*注) (stream id =偶数 SPDY SYN_REPLY) HTTP/1.1 200 OK
  16. 16. QUIC vs SPDY (0-RTT対決) (40sec-1min後あたり) http://www.youtube.com/watch?v=F7L3VjiMjJI

×