SlideShare a Scribd company logo

HTTP/2, QUIC入門

•
•
S
shigeki_ohtsu

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

1 of 71
Downloaded 190 times
HTTP/2, QUIC入門 セキュリティキャンプ 2015 2015年8月12日 IIJ 大津 繁樹 更新版資料の置場 http://goo.gl/cX1M17
自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ • プロダクト本部 アプリケーション開発部サービス開発2課 • NodeJS Technical Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当） • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。 • ブログ： http://d.hatena.ne.jp/jovi0608/
はじめに • HTTP/2とQUICの概要を学んでいただきます。 • HTTP/2はTLSと異なり必要となる要素技術の数は少ないです。 ですがヘッダ圧縮仕様HPACKを完全に理解しないと概要以上の レベルの技術は見につきません。 • QUICは、TCP/TLSの技術要素の集まりです。これをきちんと理 解するには相当の努力が必要です。 • 残念ながら2時間の時間では概要以上の技術レベルを取得する のは難しいと思われます。
本講義の目的 • 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/1.1 Semantics
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 RFC7230-5 HTTP/2 RFC7540 SPDY/2 SPDY/3 SPDY/3.1 httpbis WG 暗黒の時代 HTTP-NG 中止 HPACK RFC7541
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#bytesTotal&reqTotal 3年で 転送サイズ: 96%増 リクエスト数：20%増 （単一Webサイトの統計平均）
回線帯域を増速していくと 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 の試験
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 の試験
ＳＰＤＹ(スピーディ）の登場（2009年） • RTTの影響をできるだけ避けるべくGoogleはSPDYを開発した。 • SPDYは、Ｗｅｂページの表示速度を速くするためのプロトコル として当初社内プロジェクトから生まれた。 • 既に3年以上に渡りGoogleの全サービスで利用され、Twitterや Facebook、LINEなど大規模なシステムに導入されている。 ブラウザの拡張プラ グイン(SPDY Indicator)を使うと SPDYを使っている サイトがわかる
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 SSL2 SSL3 SSL4 SSL5 SSL6 6本のTCPがバラバラに 輻輳制御。帯域を有効 に使いきれてない
HTTP/2(SPDY)は効率的なプロトコル 0 10 20 30 40 50 60 60 65 70 75 80 85 90 95 輻輳ウィンドウサイズ(mss) 時間(sec) SPDY利用時の輻輳ウィンドウサイズの変遷 SPDY 1本のTCPで最高速まで利 用。帯域を最大限に効率的 に使っている。
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
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は省いています） データの 位置・サイズ・型 が明確
HTTP/2の仕組み概要
HTTP/2の技術的な特徴 •HTTP/1.1のセマンティックスを変えない。 •サーバへのTCP接続数を１つに限定 •TLSと連携してプロトコルを自動選択 •バイナリープロトコル（テキストデータの曖昧さを排除） •全２重多重化通信 •フロー制御、優先度指定 •サーバプッシュ機能
HTTP/2の技術的な特徴 • SPDYのプロトコルアーキテクチャはそのまま利用 • SPDYの無駄なヘッダフィールドやフレームタイプを統廃合 し、簡略化 • SPDYの実運用で明らかとなったフロー制御・優先度制御と いった課題へ対応する • TLS利用を前提とするSPDYに対し、平文接続も利用可能に する 。 • ヘッダ圧縮脆弱性(CRIME)対策として新しくHTTPに特化し たヘッダ送受信仕様(HPACK)を策定する
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 と一緒 詳細仕様 検討中 暗号化通信 平文通信
ALPN (Application Layer Protocol Negotiation) クライアント サーバー 1. ClientHello + ALPN拡張 2. ServerHello + ALPN拡張 サーバ側でプロトコルを決定し、通知する h2 3. TLS 証明書・暗号化情報交換 プロトコルリストをサーバに送信 h2,spdy/3.1,http/1.1 HTTP/2で通信 TLSハンドシェイク
HTTP/2初期ニゴシエーション 3種類で2段階（その２） 505249202a20485454502f322e300d0a0d0a534d0d0a0d0a PRI * HTTP/2.0¥r¥n ¥r¥n SM¥r¥n ¥r¥n クライアントから謎の24byteのマジックコード をサーバに送り、初期情報(SETTINGSフレーム を交換する） SETTINGS (初期ウィンドウサイズ、ストリームの最大同時オープン数等の設定情報を含 む） 間違えてHTTP/1.1 サーバに接続した 場合は即切断され る
演習： • 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(); };
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バイト
演習： 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で出力しなさい。
演習：SETTINGS AckとSETTINGSをサー バに送る。 • サーバから受け取った SETTINGS の返信として、フラグフィー ルドに Ack (0x01) を付けたSETTINGSフレームをサーバに送る。 • SETTINGS Ack は、Identifier/Value は付けないのでヘッダのみ の送信になります。 • 次にクライアントからSETTINGSをサーバに送信します。 id/valueは好きな項目を好きな値で構いません。（なしでも 可）
フロー制御 クライアント サーバA サーバB Reverse Proxy 高速 低速 AとBからのデータを バランスよく返す WINDOW_UPDATE WINDOW_UPDATE サーバは、Window Size が ０になったらデータ送信を 停止 Window Size を増加させる サーバA,B への ウィンドウサイ ズ更新を調整 TCPコネクション、ストリーム毎にフロー制御が可能
プライオリティ クライアント Reverse Proxy コンテンツ HTML 画像 CSS, js HTML CSS JS 画像１ 画像2 画像3 画像4 依存性と重みを指定 weight:16 weight:16 プライオリティのユースケース • ファイルタイプ(HTML/CSS/JS/画像）に応 じた返答順序の指定 • タブ切り替えによる重みの上げ下げ • 分割されたビデオデータなど順番が明示的 に決められている場合
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 ストリーム
サーバプッシュ機能 コンテンツリクエスト クライアント サーバ 画像のHTTPリクエストを予約 コンテンツのレスポンス 画像データキャッシュ サーバはコンテンツ の中身を判断し，あ らかじめコンテンツ に含まれている画像 のリクエストを予約 する． 予約された画像リクエスト はクライアントからサーバ に送らずに，クライアント はサーバ側からの画像デー タの送付を待つ サーバから送信され た画像データは，ク ライアントのキャッ シュに保存
HPACK詳細
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
HTTPヘッダの特徴とHPACKの方針 • HTTPヘッダは Name Value の集まり • HTTPヘッダは繰り返し同じデータが送られることが多い • リクエストパスなど頻繁に変わるものもある • クッキーなどbase64エンコーディングされているようなものも あり、使われる文字・記号種に偏りがある • CRIMEの脅威を避けつつ、送受信するデータ量の圧縮ができる ようにする
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'のヘッダを送信します。後で使うからテー ブルに追加しておいて。 クライアント・サーバ両者でインデックス番号が付いたヘッダ テーブルを保持。そのインデックスを参照する情報を送る。 最も圧縮ができる時は、番号を通知するだけでよくなる。
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先にも強 要させる ヘッダテーブル のサイズ変更 番号だけ 文字も送る 制御用
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番号を参照する。
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
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 続く前の整数表示と違うなんかのデータ 整数と続くデー タの切れ目をど う判断する？
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を指定
演習：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 の整数は？
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符号化をサポート
Huffman符号化 • 通常データで利用される文字種や記号には偏りがある。 • 頻度情報から良く使われるものに短いビット列を割り当て、そ うでないものに長いビットを割り当てて符号化すると統計的に 全体のデータ量を削減することができる。 文字・記号 割当ビット 長さ a 00011 5 bits (3bits分お得) < 111111111111100 15bits (7bits分損)
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)で埋め る。
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木
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%削減
演習： Huffman符号化 • abc をハフマン符号でエンコードしてHex文字列で出力する。 • 0x21231f をハフマン符号デコードしてみる。 文字 ascii 符号 符号長 a 0x61 00011 5 b 0x62 100011 6 c 0x63 00100 5
演習： String Literal • Huffman符号化せず abc を String Literal で表してみる。 • Huffman符号化して abc を String Literal で表してみる。 • String Literalで符号化された 0x03626164 の文字は何か？ • String Literalで符号化された 0x821C64の文字は何か？
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 両方をその まま使う
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番目に挿入す る。
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の変更はなし
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だけ使う。
without IndexingとNever Indexed • HPACKではCRIME攻撃が困難になったが完全に防げるわけではない。 • なぜならHeaderTableへのindex化によって圧縮サイズが変わり、その 情報を手掛かりに機密データの推測が理論的に可能となる。 • セキュリティ的に機密度の高いデータ(パスワード・クッキー情報） は、ヘッダテーブルにインデックスしないことを明示的に示すため Never Indexedが設けられた。途中でもProxyでも方式変更を禁止する。 Proxy Never Indexed (機密的に重要) 途中で方式を変えちゃいけない without Indexing with indexing 変えてもOK
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で指定 した以下の値であること
演習： 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'}]
演習： 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
HTTP/2 クライアントの実装
演習：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
演習： 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
QUIC概要
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や中継機の機能追加が必要 これは非常に時間がかかる。
TLSの問題点 • TLSのハンドシェイクネゴシエーションのコスト • ChangeCipherSpecが来るまで待たないといけない • 負荷分散のバグによるClientHelloのサイズ制限 • サーバから送信する証明書チェーンの肥大 • 再接続や再ネゴシエーションはコストがかかり最適化できてな い Ballooning Extension TLS Ticket, Channel ID TLS False Start TLSのライブラリや中継機のバージョンアップが必要
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
新プロトコル: 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の公表値)
QUIC 1-RTTハンドシェイク（新規) クライアント サーバ CHLO (STK, VER, CCS, PDMD, SCID) REJ(STK, SNO, SCFG) CHLO(STK, SNO, SCID) 暗号化されたアプリデータ Source Address Token TLS1.3のknown_configrationに近い
0-RTT (再接続) クライアント サーバ CHLO(STK, SNO, SCID) 暗号化されたアプリデータ Source Address Token TLS1.3のknown_configrationに近い
演習：QUIC

More Related Content

HTTP/2, QUIC入門