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

2,934 views
2,733 views

Published on

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

No Downloads
Views
Total views
2,934
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
36
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

第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

×