第43回html5とか勉強会 spdy/quicデモ
TRANSCRIPT
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接続数を１つに限定
• 3種類・2段階の初期接続方法(HTTP/HTTPS)
• バイナリープロトコル
• 優先度付全２重多重化通信
• フロー制御(コネクション・ストリームレベル）
• サーバプッシュ機能
• 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: 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の比較、どうなるでしょう？
ＨＴＴＰ 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
ブロックされると次のリクエストできない。
ＨＴＴＰ Head of Line Blocking ＳＰＤＹ・HTTP/2.0
クライアント サーバ
TCP#1
GET
GET
GET
GET
GET
GET
GET
GET ブロックされな
い
GET
GET
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サーバー
（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