1. HTTP/2.0がもたらす
Webサービスの進化
HTTP/2.0でWebはどう進化するのか？
（+SPDYデモ+ QUICも？）
IIJ 大津 繁樹
2013年12月16日
第43回HTLM5とか勉強会

2. 自己紹介
• 大津繁樹
株式会社インターネットイニシアティブ(IIJ)
プロダクト本部戦略的開発部
新技術の検証評価
–
–
–
–
SPDY,HTTP/2.0
HTML5
Node.js
Kinect/Leap Motion

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. HTTP/2.0の主な技術的な特徴
•
•
•
•
•
•
•
クライアント・サーバのTCP接続数を１つに限定
3種類・2段階の初期接続方法(HTTP/HTTPS)
バイナリープロトコル
優先度付全２重多重化通信
フロー制御(コネクション・ストリームレベル）
サーバプッシュ機能
HTTPヘッダに特化したデータの圧縮手法
(HPACK)
（注：青：SPDYから変更されてる項目
,赤:SPDYの異なる項目）

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. サーバプッシュ機能（予約機能）
ストリーム(0x1)
予約されたリクエ
ストは新しくリクエ
ストしない。
HEADERS (id=0x1,index.html)
PUSH_PROMISE
先読みさせるリ
クエストヘッダと
ストリームＩＤをク
ライアントに予約
プロミスID: 0x2
リクエストヘッダ
(/images/pic1.png)
DATA(index.htmlのコンテンツ）
クライアント
ストリーム(0x2)
サーバ
HEADERS
キャッシュ
レスポンスヘッダ
DATA
レスポンスボディ
サーバがコンテンツをプッシュしてクライアントにキャッシュ

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. デモンストレーション#1
Server Push を見つけてみる。
• HTTP/2.0は開発中であるため、SPDYでデモン
ストレーションを行います。
• SSL、SPDY, SPDY+サーバプッシュ の3通りで同
じコンテンツをアクセスしてみます。
• 違いがわかるでしょうか？

9. デモンストレーション#2
世界のナベアツで起こる
HTTP Head of Line Blocking
• イメージ3の倍数の数のイメージアクセスがあ
るとその数番目のイメージだけレスポンスを3
秒遅延させる。
• HTTP/1.1(SSL)とSPDYの比較、どうなるでしょ
う？

10. ＨＴＴＰ 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. ＨＴＴＰ Head of Line Blocking
ＳＰＤＹ・HTTP/2.0
TCP#1
クライアント
GET
GET
GET
GET
GET
GET
GET
GET
GET
GET
サーバ
ブロックされな
い

12. QUIC

13. ＱＵＩＣアーキテクチャ
HTTP
SPDY
TLS
暗号化・認証
QUIC
セッション確立・フロー制御
エラー訂正・輻輳制御
TCP
UDP
IP
（IPv4/IPv6)

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. ＱＵＩＣシーケンス
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. QUIC vs SPDY (0-RTT対決)
(40sec-1min後あたり）
http://www.youtube.com/watch?v=F7L3VjiMjJI