HTTP/2, QUIC入門 セキュリティキャンプ2015

1. HTTP/2, QUIC入門
セキュリティキャンプ 2015
2015年8月12日
IIJ 大津 繁樹
更新版資料の置場 http://goo.gl/cX1M17

2. 自己紹介
• 大津 繁樹
• 株式会社 インターネットイニシアティブ
• プロダクト本部 アプリケーション開発部サービス開発2課
• NodeJS Technical Committee メンバー
• (主にTLS/CRYPTO/OpenSSLバインディングを担当）
• IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。
• ブログ： http://d.hatena.ne.jp/jovi0608/

3. はじめに
• HTTP/2とQUICの概要を学んでいただきます。
• HTTP/2はTLSと異なり必要となる要素技術の数は少ないです。
ですがヘッダ圧縮仕様HPACKを完全に理解しないと概要以上の
レベルの技術は見につきません。
• QUICは、TCP/TLSの技術要素の集まりです。これをきちんと理
解するには相当の努力が必要です。
• 残念ながら2時間の時間では概要以上の技術レベルを取得する
のは難しいと思われます。

4. 本講義の目的
• HTTP/2とQUICの技術的概要を知ることを目的とします。
• 概要レベル以上の技術を身につけるためHPACKについて詳細を
解説し、演習をしていただきます。
• できればHTTP/2データの解析ができるところまで目指します。
• 課題内容は空白にしています。講義当日にお知らせします。

5. 本講義の内容
• HTTP/1.1からHTTP/2へ
• HTTP/2の仕組み概要
• HPACK詳細
• HTTP/2解析
• QUIC概要
Ethernet
IP(v4/v6)
TCP
TLS
HTTP/2
Frame Layer
HTTP/1.1
Semantics

6. HTTP/1.1からHTTP/2へ

7. HTTPプロトコルの年表
1990 1995 2000 2005 2010 2015
Webの
始まり
HTTP/0.9 HTTP/1.0
RFC1945
HTTP/1.1
RFC2068
HTTP/1.1
RFC2616
HTTP/1.1
RFC7230-5
HTTP/2
RFC7540
SPDY/2
SPDY/3
SPDY/3.1
httpbis WG
暗黒の時代
HTTP-NG
中止
HPACK
RFC7541

8. HTTP/2サポート状況
http://caniuse.com/#feat=http2

9. HTTP転送サイズとリクエスト数の遷移
(2012/7/1～2015/7/1)
http://httparchive.org/trends.php?s=All&minlabel=Jul+1+2012&maxlabel=Jul+1+2015#bytesTotal&reqTotal
3年で
転送サイズ: 96%増
リクエスト数：20%増
（単一Webサイトの統計平均）

10. 回線帯域を増速していくと
0
500
1000
1500
2000
2500
3000
3500
0 2 4 6 8 10 12
HTTP経由のダウンロード時間[ms]
回線帯域[MBps]
More Bandwidth does’nt matter よりデータ引用
http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2
ページの表示時間は、
これ以上短縮できない。
Make the Web Faster: Google の試験

11. RTT(Round Trip Time)を小さくしていくと
0
500
1000
1500
2000
2500
3000
3500
4000
4500
050100150200250300
HTTP経由のダウンロード時間[ms]
RTT[ms]
ちゃんと下がる
More Bandwidth does’nt matter よりデータ引用
http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2
Webページの表示速度を速くするには、回線速度増強よりRTT（の影
響）を小さくするかが重要。でも物理的な制限で難しい。
Make the Web Faster: Google の試験

12. ＳＰＤＹ(スピーディ）の登場（2009年）
• RTTの影響をできるだけ避けるべくGoogleはSPDYを開発した。
• SPDYは、Ｗｅｂページの表示速度を速くするためのプロトコル
として当初社内プロジェクトから生まれた。
• 既に3年以上に渡りGoogleの全サービスで利用され、Twitterや
Facebook、LINEなど大規模なシステムに導入されている。
ブラウザの拡張プラ
グイン(SPDY
Indicator)を使うと
SPDYを使っている
サイトがわかる

13. HTTP/1.1の問題点のおさらい
1. HTTP Head of Line Blocking
2. ネットワーク通信の利用が非効率
3. 曖昧でテキスト処理が煩雑

14. 1. HTTP Head of Line Blocking
クライアント サーバ
HTTP/1.1
1本のTCP接続
HTTP リクエスト
HTTPレスポンス
待ち時間
HTTP リクエスト

15. HTTP/1.1
ブラウザは最大同時4～6TCP接続に制限
最大同時並列6

16. HTTP/2
100以上の同時リクエストが可能
全部同時

17. 2. HTTP/1.1はネットワーク通信の利用が非効率
クライアント サーバ
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
それぞれのTCP接続が独立して輻輳制御を行う

18. HTTP/1.1は非効率なプロトコル
0
10
20
30
40
50
60
10 15 20 25 30 35 40 45
輻輳ウィンドウサイズ(mss)
時間(sec)
HTTP/1.1+SSLの輻輳ウィンドウサイズの変遷
SSL1
SSL2
SSL3
SSL4
SSL5
SSL6
6本のTCPがバラバラに
輻輳制御。帯域を有効
に使いきれてない

19. HTTP/2(SPDY)は効率的なプロトコル
0
10
20
30
40
50
60
60 65 70 75 80 85 90 95
輻輳ウィンドウサイズ(mss)
時間(sec)
SPDY利用時の輻輳ウィンドウサイズの変遷
SPDY
1本のTCPで最高速まで利
用。帯域を最大限に効率的
に使っている。

20. 3. HTTP/1.1は処理が煩雑なテキストプロトコル
HTTP/1.1 200 OK
Content-Type: image/jpeg
Transfer-Encoding: chunked
Trailer: Foo
123
{binary data}
0
Foo: bar
Status-Lineは一行目 空白は1つ
ヘッダ名は大文字・小文
字区別せず
ヘッダ領域の区切り
はCRLF一つ
:の後に空白を許可
CRLFで改行、複数行
対応は廃止
レスポンスデータがchunkedであ
り、サイズはまだ不定
一番最後にFooヘッダが付与
されることを宣言
続くデータが123バイト
であることを宣言
データ終了の合図
Trailヘッダ
chunk終了合図
のCRLF

21. HTTP/2はきっちりしたバイナリープロトコル
00 00 00 01
01 04
00 00 1a
88 5c 82 08
・・・・・・
73 ff
00 00 00 01
00 00
00 00 7b
{binary data}
:status = 200
content-length = 123
content-type =
image/jpeg
trailer = Foo
HEADERS
DATA
フレーム長：28バイト
フレーム長：123バイト
フレームタイプ：HEADERS, END_HEADERSフラグ
ストリームID: 1
ストリームID: 1
フレームタイプ：DATA, フラグなし
(* 記載スペースの都合上Trailer HEADERSは省いています）
データの
位置・サイズ・型
が明確

22. HTTP/2の仕組み概要

23. HTTP/2の技術的な特徴
•HTTP/1.1のセマンティックスを変えない。
•サーバへのTCP接続数を１つに限定
•TLSと連携してプロトコルを自動選択
•バイナリープロトコル（テキストデータの曖昧さを排除）
•全２重多重化通信
•フロー制御、優先度指定
•サーバプッシュ機能

24. HTTP/2の技術的な特徴
• SPDYのプロトコルアーキテクチャはそのまま利用
• SPDYの無駄なヘッダフィールドやフレームタイプを統廃合
し、簡略化
• SPDYの実運用で明らかとなったフロー制御・優先度制御と
いった課題へ対応する
• TLS利用を前提とするSPDYに対し、平文接続も利用可能に
する 。
• ヘッダ圧縮脆弱性(CRIME)対策として新しくHTTPに特化し
たヘッダ送受信仕様(HPACK)を策定する

25. HTTP/2初期ニゴシエーション
3種類で2段階（その１）
あらかじめサーバがHTTP/2対応とわかって
いる場合、直接第２段階の接続方法を行う。
(DNSレコードや HTTPヘッダによるリダイレ
クト）
HTTP/1.1の接続後 Upgradeヘッダを使っ
て、HTTP/2 に接続をアップグレードす
る。
TLS接続時にALPN拡張フィールドを利用
してHTTP/2に接続を行う。(1) TLS + ALPN
(2) HTTP Upgrade
(3) 事前知識に
よるDirect接続
詳細後述
WebSocket
と一緒
詳細仕様
検討中
暗号化通信
平文通信

26. ALPN (Application Layer Protocol Negotiation)
クライアント
サーバー
1. ClientHello + ALPN拡張
2. ServerHello + ALPN拡張
サーバ側でプロトコルを決定し、通知する
h2
3. TLS 証明書・暗号化情報交換
プロトコルリストをサーバに送信
h2,spdy/3.1,http/1.1
HTTP/2で通信
TLSハンドシェイク

27. HTTP/2初期ニゴシエーション
3種類で2段階（その２）
505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
PRI * HTTP/2.0¥r¥n
¥r¥n
SM¥r¥n
¥r¥n
クライアントから謎の24byteのマジックコード
をサーバに送り、初期情報(SETTINGSフレーム
を交換する）
SETTINGS
(初期ウィンドウサイズ、ストリームの最大同時オープン数等の設定情報を含
む）
間違えてHTTP/1.1
サーバに接続した
場合は即切断され
る

28. 演習：
• http2.koulayer.com にTLS接続をして http2 のハンドシェイクの
一部を見る。
• options に {NPNProtocols: ['h2'] } を追加し、HTTP/2のコネク
ションヘッダを送信する。
• サーバから返信されたデータを hex で標準出力に出す。
// TLS接続のサンプル
var tls = require('tls');
var opts = {host: host, port: 443};
var client = tls.connect(opts, function() {
client.on('data', function(c) {
});
client.write();
};

29. HTTP/2のデータフレーム(binary)
ペイロード長(24bit)
タイプ(8bit) フラグ(8bit)
X ストリームID(31bit)
ペイロードデータ(ペイロード長bit)
タイプ フレーム種類 タイプ フレーム種類
0x00 DATA 0x05 PUSH_PROMISE
0x01 HEADERS 0x06 PING
0x02 PRIORITY 0x07 GOAWAY
0x03 RST_STREAM 0x08 WINDOW_UPDATE
0x04 SETTINGS 0x09 CONTINUATION
デフォルトは14bit(16K),
24bit(16M)まで拡張可
フレームヘッダ
9バイト

30. 演習： SETTINGS(Type:0x04)をパースする
SETTINGSフレームフォーマット
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length (24)
Type(8) Flags(8)
R Stream Identifier(31) (必ず０)
Identifier(16)
Value(32)
Identifier name
0x01 SETTINGS_HEADER_TABLE_SIZE
0x02 SETTINGS_ENABLE_PUSH
0x03 SETTINGS_MAX_CONCURRENT_STREAMS
0x04 SETTINGS_INITIAL_WINDOW_SIZE
0x05 SETTINGS_MAX_FRAME_SIZE
0x06 SETTINGS_MAX_HEADER_LIST_SIZE
前の演習でサーバから送信されたSETTINGS
フレームを解析し、フレームの各項目を
JSONで出力しなさい。

31. 演習：SETTINGS AckとSETTINGSをサー
バに送る。
• サーバから受け取った SETTINGS の返信として、フラグフィー
ルドに Ack (0x01) を付けたSETTINGSフレームをサーバに送る。
• SETTINGS Ack は、Identifier/Value は付けないのでヘッダのみ
の送信になります。
• 次にクライアントからSETTINGSをサーバに送信します。
id/valueは好きな項目を好きな値で構いません。（なしでも
可）

32. フロー制御
クライアント
サーバA
サーバB
Reverse
Proxy
高速
低速
AとBからのデータを
バランスよく返す
WINDOW_UPDATE
WINDOW_UPDATE
サーバは、Window Size が
０になったらデータ送信を
停止
Window Size
を増加させる
サーバA,B への
ウィンドウサイ
ズ更新を調整
TCPコネクション、ストリーム毎にフロー制御が可能

33. プライオリティ
クライアント Reverse
Proxy
コンテンツ
HTML
画像
CSS, js
HTML
CSS JS
画像１ 画像2 画像3 画像4
依存性と重みを指定
weight:16 weight:16
プライオリティのユースケース
• ファイルタイプ(HTML/CSS/JS/画像）に応
じた返答順序の指定
• タブ切り替えによる重みの上げ下げ
• 分割されたビデオデータなど順番が明示的
に決められている場合

34. Firefoxのプライオリティ依存機能
Stream:0x0
Stream:0x3
Leader
Stream:0x5
Unblocked
Stream:0x7
Background
weight:201 weight:1
weight:101
Stream:0xb
Follower
Stream:0x9
Speculative
weight:1
weight:1
css,js
ファイル
html,images等
その他
XHR
非同期js
明示的な
バックグラウンド
リクエスト
beacon等
大きなバック
グラウンド
リクエスト
idle
ストリーム

35. サーバプッシュ機能
コンテンツリクエスト
クライアント
サーバ
画像のHTTPリクエストを予約
コンテンツのレスポンス
画像データキャッシュ
サーバはコンテンツ
の中身を判断し，あ
らかじめコンテンツ
に含まれている画像
のリクエストを予約
する．
予約された画像リクエスト
はクライアントからサーバ
に送らずに，クライアント
はサーバ側からの画像デー
タの送付を待つ
サーバから送信され
た画像データは，ク
ライアントのキャッ
シュに保存

36. HPACK詳細

37. HPACKとは
• HTTP/2で用いられるヘッダ圧縮技術
• もともとSPDYでは gzipを使ったヘッダ圧縮を行っていたが暗
号化通信下でも情報が漏えい可能となるCRIME攻撃手法が公開
され、クライアントからサーバへのヘッダ圧縮が無効になって
いた。
• そこでHTTP/2専用でHTTPヘッダに特化した圧縮技術仕様
HPACKの開発を行った。
GET / HTTP/1.1
Host: www.google.co.jp
User-Agent: Mozilla/5.0 XXXXX
Accept: text/html,application/xhtml+xml,XXX
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

38. HTTPヘッダの特徴とHPACKの方針
• HTTPヘッダは Name Value の集まり
• HTTPヘッダは繰り返し同じデータが送られることが多い
• リクエストパスなど頻繁に変わるものもある
• クッキーなどbase64エンコーディングされているようなものも
あり、使われる文字・記号種に偏りがある
• CRIMEの脅威を避けつつ、送受信するデータ量の圧縮ができる
ようにする

39. HPACK概要
ヘッダテーブル
1. name1, value1
2. name2, value2
3. name3., value3
……
ヘッダテーブル
1. name1, value1
2. name2, value2
3. name3., value3
……
X番のエントリー(nameX, valueX)送信します。
X番のエントリーのnameXを使うけど値は別の
valueX'のヘッダを送信します。後で使うからテー
ブルに追加しておいて。
クライアント・サーバ両者でインデックス番号が付いたヘッダ
テーブルを保持。そのインデックスを参照する情報を送る。
最も圧縮ができる時は、番号を通知するだけでよくなる。

40. HPACKエンコーディング種類
種類 Indexed Header
Field
Representation
Literal Header Field Representation Dynamic Table
Size UpdateLiteral Header
Field with
Incremental
Indexing
Literal Header
Field without
Indexing
Literal Header
Field Never
Indexed
最初の1バイト 1XXXXXXX 01XXXXXX 0000XXXX 0001XXXX 001XXXXX
ヘッダテーブル
中のエントリを
参照する方式
ヘッダテーブ
ルにエントリ
を追加する方
式
ヘッダテーブル
にエントリを追
加しない方式
ヘッダテーブル
にエントリを追
加しない方式
Proxy先にも強
要させる
ヘッダテーブル
のサイズ変更
番号だけ 文字も送る 制御用

41. Header Table
index header name header value
1 :authority
2 :method GET
3 :method POST
4 :path /
5 :path /index.html
…
60 via
61 www-authenticate
62 name2 value2
63 name1 value2
…
…
Static Table(変わらない)
Literal Header Field with Incremental
Indexing はここにエントリーを追加
Dynamic Table(追加される)
ヘッダテーブルサイズ
初期値:4096バイト
エントリー追加でサイ
ズ超過したら最後のエ
ントリーを取り除く
Indexed Header
Field Representationはこの
index番号だけを参照して
ヘッダ情報を伝える。
Literal Header Fieldでnameだけがテーブル
に存在するものは、index番号を参照する。

42. HPACKはビットの世界
0 1 X X X X X
X X X X X X X
X X X X X X X
ヘッダビット(1～4bits)
種類によって変わる 中途半端なオフセットから始まるこ
こに任意のサイズの整数値や文字列
などのヘッダ情報を無駄なく入れ込
むにはどうしたらよいだろうか？
整数値の入れ込み方： Integer Representation
文字列の入れ込み方： String Literal Representation

43. Integer Representation
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1
1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7
なんかのヘッダビット ここの領域に整数を格納したい
０～2^5-1
まで大丈夫
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1 32以上はど
うする？
どうしたらここ
に桁を上げる
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1
1 1 1 1 1 1 1 1
続く前の整数表示と違うなんかのデータ
整数と続くデー
タの切れ目をど
う判断する？

44. Integer Representation
0 1 2 3 4 5 6 7
なんかのヘッダビット 1 1 1 1 1
1 1 1 1 1 1 1 1
0 0 0 1 1 1 1 1
続く前の整数表示と違うなんかのデータ
じゃどうするか？
最上位ビットは整数表示に使わない。
継続フラグ
１：次のバイトに整数表示が続く
０：このバイトで終わり
prefix length
127超で
桁上がり
種類によって prefix
lengthを指定

45. 演習：Integer Representation
• 3 bit prefix で 3 を表す
• 3 bit prefix で 10 を表す
• 3 bit prefix で 150 を表す
• 4 bit prefix の 0x04 の整数は？
• 4 bit prefix の 0x0f04 の整数は？
• 4 bit prefix の 0x0fc601 の整数は？

46. String Literal Representation
0 1 2 3 4 5 6 7
H 文字列長 (7-bit prefix)
文字列データ
Huffman符号化
をしているか
文字列長を7bit-
prefixでエン
コード
文字列長分デー
タを入れる
0 1 2 3 4 5 6 7
0 0 0 0 0 0 0 1
0 1 1 0 0 0 0 1
H:0
Huffman符号化
せず
文字列長：１
文字列： 0x61(a)
ハフマン符号化せずに一文字の a を表すと
文字列を表すには、文字列長とデータの2つが必要
文字列データの更なる圧縮のためHuffman符号化をサポート

47. Huffman符号化
• 通常データで利用される文字種や記号には偏りがある。
• 頻度情報から良く使われるものに短いビット列を割り当て、そ
うでないものに長いビットを割り当てて符号化すると統計的に
全体のデータ量を削減することができる。
文字・記号 割当ビット 長さ
a 00011 5 bits (3bits分お得)
< 111111111111100 15bits (7bits分損)

48. HPACKのHuffman符号化
• String Literal Representation中の文字列をHuffman符号化できる
様にしてデータ量を圧縮する。
• 先頭の1ビットをHuffman符号化を行っているかのフラグにする
• Google Chromeで収集したHTTPヘッダ文字種の頻度情報の統計
からHuffman木を生成し、符号を割り当てた。
https://httpwg.github.io/specs/rfc7541.html#huffman.code
• 文字列の最後がバイト境界でない場合は、EOS(All bits 1)で埋め
る。

49. Root
0
1
0
0 1
1
0
0
0 1
1
2 a
!
0
s t
0
c e
1
i o
1
1
0
%
1
- .
0
/ 3
1
4 5
0
0
6 7
1
8 9
1
0
0 1
1
0
1
0 1
0
= A
1
_ b
0
0
d f
1
g h
1
0
l m
1
n p
0
0
r u
1
1
0
: B
1
C D
1
1
1
0
0
0
0
0
1
1
10
#
HPACKのHuffman木

50. Hello!のHuffman符号化
文字 符号 符号長
! 1111111000 10
H 1100011 7
e 00101 5
l 101000 6
o 00111 5
H e l l o ! EOS
1100011 00101 101000 101000 00111 1111111000 1
40 bits
40/48=83.3 約17%削減

51. 演習： Huffman符号化
• abc をハフマン符号でエンコードしてHex文字列で出力する。
• 0x21231f をハフマン符号デコードしてみる。
文字 ascii 符号 符号長
a 0x61 00011 5
b 0x62 100011 6
c 0x63 00100 5

52. 演習： String Literal
• Huffman符号化せず abc を String Literal で表してみる。
• Huffman符号化して abc を String Literal で表してみる。
• String Literalで符号化された 0x03626164 の文字は何か？
• String Literalで符号化された 0x821C64の文字は何か？

53. Indexed Header Field Representation
0 1 2 3 4 5 6 7
1 Index (7-bit prefix)
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
Header Tableの indexの
name value 両方をその
まま使う

54. Literal Header Field with Incremental
Indexing
0 1 2 3 4 5 6 7
0 1 Index (6-bit prefix)
H Value Length (7-bit prefix)
Value Data
0 1 2 3 4 5 6 7
0 1 0
H Name Length (7-bit prefix)
Name Data
H Value Length (7-bit prefix)
Value Data
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
61 … …
62 … …
63 … …
… … …
Indexed Name
New Name
Header Tableの indexの
nameだけ使う。
ここで使われた name,
valueを62番目に挿入す
る。

55. Literal Header Field without Indexing
0 1 2 3 4 5 6 7
0 0 0 0 Index (4-bit prefix)
H Value Length (7-bit prefix)
Value Data
0 1 2 3 4 5 6 7
0 0 0 0 0
H Name Length (7-bit prefix)
Name Data
H Value Length (7-bit prefix)
Value Data
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
Indexed Name
New Name
Header Tableの indexの
nameだけ使う。
Header Tableの変更はなし

56. Literal Header Field Never Indexed
0 1 2 3 4 5 6 7
0 0 0 1 Index (4-bit prefix)
H Value Length (7-bit prefix)
Value Data
0 1 2 3 4 5 6 7
0 0 0 1 0
H Name Length (7-bit prefix)
Name Data
H Value Length (7-bit prefix)
Value Data
Header Table
index name value
1 … …
2 … …
3 … …
… … …
… … …
Indexed Name
New Name
Header Tableの変更はなし
Header Tableの indexの
nameだけ使う。

57. without IndexingとNever Indexed
• HPACKではCRIME攻撃が困難になったが完全に防げるわけではない。
• なぜならHeaderTableへのindex化によって圧縮サイズが変わり、その
情報を手掛かりに機密データの推測が理論的に可能となる。
• セキュリティ的に機密度の高いデータ(パスワード・クッキー情報）
は、ヘッダテーブルにインデックスしないことを明示的に示すため
Never Indexedが設けられた。途中でもProxyでも方式変更を禁止する。
Proxy
Never Indexed (機密的に重要)
途中で方式を変えちゃいけない
without Indexing with indexing
変えてもOK

58. Dynamic Table Size Update
0 1 2 3 4 5 6 7
0 0 1 Max Size(5-bit prefix)
Header Table
index
1
2
3
…
…
Header TableのMaxSizeを変更する。
小さくなる場合は、サイズが超えた
分エントリーを最後から削除する。
SETTINGS_HEADER_TABLE_SIZEで指定
した以下の値であること

59. 演習： HPACK
Indexed Representation
Header Table
index header name header value
1 :authority
2 :method GET
4 :path /
7 :scheme https
• 以下の３つのヘッダをIndexed Representationでエンコードし
てhex文字列で出力しなさい。
• [{name: ':method', value: 'GET'}, {name: ':path', value: '/'}, {name:
':scheme', value: 'https'}]

60. 演習： HPACK
Literal Header Field without Indexing
• [{name: ':authority', value: 'http2.koulayer.com'}] をLiteral Header
Field without Indexing(Indexed Name)でエンコードし、hex文字
列で出力しなさい。(Huffman符号化しなくてもよい）
Header Table
index header name header value
1 :authority
2 :method GET
4 :path /
7 :scheme https

61. HTTP/2 クライアントの実装

62. 演習：HTTP/2 リクエストの送信
• 前の演習で作成した[{name: ':method', value: 'GET'}, {name:
':path', value: '/'}, {name: ':scheme', value: 'https'}, {name:
':authority', value: 'http2.koulayer.com'}]] のHPACKエンコーディ
ングデータを使ってHEADERフレームを作成し、SETTING-Ack
後のサーバに送信しなさい。
HEADERSフレームフォーマット
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length (24)
Type(8)
0x01
Flags(8)
END_HEADERS (0x4)のみ
R Stream Identifier(31) (idは１を利用する)
Header Block

63. 演習： HTTP/2 レスポンスの解析
• サーバからHEADERとDATAフレームが返信されてくるので、
データを解析してJSON形式で出力しなさい。
DATAフレームフォーマット
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length (24)
Type(8)
0x00
Flags(8)
R Stream Identifier(31)
Data

64. QUIC概要

65. TCPの問題点
• TCP Head of Line Blocking.
• 3方向ハンドシェイクのコスト.
• initcwnd（初期輻輳ウィンドウ)が小さくスロースタート
• パケットロスによる大きなバックオフ（待ち時間）
• カーネルのソケットバッファの増大
• NATのタイムアウトとIPのローミング
• 経路途中のTCP Buffer Bloat
TCP Fast
Open
initCWND10
TCP cubic
Random packet
drop in router
TCP_NOT_SENT_LOWAT
解決策は提示されているが、OSや中継機の機能追加が必要
これは非常に時間がかかる。

66. TLSの問題点
• TLSのハンドシェイクネゴシエーションのコスト
• ChangeCipherSpecが来るまで待たないといけない
• 負荷分散のバグによるClientHelloのサイズ制限
• サーバから送信する証明書チェーンの肥大
• 再接続や再ネゴシエーションはコストがかかり最適化できてな
い
Ballooning
Extension
TLS Ticket, Channel
ID
TLS False Start
TLSのライブラリや中継機のバージョンアップが必要

67. SPDY
TCP HoLブロックとTCP+TLSハンドシェイク
5 4 3 1
ロス！
67
ブロック！
TCP
syn
syn+ack
ack
ClientHello
ServerHello
Certificate
Server Key Exchange
Client Key Exchange Change Cipher Spec
FInished
Application Data
TCP
ハンドシェイク
Change Cipher Spec
Finished
TLS
ハンドシェイク
SPDY SPDYSPDY SPDY
SPDYSPDY

68. 新プロトコル: QUIC
(Quic UDP Internet Connections)
IP(IPv4/IPv6)
UDP
TCP
TLS
QUIC
HTTP/2
HTTP
暗号化・認証
セッション確立、フロー制御
エラー補正, 輻輳制御
• Googleが独自に開発しているプロトコ
ル
• UDP上でTCP+TLS相当＋αの機能を実装
• 最短0-RTTで再接続、暗号通信を必須化
• TCPと同様の輻輳制御で帯域の公平化
• 独自の誤り訂正と再送機能でパケットロス
によるTCPのHead of Line Blockingを回避
• Googleの全サービスで運用中、Chrome
のフィールドテスト中(*)
• Stable版： 0.2%(Desktop), 2%(Android)
• Beta版： 25%(Desktop), 50%(Android)
(* 割合は2014/08時点のGoogleの公表値)

69. QUIC 1-RTTハンドシェイク（新規)
クライアント サーバ
CHLO (STK, VER, CCS, PDMD, SCID)
REJ(STK, SNO, SCFG)
CHLO(STK, SNO, SCID)
暗号化されたアプリデータ
Source Address Token
TLS1.3のknown_configrationに近い

70. 0-RTT (再接続)
クライアント サーバ
CHLO(STK, SNO, SCID)
暗号化されたアプリデータ
Source Address Token
TLS1.3のknown_configrationに近い

71. 演習：QUIC