Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
HTTP/2, QUIC入門
セキュリティキャンプ 2015
2015年8月12日
IIJ 大津 繁樹
更新版資料の置場 http://goo.gl/cX1M17
自己紹介
• 大津 繁樹
• 株式会社 インターネットイニシアティブ
• プロダクト本部 アプリケーション開発部サービス開発2課
• NodeJS Technical Committee メンバー
• (主にTLS/CRYPTO/OpenSSL...
はじめに
• HTTP/2とQUICの概要を学んでいただきます。
• HTTP/2はTLSと異なり必要となる要素技術の数は少ないです。
ですがヘッダ圧縮仕様HPACKを完全に理解しないと概要以上の
レベルの技術は見につきません。
• QUICは...
本講義の目的
• HTTP/2とQUICの技術的概要を知ることを目的とします。
• 概要レベル以上の技術を身につけるためHPACKについて詳細を
解説し、演習をしていただきます。
• できればHTTP/2データの解析ができるところまで目指します...
本講義の内容
• HTTP/1.1からHTTP/2へ
• HTTP/2の仕組み概要
• HPACK詳細
• HTTP/2解析
• QUIC概要
Ethernet
IP(v4/v6)
TCP
TLS
HTTP/2
Frame Layer
HTTP...
HTTP/1.1からHTTP/2へ
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
R...
HTTP/2サポート状況
http://caniuse.com/#feat=http2
HTTP転送サイズとリクエスト数の遷移
(2012/7/1~2015/7/1)
http://httparchive.org/trends.php?s=All&minlabel=Jul+1+2012&maxlabel=Jul+1+2015#by...
回線帯域を増速していくと
0
500
1000
1500
2000
2500
3000
3500
0 2 4 6 8 10 12
HTTP経由のダウンロード時間[ms]
回線帯域[MBps]
More Bandwidth does’nt mat...
RTT(Round Trip Time)を小さくしていくと
0
500
1000
1500
2000
2500
3000
3500
4000
4500
050100150200250300
HTTP経由のダウンロード時間[ms]
RTT[ms]...
SPDY(スピーディ)の登場(2009年)
• RTTの影響をできるだけ避けるべくGoogleはSPDYを開発した。
• SPDYは、Webページの表示速度を速くするためのプロトコル
として当初社内プロジェクトから生まれた。
• 既に3年以上に...
HTTP/1.1の問題点のおさらい
1. HTTP Head of Line Blocking
2. ネットワーク通信の利用が非効率
3. 曖昧でテキスト処理が煩雑
1. HTTP Head of Line Blocking
クライアント サーバ
HTTP/1.1
1本のTCP接続
HTTP リクエスト
HTTPレスポンス
待ち時間
HTTP リクエスト
HTTP/1.1
ブラウザは最大同時4~6TCP接続に制限
最大同時並列6
HTTP/2
100以上の同時リクエストが可能
全部同時
2. HTTP/1.1はネットワーク通信の利用が非効率
クライアント サーバ
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
TCP接続
それぞれのTCP接続が独立して輻輳制御を行う
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
SSL...
HTTP/2(SPDY)は効率的なプロトコル
0
10
20
30
40
50
60
60 65 70 75 80 85 90 95
輻輳ウィンドウサイズ(mss)
時間(sec)
SPDY利用時の輻輳ウィンドウサイズの変遷
SPDY
1本のT...
3. HTTP/1.1は処理が煩雑なテキストプロトコル
HTTP/1.1 200 OK
Content-Type: image/jpeg
Transfer-Encoding: chunked
Trailer: Foo
123
{binary d...
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}
:stat...
HTTP/2の仕組み概要
HTTP/2の技術的な特徴
•HTTP/1.1のセマンティックスを変えない。
•サーバへのTCP接続数を1つに限定
•TLSと連携してプロトコルを自動選択
•バイナリープロトコル(テキストデータの曖昧さを排除)
•全2重多重化通信
•フロー制御...
HTTP/2の技術的な特徴
• SPDYのプロトコルアーキテクチャはそのまま利用
• SPDYの無駄なヘッダフィールドやフレームタイプを統廃合
し、簡略化
• SPDYの実運用で明らかとなったフロー制御・優先度制御と
いった課題へ対応する
• ...
HTTP/2初期ニゴシエーション
3種類で2段階(その1)
あらかじめサーバがHTTP/2対応とわかって
いる場合、直接第2段階の接続方法を行う。
(DNSレコードや HTTPヘッダによるリダイレ
クト)
HTTP/1.1の接続後 Upgrad...
ALPN (Application Layer Protocol Negotiation)
クライアント
サーバー
1. ClientHello + ALPN拡張
2. ServerHello + ALPN拡張
サーバ側でプロトコルを決定し、通...
HTTP/2初期ニゴシエーション
3種類で2段階(その2)
505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
PRI * HTTP/2.0¥r¥n
¥r¥n
SM¥r¥n
¥r¥n
クライアントか...
演習:
• http2.koulayer.com にTLS接続をして http2 のハンドシェイクの
一部を見る。
• options に {NPNProtocols: ['h2'] } を追加し、HTTP/2のコネク
ションヘッダを送信する。...
HTTP/2のデータフレーム(binary)
ペイロード長(24bit)
タイプ(8bit) フラグ(8bit)
X ストリームID(31bit)
ペイロードデータ(ペイロード長bit)
タイプ フレーム種類 タイプ フレーム種類
0x00 D...
演習: 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 (2...
演習:SETTINGS AckとSETTINGSをサー
バに送る。
• サーバから受け取った SETTINGS の返信として、フラグフィー
ルドに Ack (0x01) を付けたSETTINGSフレームをサーバに送る。
• SETTINGS A...
フロー制御
クライアント
サーバA
サーバB
Reverse
Proxy
高速
低速
AとBからのデータを
バランスよく返す
WINDOW_UPDATE
WINDOW_UPDATE
サーバは、Window Size が
0になったらデータ送信を...
プライオリティ
クライアント Reverse
Proxy
コンテンツ
HTML
画像
CSS, js
HTML
CSS JS
画像1 画像2 画像3 画像4
依存性と重みを指定
weight:16 weight:16
プライオリティのユースケー...
Firefoxのプライオリティ依存機能
Stream:0x0
Stream:0x3
Leader
Stream:0x5
Unblocked
Stream:0x7
Background
weight:201 weight:1
weight:101...
サーバプッシュ機能
コンテンツリクエスト
クライアント
サーバ
画像のHTTPリクエストを予約
コンテンツのレスポンス
画像データキャッシュ
サーバはコンテンツ
の中身を判断し,あ
らかじめコンテンツ
に含まれている画像
のリクエストを予約
す...
HPACK詳細
HPACKとは
• HTTP/2で用いられるヘッダ圧縮技術
• もともとSPDYでは gzipを使ったヘッダ圧縮を行っていたが暗
号化通信下でも情報が漏えい可能となるCRIME攻撃手法が公開
され、クライアントからサーバへのヘッダ圧縮が無効にな...
HTTPヘッダの特徴とHPACKの方針
• HTTPヘッダは Name Value の集まり
• HTTPヘッダは繰り返し同じデータが送られることが多い
• リクエストパスなど頻繁に変わるものもある
• クッキーなどbase64エンコーディング...
HPACK概要
ヘッダテーブル
1. name1, value1
2. name2, value2
3. name3., value3
……
ヘッダテーブル
1. name1, value1
2. name2, value2
3. name3....
HPACKエンコーディング種類
種類 Indexed Header
Field
Representation
Literal Header Field Representation Dynamic Table
Size UpdateLitera...
Header Table
index header name header value
1 :authority
2 :method GET
3 :method POST
4 :path /
5 :path /index.html
…
60 v...
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
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
なんかのヘッダビット ここの領域に整数を格納したい
0~2^...
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
続く前の整数表示と違うなんかのデータ
じゃどうするか?
最上...
演習:Integer Representation
• 3 bit prefix で 3 を表す
• 3 bit prefix で 10 を表す
• 3 bit prefix で 150 を表す
• 4 bit prefix の 0x04 の整...
String Literal Representation
0 1 2 3 4 5 6 7
H 文字列長 (7-bit prefix)
文字列データ
Huffman符号化
をしているか
文字列長を7bit-
prefixでエン
コード
文字列長...
Huffman符号化
• 通常データで利用される文字種や記号には偏りがある。
• 頻度情報から良く使われるものに短いビット列を割り当て、そ
うでないものに長いビットを割り当てて符号化すると統計的に
全体のデータ量を削減することができる。
文字・...
HPACKのHuffman符号化
• String Literal Representation中の文字列をHuffman符号化できる
様にしてデータ量を圧縮する。
• 先頭の1ビットをHuffman符号化を行っているかのフラグにする
• Go...
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...
Hello!のHuffman符号化
文字 符号 符号長
! 1111111000 10
H 1100011 7
e 00101 5
l 101000 6
o 00111 5
H e l l o ! EOS
1100011 00101 10100...
演習: Huffman符号化
• abc をハフマン符号でエンコードしてHex文字列で出力する。
• 0x21231f をハフマン符号デコードしてみる。
文字 ascii 符号 符号長
a 0x61 00011 5
b 0x62 100011 ...
演習: String Literal
• Huffman符号化せず abc を String Literal で表してみる。
• Huffman符号化して abc を String Literal で表してみる。
• String Litera...
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 … …...
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)
Valu...
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 Dat...
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...
without IndexingとNever Indexed
• HPACKではCRIME攻撃が困難になったが完全に防げるわけではない。
• なぜならHeaderTableへのindex化によって圧縮サイズが変わり、その
情報を手掛かりに機密デ...
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を変...
演習: HPACK
Indexed Representation
Header Table
index header name header value
1 :authority
2 :method GET
4 :path /
7 :schem...
演習: HPACK
Literal Header Field without Indexing
• [{name: ':authority', value: 'http2.koulayer.com'}] をLiteral Header
Fiel...
HTTP/2 クライアントの実装
演習:HTTP/2 リクエストの送信
• 前の演習で作成した[{name: ':method', value: 'GET'}, {name:
':path', value: '/'}, {name: ':scheme', value: 'htt...
演習: HTTP/2 レスポンスの解析
• サーバからHEADERとDATAフレームが返信されてくるので、
データを解析してJSON形式で出力しなさい。
DATAフレームフォーマット
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 ...
QUIC概要
TCPの問題点
• TCP Head of Line Blocking.
• 3方向ハンドシェイクのコスト.
• initcwnd(初期輻輳ウィンドウ)が小さくスロースタート
• パケットロスによる大きなバックオフ(待ち時間)
• カーネルのソ...
TLSの問題点
• TLSのハンドシェイクネゴシエーションのコスト
• ChangeCipherSpecが来るまで待たないといけない
• 負荷分散のバグによるClientHelloのサイズ制限
• サーバから送信する証明書チェーンの肥大
• 再...
SPDY
TCP HoLブロックとTCP+TLSハンドシェイク
5 4 3 1
ロス!
67
ブロック!
TCP
syn
syn+ack
ack
ClientHello
ServerHello
Certificate
Server Key Ex...
新プロトコル: QUIC
(Quic UDP Internet Connections)
IP(IPv4/IPv6)
UDP
TCP
TLS
QUIC
HTTP/2
HTTP
暗号化・認証
セッション確立、フロー制御
エラー補正, 輻輳制御
•...
QUIC 1-RTTハンドシェイク(新規)
クライアント サーバ
CHLO (STK, VER, CCS, PDMD, SCID)
REJ(STK, SNO, SCFG)
CHLO(STK, SNO, SCID)
暗号化されたアプリデータ
So...
0-RTT (再接続)
クライアント サーバ
CHLO(STK, SNO, SCID)
暗号化されたアプリデータ
Source Address Token
TLS1.3のknown_configrationに近い
演習:QUIC
Upcoming SlideShare
Loading in …5
×

HTTP/2, QUIC入門

42,197 views

Published on

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

Published in: Technology
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

HTTP/2, QUIC入門

  1. 1. HTTP/2, QUIC入門 セキュリティキャンプ 2015 2015年8月12日 IIJ 大津 繁樹 更新版資料の置場 http://goo.gl/cX1M17
  2. 2. 自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ • プロダクト本部 アプリケーション開発部サービス開発2課 • NodeJS Technical Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当) • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。 • ブログ: http://d.hatena.ne.jp/jovi0608/
  3. 3. はじめに • HTTP/2とQUICの概要を学んでいただきます。 • HTTP/2はTLSと異なり必要となる要素技術の数は少ないです。 ですがヘッダ圧縮仕様HPACKを完全に理解しないと概要以上の レベルの技術は見につきません。 • QUICは、TCP/TLSの技術要素の集まりです。これをきちんと理 解するには相当の努力が必要です。 • 残念ながら2時間の時間では概要以上の技術レベルを取得する のは難しいと思われます。
  4. 4. 本講義の目的 • HTTP/2とQUICの技術的概要を知ることを目的とします。 • 概要レベル以上の技術を身につけるためHPACKについて詳細を 解説し、演習をしていただきます。 • できればHTTP/2データの解析ができるところまで目指します。 • 課題内容は空白にしています。講義当日にお知らせします。
  5. 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. 6. HTTP/1.1からHTTP/2へ
  7. 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. 8. HTTP/2サポート状況 http://caniuse.com/#feat=http2
  9. 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. 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. 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. 12. SPDY(スピーディ)の登場(2009年) • RTTの影響をできるだけ避けるべくGoogleはSPDYを開発した。 • SPDYは、Webページの表示速度を速くするためのプロトコル として当初社内プロジェクトから生まれた。 • 既に3年以上に渡りGoogleの全サービスで利用され、Twitterや Facebook、LINEなど大規模なシステムに導入されている。 ブラウザの拡張プラ グイン(SPDY Indicator)を使うと SPDYを使っている サイトがわかる
  13. 13. HTTP/1.1の問題点のおさらい 1. HTTP Head of Line Blocking 2. ネットワーク通信の利用が非効率 3. 曖昧でテキスト処理が煩雑
  14. 14. 1. HTTP Head of Line Blocking クライアント サーバ HTTP/1.1 1本のTCP接続 HTTP リクエスト HTTPレスポンス 待ち時間 HTTP リクエスト
  15. 15. HTTP/1.1 ブラウザは最大同時4~6TCP接続に制限 最大同時並列6
  16. 16. HTTP/2 100以上の同時リクエストが可能 全部同時
  17. 17. 2. HTTP/1.1はネットワーク通信の利用が非効率 クライアント サーバ TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 TCP接続 それぞれのTCP接続が独立して輻輳制御を行う
  18. 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. 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. 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. 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. 22. HTTP/2の仕組み概要
  23. 23. HTTP/2の技術的な特徴 •HTTP/1.1のセマンティックスを変えない。 •サーバへのTCP接続数を1つに限定 •TLSと連携してプロトコルを自動選択 •バイナリープロトコル(テキストデータの曖昧さを排除) •全2重多重化通信 •フロー制御、優先度指定 •サーバプッシュ機能
  24. 24. HTTP/2の技術的な特徴 • SPDYのプロトコルアーキテクチャはそのまま利用 • SPDYの無駄なヘッダフィールドやフレームタイプを統廃合 し、簡略化 • SPDYの実運用で明らかとなったフロー制御・優先度制御と いった課題へ対応する • TLS利用を前提とするSPDYに対し、平文接続も利用可能に する 。 • ヘッダ圧縮脆弱性(CRIME)対策として新しくHTTPに特化し たヘッダ送受信仕様(HPACK)を策定する
  25. 25. HTTP/2初期ニゴシエーション 3種類で2段階(その1) あらかじめサーバがHTTP/2対応とわかって いる場合、直接第2段階の接続方法を行う。 (DNSレコードや HTTPヘッダによるリダイレ クト) HTTP/1.1の接続後 Upgradeヘッダを使っ て、HTTP/2 に接続をアップグレードす る。 TLS接続時にALPN拡張フィールドを利用 してHTTP/2に接続を行う。(1) TLS + ALPN (2) HTTP Upgrade (3) 事前知識に よるDirect接続 詳細後述 WebSocket と一緒 詳細仕様 検討中 暗号化通信 平文通信
  26. 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. 27. HTTP/2初期ニゴシエーション 3種類で2段階(その2) 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a PRI * HTTP/2.0¥r¥n ¥r¥n SM¥r¥n ¥r¥n クライアントから謎の24byteのマジックコード をサーバに送り、初期情報(SETTINGSフレーム を交換する) SETTINGS (初期ウィンドウサイズ、ストリームの最大同時オープン数等の設定情報を含 む) 間違えてHTTP/1.1 サーバに接続した 場合は即切断され る
  28. 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. 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. 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) (必ず0) 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. 31. 演習:SETTINGS AckとSETTINGSをサー バに送る。 • サーバから受け取った SETTINGS の返信として、フラグフィー ルドに Ack (0x01) を付けたSETTINGSフレームをサーバに送る。 • SETTINGS Ack は、Identifier/Value は付けないのでヘッダのみ の送信になります。 • 次にクライアントからSETTINGSをサーバに送信します。 id/valueは好きな項目を好きな値で構いません。(なしでも 可)
  32. 32. フロー制御 クライアント サーバA サーバB Reverse Proxy 高速 低速 AとBからのデータを バランスよく返す WINDOW_UPDATE WINDOW_UPDATE サーバは、Window Size が 0になったらデータ送信を 停止 Window Size を増加させる サーバA,B への ウィンドウサイ ズ更新を調整 TCPコネクション、ストリーム毎にフロー制御が可能
  33. 33. プライオリティ クライアント Reverse Proxy コンテンツ HTML 画像 CSS, js HTML CSS JS 画像1 画像2 画像3 画像4 依存性と重みを指定 weight:16 weight:16 プライオリティのユースケース • ファイルタイプ(HTML/CSS/JS/画像)に応 じた返答順序の指定 • タブ切り替えによる重みの上げ下げ • 分割されたビデオデータなど順番が明示的 に決められている場合
  34. 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. 35. サーバプッシュ機能 コンテンツリクエスト クライアント サーバ 画像のHTTPリクエストを予約 コンテンツのレスポンス 画像データキャッシュ サーバはコンテンツ の中身を判断し,あ らかじめコンテンツ に含まれている画像 のリクエストを予約 する. 予約された画像リクエスト はクライアントからサーバ に送らずに,クライアント はサーバ側からの画像デー タの送付を待つ サーバから送信され た画像データは,ク ライアントのキャッ シュに保存
  36. 36. HPACK詳細
  37. 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. 38. HTTPヘッダの特徴とHPACKの方針 • HTTPヘッダは Name Value の集まり • HTTPヘッダは繰り返し同じデータが送られることが多い • リクエストパスなど頻繁に変わるものもある • クッキーなどbase64エンコーディングされているようなものも あり、使われる文字・記号種に偏りがある • CRIMEの脅威を避けつつ、送受信するデータ量の圧縮ができる ようにする
  39. 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. 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. 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. 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. 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 なんかのヘッダビット ここの領域に整数を格納したい 0~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. 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 続く前の整数表示と違うなんかのデータ じゃどうするか? 最上位ビットは整数表示に使わない。 継続フラグ 1:次のバイトに整数表示が続く 0:このバイトで終わり prefix length 127超で 桁上がり 種類によって prefix lengthを指定
  45. 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. 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符号化 せず 文字列長:1 文字列: 0x61(a) ハフマン符号化せずに一文字の a を表すと 文字列を表すには、文字列長とデータの2つが必要 文字列データの更なる圧縮のためHuffman符号化をサポート
  47. 47. Huffman符号化 • 通常データで利用される文字種や記号には偏りがある。 • 頻度情報から良く使われるものに短いビット列を割り当て、そ うでないものに長いビットを割り当てて符号化すると統計的に 全体のデータ量を削減することができる。 文字・記号 割当ビット 長さ a 00011 5 bits (3bits分お得) < 111111111111100 15bits (7bits分損)
  48. 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. 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. 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. 51. 演習: Huffman符号化 • abc をハフマン符号でエンコードしてHex文字列で出力する。 • 0x21231f をハフマン符号デコードしてみる。 文字 ascii 符号 符号長 a 0x61 00011 5 b 0x62 100011 6 c 0x63 00100 5
  52. 52. 演習: String Literal • Huffman符号化せず abc を String Literal で表してみる。 • Huffman符号化して abc を String Literal で表してみる。 • String Literalで符号化された 0x03626164 の文字は何か? • String Literalで符号化された 0x821C64の文字は何か?
  53. 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. 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. 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. 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. 57. without IndexingとNever Indexed • HPACKではCRIME攻撃が困難になったが完全に防げるわけではない。 • なぜならHeaderTableへのindex化によって圧縮サイズが変わり、その 情報を手掛かりに機密データの推測が理論的に可能となる。 • セキュリティ的に機密度の高いデータ(パスワード・クッキー情報) は、ヘッダテーブルにインデックスしないことを明示的に示すため Never Indexedが設けられた。途中でもProxyでも方式変更を禁止する。 Proxy Never Indexed (機密的に重要) 途中で方式を変えちゃいけない without Indexing with indexing 変えてもOK
  58. 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. 59. 演習: HPACK Indexed Representation Header Table index header name header value 1 :authority 2 :method GET 4 :path / 7 :scheme https • 以下の3つのヘッダをIndexed Representationでエンコードし てhex文字列で出力しなさい。 • [{name: ':method', value: 'GET'}, {name: ':path', value: '/'}, {name: ':scheme', value: 'https'}]
  60. 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. 61. HTTP/2 クライアントの実装
  62. 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は1を利用する) Header Block
  63. 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. 64. QUIC概要
  65. 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. 66. TLSの問題点 • TLSのハンドシェイクネゴシエーションのコスト • ChangeCipherSpecが来るまで待たないといけない • 負荷分散のバグによるClientHelloのサイズ制限 • サーバから送信する証明書チェーンの肥大 • 再接続や再ネゴシエーションはコストがかかり最適化できてな い Ballooning Extension TLS Ticket, Channel ID TLS False Start TLSのライブラリや中継機のバージョンアップが必要
  67. 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. 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. 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. 70. 0-RTT (再接続) クライアント サーバ CHLO(STK, SNO, SCID) 暗号化されたアプリデータ Source Address Token TLS1.3のknown_configrationに近い
  71. 71. 演習:QUIC

×