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.
QUIC標準化動向 〜2017/7
QUIC標準化動向 〜2017/7
Kazuho Oku
Fastly
QUIC標準化動向 〜2017/7
• 大手CDN「Fastly」勤務
• HTTP/2サーバ「H2O」開発者
– TLS 1.3実装済 (known as picotls)
– QUIC実装中 (known as quicly)
• HTTP...
QUIC標準化動向 〜2017/7
• QUICとは
• 標準化動向
• 標準化の論点
• まとめ
• TLS 1.3動向
目次
QUIC標準化動向 〜2017/7
QUICとは
QUIC標準化動向 〜2017/7
QUIC標準化動向 〜2017/7
• TCP/IPとTLSとHTTP/2の一体化
QUICとは
HTTP/2
TLS
TCP
IP
QUIC
QUIC-HTTP
UDP
TLS
暗号化
多重化
トランスポート
QUIC標準化動向 〜2017/7
• 接続確立の高速化
• ヘッドオブラインブロッキングの回避
• ローミング
• プライバシー保護と進化可能性
一体化の理由
QUIC標準化動向 〜2017/7
• 従来: 2RTT
– TCPハンドシェイク: 1RTT
– TLSハンドシェイク: 1RTT
• QUIC: 1RTT
– SYNとTLSハンドシェイクを一体化
接続確立の高速化
QUIC標準化動向 〜2017/7
• HTTP/2では、先行するレスポンスのパケット
が欠落すると、後続するレスポンスのパケット
が届いていてもデコードできない
– TCP(TLS)はデータを順に処理するモデルだから
• QUICでは、パケッ...
QUIC標準化動向 〜2017/7
• QUICでは、IPアドレス/ポートではなく64bitの
Connection IDを用いて接続を判別すること
が可能
– クライアントのアドレスがかわっても通信を継続
ローミング
QUIC標準化動向 〜2017/7
• QUICでは、Connection IDとパケット番号以
外の全てのデータを暗号化
– 通信の中継者に漏れる情報が少ない
– ルータ等のバグにより、プロトコルの進化が阻害
されない
• カーネルではなくユ...
QUIC標準化動向 〜2017/7
• GQUIC
– GoogleがChromeと自社サーバ間で利用してい
るプロトコル
– 定期的にバージョンアップ
• いずれはIQUICになる
• IQUIC
– GQUICをもとにIETFで標準化中のプ...
QUIC標準化動向 〜2017/7
• モバイル・新興国など回線状態の悪い環境に
おけるユーザ体験の改善
• 検索のレイテンシ:
– 90パーセンタイル: 10.3%減少
– 99パーセンタイル: 16.7%減少
• 動画再生時のリバッファ発生...
QUIC標準化動向 〜2017/7
• パケット構成:
– ヘッダ:
• Type, Connection ID, Packet Numberは平文
• 残りはAEAD暗号化
– 平文部分はAEADの認証データ
– フレーム群:
• STREA...
QUIC標準化動向 〜2017/7
Long Packet:
0 1 2 3
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
+-+-+-+-+-+-+-+-+
|...
QUIC標準化動向 〜2017/7
ACK Frame:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+...
QUIC標準化動向 〜2017/7
標準化動向
QUIC標準化動向 〜2017/7
• 2016/11 ワーキンググループ設立
• 2017/7 初回相互接続テスト
• 2018/3 コアドキュメント群のラストコール完了
• 2018/11 HTTPマッピングのラストコール完了
予定ロードマ...
QUIC標準化動向 〜2017/7
• 2016/11 ワーキンググループ設立
• 2017/7 初回相互接続テスト
• 2018/3 コアドキュメント群のラストコール完了
• 2018/11 HTTPマッピングのラストコール完了
実際
QUIC標準化動向 〜2017/7
初回相互接続テスト
参照: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit
•...
QUIC標準化動向 〜2017/7
• Rough Consensus and Running Code
• 基本はMLとGitHub Issuesで議論
• 年6回のミーティング
– 年3回のIETF
– 年3回のInterim Meetin...
QUIC標準化動向 〜2017/7
QUIC標準化動向 〜2017/7
標準化の論点
QUIC標準化動向 〜2017/7
• トランスポート
– Server-chosen Connection ID
– Stateless Reset
– Closing Connections
– Unidirectional Streams...
QUIC標準化動向 〜2017/7
• GQUICの仕様: IDはクライアントが決定
• やりたいこと: IDにPOP識別子を埋込みたい
– 理由: クライアントのアドレスがローミングすると、
AnycastベースのCDNでは異なるPOPにパケ...
QUIC標準化動向 〜2017/7
• QUICではRSTも暗号化される
• 課題: エンドポイントがリセットされて暗号鍵
が失われたら、接続をリセットできない???
• 結論: 以下の手順でやる
– 1. RSTを表すバイト列を接続確立時に発...
QUIC標準化動向 〜2017/7
• 接続レベルでの切断用パケットは不要?
– 注: ストリーム単位でのFINはある
– タイムアウト時に切断パケットを流すのは電力と
ネットワークの無駄
• 結論:
– 切断用パケットはQUICでは標準化しな...
QUIC標準化動向 〜2017/7
• ストリームを片方向として定義したい
– 各バインディングで両方向のストリームを束ねれ
ば、双方向ストリームを実現可能
• メリット:
– QUICレイヤのステートマシン単純化
• デメリット:
– バイン...
QUIC標準化動向 〜2017/7
• QUICでは、ルータはACKに含まれるpacket
numberを観測できない(暗号化されるから)
• 課題: ルータが接続のRTTを測定し、それに
基づいた最適化を施せない
• 解決案:
– パケットヘ...
QUIC標準化動向 〜2017/7
• ECN対応
– ルータが輻輳をエンドポイントに通知
– エンドポイントはピアにECN情報を通知※
– ※をQUICで行うべきか、どうやるか
• Encrypting Metadata
– packet n...
QUIC標準化動向 〜2017/7
• 問題: ヘッダとボディを別々のストリームで送
るか否か
– 注: ヘッダを送るストリームはリセットできない(圧
縮情報として後続のリクエストから参照されるた
め)。ボディはリセット必須
• 結論:
– 圧...
QUIC標準化動向 〜2017/7
• ヘッダ圧縮
– HPACKは配送順に依存するので改良が必要
– ふたつの提案: QPACK, QCRAM
– 両者の主要な差異:
• header indexを絶対値で送るか、絶対値を復元可能
な相対値で...
QUIC標準化動向 〜2017/7
• 優先度制御
– HTTP/2では、Idle Streamを使って、複数のスト
リームをまとめて優先度制御していた
– QUICにはIdle Streamが存在しない
• すべてのStreamでHTTPリク...
QUIC標準化動向 〜2017/7
まとめ
QUIC標準化動向 〜2017/7
• 議論錯綜中
– 特にunidirectional streamはコアの設計に影響
• interopはちょい遅れくらいでがんばり
まとめ
QUIC標準化動向 〜2017/7
TLS 1.3動向
QUIC標準化動向 〜2017/7
• draft-21のWGLCなう
• 一部のファイアウォールを通過できない問題
– Facebookがcleartext handshake messageの
IDを変えることで、疎通率が改善したと報告
•...
Upcoming SlideShare
Loading in …5
×

QUIC標準化動向 〜2017/7

6,898 views

Published on

QUICの標準化動向を日本語で解説。HTTP/2勉強会発表資料(2017/08/23)
https://http2study.connpass.com/event/63998/

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

QUIC標準化動向 〜2017/7

  1. 1. QUIC標準化動向 〜2017/7 QUIC標準化動向 〜2017/7 Kazuho Oku Fastly
  2. 2. QUIC標準化動向 〜2017/7 • 大手CDN「Fastly」勤務 • HTTP/2サーバ「H2O」開発者 – TLS 1.3実装済 (known as picotls) – QUIC実装中 (known as quicly) • HTTP関連のインターネットドラフト著者 – 103 Early Hints – Cache Digest for HTTP/2 自己紹介
  3. 3. QUIC標準化動向 〜2017/7 • QUICとは • 標準化動向 • 標準化の論点 • まとめ • TLS 1.3動向 目次
  4. 4. QUIC標準化動向 〜2017/7 QUICとは
  5. 5. QUIC標準化動向 〜2017/7
  6. 6. QUIC標準化動向 〜2017/7 • TCP/IPとTLSとHTTP/2の一体化 QUICとは HTTP/2 TLS TCP IP QUIC QUIC-HTTP UDP TLS 暗号化 多重化 トランスポート
  7. 7. QUIC標準化動向 〜2017/7 • 接続確立の高速化 • ヘッドオブラインブロッキングの回避 • ローミング • プライバシー保護と進化可能性 一体化の理由
  8. 8. QUIC標準化動向 〜2017/7 • 従来: 2RTT – TCPハンドシェイク: 1RTT – TLSハンドシェイク: 1RTT • QUIC: 1RTT – SYNとTLSハンドシェイクを一体化 接続確立の高速化
  9. 9. QUIC標準化動向 〜2017/7 • HTTP/2では、先行するレスポンスのパケット が欠落すると、後続するレスポンスのパケット が届いていてもデコードできない – TCP(TLS)はデータを順に処理するモデルだから • QUICでは、パケット単位でデコード可能 – TLSを用いてハンドシェイク後、パケット単位の暗 号鍵をTLSスタックからexport – AEAD nonce=packet number ヘッドオブラインブロッキング
  10. 10. QUIC標準化動向 〜2017/7 • QUICでは、IPアドレス/ポートではなく64bitの Connection IDを用いて接続を判別すること が可能 – クライアントのアドレスがかわっても通信を継続 ローミング
  11. 11. QUIC標準化動向 〜2017/7 • QUICでは、Connection IDとパケット番号以 外の全てのデータを暗号化 – 通信の中継者に漏れる情報が少ない – ルータ等のバグにより、プロトコルの進化が阻害 されない • カーネルではなくユーザランドで実装可能 • 接続確立時にプロトコルバージョンのネゴシ エーション プライバシー保護と進化可能性
  12. 12. QUIC標準化動向 〜2017/7 • GQUIC – GoogleがChromeと自社サーバ間で利用してい るプロトコル – 定期的にバージョンアップ • いずれはIQUICになる • IQUIC – GQUICをもとにIETFで標準化中のプロトコル 2つのQUIC
  13. 13. QUIC標準化動向 〜2017/7 • モバイル・新興国など回線状態の悪い環境に おけるユーザ体験の改善 • 検索のレイテンシ: – 90パーセンタイル: 10.3%減少 – 99パーセンタイル: 16.7%減少 • 動画再生時のリバッファ発生率 – 90パーセンタイル: 70.4%減少 – 99パーセンタイル: 18.5%減少 参考文献: The QUIC Transport Protocol: Design and Internet-Scale Deployment GQUICの効果測定
  14. 14. QUIC標準化動向 〜2017/7 • パケット構成: – ヘッダ: • Type, Connection ID, Packet Numberは平文 • 残りはAEAD暗号化 – 平文部分はAEADの認証データ – フレーム群: • STREAM, ACK, MAX_DATA, … • HTTPのフレーム != QUICフレーム – HTTPのフレーム(例: PRIORITY)はSTREAM内のデータ IQUICのパケットフォーマット
  15. 15. QUIC標準化動向 〜2017/7 Long Packet: 0 1 2 3 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 +-+-+-+-+-+-+-+-+ |1| Type (7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frames (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ STREAM Frame: 0 1 2 3 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 +-+-+-+-+-+-+-+-+ |1 1 F S S O O D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (8/16/24/32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset (0/16/32/64) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Data Length (16)] | Stream Data (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  16. 16. QUIC標準化動向 〜2017/7 ACK Frame: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 1 N L L M M|[Num Blocks(8)]| NumTS (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Largest Acknowledged (8/16/32/64) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Delay (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Block Section (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp Section (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACK Block Section: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First ACK Block Length (8/16/32/64) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap 1 (8)] | [ACK Block 1 Length (8/16/32/64)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap 2 (8)] | [ACK Block 2 Length (8/16/32/64)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap N (8)] | [ACK Block N Length (8/16/32/64)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  17. 17. QUIC標準化動向 〜2017/7 標準化動向
  18. 18. QUIC標準化動向 〜2017/7 • 2016/11 ワーキンググループ設立 • 2017/7 初回相互接続テスト • 2018/3 コアドキュメント群のラストコール完了 • 2018/11 HTTPマッピングのラストコール完了 予定ロードマップ(2016/11)
  19. 19. QUIC標準化動向 〜2017/7 • 2016/11 ワーキンググループ設立 • 2017/7 初回相互接続テスト • 2018/3 コアドキュメント群のラストコール完了 • 2018/11 HTTPマッピングのラストコール完了 実際
  20. 20. QUIC標準化動向 〜2017/7 初回相互接続テスト 参照: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit • 当初はハンドシェイクのみにする予定だった • 次回はHTTP/0.9での相互接続が目標
  21. 21. QUIC標準化動向 〜2017/7 • Rough Consensus and Running Code • 基本はMLとGitHub Issuesで議論 • 年6回のミーティング – 年3回のIETF – 年3回のInterim Meeting – ハッカソンで相互接続を確認、問題の洗い出し 標準化の進め方
  22. 22. QUIC標準化動向 〜2017/7
  23. 23. QUIC標準化動向 〜2017/7 標準化の論点
  24. 24. QUIC標準化動向 〜2017/7 • トランスポート – Server-chosen Connection ID – Stateless Reset – Closing Connections – Unidirectional Streams – On-path RTT measurement – … • HTTPバインディング 標準化の論点
  25. 25. QUIC標準化動向 〜2017/7 • GQUICの仕様: IDはクライアントが決定 • やりたいこと: IDにPOP識別子を埋込みたい – 理由: クライアントのアドレスがローミングすると、 AnycastベースのCDNでは異なるPOPにパケット が届き始める – 元のPOPがどこかをどうやって判別するのか • 結論: ハンドシェイク終了時にサーバで Connection IDを発番 Server-chosen Connection ID
  26. 26. QUIC標準化動向 〜2017/7 • QUICではRSTも暗号化される • 課題: エンドポイントがリセットされて暗号鍵 が失われたら、接続をリセットできない??? • 結論: 以下の手順でやる – 1. RSTを表すバイト列を接続確立時に発行 • このバイト列はstatic keyとconnection IDから導出 • 一見暗号化されたデータのように見える – 2. サーバはリセット時に、このバイト列を送信 – 3. クライアントはパケットの復号に失敗したら、こ のリセットでないか確認 Stateless Reset
  27. 27. QUIC標準化動向 〜2017/7 • 接続レベルでの切断用パケットは不要? – 注: ストリーム単位でのFINはある – タイムアウト時に切断パケットを流すのは電力と ネットワークの無駄 • 結論: – 切断用パケットはQUICでは標準化しない – 必要なら各プロトコルバインディングで対応 • 例: DNS over QUICなら切断用パケット不要 • 例: HTTP over QUICなら、切断時に、サーバが最後 に処理したリクエストのstream IDを送信 Closing Connections
  28. 28. QUIC標準化動向 〜2017/7 • ストリームを片方向として定義したい – 各バインディングで両方向のストリームを束ねれ ば、双方向ストリームを実現可能 • メリット: – QUICレイヤのステートマシン単純化 • デメリット: – バインディングの複雑化 • 結論: 提案の再検討 – コアで双方向ストリームをサポートする点は合意 Unidirectional Streams
  29. 29. QUIC標準化動向 〜2017/7 • QUICでは、ルータはACKに含まれるpacket numberを観測できない(暗号化されるから) • 課題: ルータが接続のRTTを測定し、それに 基づいた最適化を施せない • 解決案: – パケットヘッダ内に、ルータが自由に書き換え可 能な1bitを用意する – エンドポイントはこの1bitをそのままエコー • 問題: プライバシーリスク On-path RTT measurement
  30. 30. QUIC標準化動向 〜2017/7 • ECN対応 – ルータが輻輳をエンドポイントに通知 – エンドポイントはピアにECN情報を通知※ – ※をQUICで行うべきか、どうやるか • Encrypting Metadata – packet numberも暗号化したい その他のコアのissue
  31. 31. QUIC標準化動向 〜2017/7 • 問題: ヘッダとボディを別々のストリームで送 るか否か – 注: ヘッダを送るストリームはリセットできない(圧 縮情報として後続のリクエストから参照されるた め)。ボディはリセット必須 • 結論: – 圧縮情報はcontrol streamで送信 – ヘッダとボディはリセット可能な単一ストリーム • ヘッダはcontrol streamの圧縮情報を参照 HTTPバインディング
  32. 32. QUIC標準化動向 〜2017/7 • ヘッダ圧縮 – HPACKは配送順に依存するので改良が必要 – ふたつの提案: QPACK, QCRAM – 両者の主要な差異: • header indexを絶対値で送るか、絶対値を復元可能 な相対値で送るか • トランスポートが受信したACKの情報を使ってヘッダ 圧縮器のステートを更新するか、HTTPバインディング レベルでACKを送るか HTTPバインディング
  33. 33. QUIC標準化動向 〜2017/7 • 優先度制御 – HTTP/2では、Idle Streamを使って、複数のスト リームをまとめて優先度制御していた – QUICにはIdle Streamが存在しない • すべてのStreamでHTTPリクエストを流さないと色々 面倒なことになるので… – 解決策: ストリームをまとめるグループ専用のID 空間を用意しよう HTTPバインディング
  34. 34. QUIC標準化動向 〜2017/7 まとめ
  35. 35. QUIC標準化動向 〜2017/7 • 議論錯綜中 – 特にunidirectional streamはコアの設計に影響 • interopはちょい遅れくらいでがんばり まとめ
  36. 36. QUIC標準化動向 〜2017/7 TLS 1.3動向
  37. 37. QUIC標準化動向 〜2017/7 • draft-21のWGLCなう • 一部のファイアウォールを通過できない問題 – Facebookがcleartext handshake messageの IDを変えることで、疎通率が改善したと報告 • Googleが追試中 • Using Early Data in HTTP TLS 1.3動向

×