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