Submit Search
Upload
QUIC標準化動向 〜2017/7
•
29 likes
•
9,788 views
Kazuho Oku
Follow
QUICの標準化動向を日本語で解説。HTTP/2勉強会発表資料(2017/08/23) https://http2study.connpass.com/event/63998/
Read less
Read more
Technology
Report
Share
Report
Share
1 of 37
Download now
Download to read offline
Recommended
HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計
Kazuho Oku
ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来
Kazuho Oku
H2O - making HTTP better
H2O - making HTTP better
Kazuho Oku
TLS & LURK @ IETF 95
TLS & LURK @ IETF 95
Kazuho Oku
TLS 1.3 と 0-RTT のこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話
Kazuho Oku
HTTP/2 でリバプロするだけでグラフツールを 高速化できた話
HTTP/2 でリバプロするだけでグラフツールを 高速化できた話
Naotoshi Seo
Webアプリケーションの無停止稼働
Webアプリケーションの無停止稼働
Kazuho Oku
HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向
Kazuho Oku
Recommended
HTTP/2時代のウェブサイト設計
HTTP/2時代のウェブサイト設計
Kazuho Oku
ウェブアーキテクチャの歴史と未来
ウェブアーキテクチャの歴史と未来
Kazuho Oku
H2O - making HTTP better
H2O - making HTTP better
Kazuho Oku
TLS & LURK @ IETF 95
TLS & LURK @ IETF 95
Kazuho Oku
TLS 1.3 と 0-RTT のこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話
Kazuho Oku
HTTP/2 でリバプロするだけでグラフツールを 高速化できた話
HTTP/2 でリバプロするだけでグラフツールを 高速化できた話
Naotoshi Seo
Webアプリケーションの無停止稼働
Webアプリケーションの無停止稼働
Kazuho Oku
HTTPとサーバ技術の最新動向
HTTPとサーバ技術の最新動向
Kazuho Oku
HTTP 2.0のヘッダ圧縮(HPACK)
HTTP 2.0のヘッダ圧縮(HPACK)
Jun Fujisawa
第2回Web技術勉強会 webパフォーマンス改善編
第2回Web技術勉強会 webパフォーマンス改善編
tzm_freedom
HTTP/2 入門
HTTP/2 入門
Yahoo!デベロッパーネットワーク
サーバPUSHざっくりまとめ
サーバPUSHざっくりまとめ
Yasuhiro Mawarimichi
HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜
Kaoru Maeda
FD.io VPP事始め
FD.io VPP事始め
tetsusat
Kernel vm-2014-05-25
Kernel vm-2014-05-25
Hirochika Asai
Word press on conoha このべん #3
Word press on conoha このべん #3
Wataru OKAMOTO
Lagopus 0.2.2
Lagopus 0.2.2
Masaru Oki
最新Webプロトコル傾向と対策
最新Webプロトコル傾向と対策
Kensaku Komatsu
HTTP/2, QUIC入門
HTTP/2, QUIC入門
shigeki_ohtsu
Rust-DPDK
Rust-DPDK
Masaru Oki
NetBSD/evbarm on Raspberry Pi
NetBSD/evbarm on Raspberry Pi
tokudahiroshi
Hydrogen → Helium での Linux kernel の違い
Hydrogen → Helium での Linux kernel の違い
Masakazu Asama
High Performance Networking with DPDK & Multi/Many Core
High Performance Networking with DPDK & Multi/Many Core
slankdev
nftables: the Next Generation Firewall in Linux
nftables: the Next Generation Firewall in Linux
Tomofumi Hayashi
WebRTC meetup Tokyo 1
WebRTC meetup Tokyo 1
mganeko
CppCon2016 report and Boost.SML
CppCon2016 report and Boost.SML
Takatoshi Kondo
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
Developers Summit
MAP 実装してみた
MAP 実装してみた
Masakazu Asama
Ietf97 ソウル報告
Ietf97 ソウル報告
yuki-f
2016 February - WebRTC Conference Japan - 日本語
2016 February - WebRTC Conference Japan - 日本語
Alexandre Gouaillard
More Related Content
What's hot
HTTP 2.0のヘッダ圧縮(HPACK)
HTTP 2.0のヘッダ圧縮(HPACK)
Jun Fujisawa
第2回Web技術勉強会 webパフォーマンス改善編
第2回Web技術勉強会 webパフォーマンス改善編
tzm_freedom
HTTP/2 入門
HTTP/2 入門
Yahoo!デベロッパーネットワーク
サーバPUSHざっくりまとめ
サーバPUSHざっくりまとめ
Yasuhiro Mawarimichi
HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜
Kaoru Maeda
FD.io VPP事始め
FD.io VPP事始め
tetsusat
Kernel vm-2014-05-25
Kernel vm-2014-05-25
Hirochika Asai
Word press on conoha このべん #3
Word press on conoha このべん #3
Wataru OKAMOTO
Lagopus 0.2.2
Lagopus 0.2.2
Masaru Oki
最新Webプロトコル傾向と対策
最新Webプロトコル傾向と対策
Kensaku Komatsu
HTTP/2, QUIC入門
HTTP/2, QUIC入門
shigeki_ohtsu
Rust-DPDK
Rust-DPDK
Masaru Oki
NetBSD/evbarm on Raspberry Pi
NetBSD/evbarm on Raspberry Pi
tokudahiroshi
Hydrogen → Helium での Linux kernel の違い
Hydrogen → Helium での Linux kernel の違い
Masakazu Asama
High Performance Networking with DPDK & Multi/Many Core
High Performance Networking with DPDK & Multi/Many Core
slankdev
nftables: the Next Generation Firewall in Linux
nftables: the Next Generation Firewall in Linux
Tomofumi Hayashi
WebRTC meetup Tokyo 1
WebRTC meetup Tokyo 1
mganeko
CppCon2016 report and Boost.SML
CppCon2016 report and Boost.SML
Takatoshi Kondo
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
Developers Summit
MAP 実装してみた
MAP 実装してみた
Masakazu Asama
What's hot
(20)
HTTP 2.0のヘッダ圧縮(HPACK)
HTTP 2.0のヘッダ圧縮(HPACK)
第2回Web技術勉強会 webパフォーマンス改善編
第2回Web技術勉強会 webパフォーマンス改善編
HTTP/2 入門
HTTP/2 入門
サーバPUSHざっくりまとめ
サーバPUSHざっくりまとめ
HTTP2 最速実装 〜入門編〜
HTTP2 最速実装 〜入門編〜
FD.io VPP事始め
FD.io VPP事始め
Kernel vm-2014-05-25
Kernel vm-2014-05-25
Word press on conoha このべん #3
Word press on conoha このべん #3
Lagopus 0.2.2
Lagopus 0.2.2
最新Webプロトコル傾向と対策
最新Webプロトコル傾向と対策
HTTP/2, QUIC入門
HTTP/2, QUIC入門
Rust-DPDK
Rust-DPDK
NetBSD/evbarm on Raspberry Pi
NetBSD/evbarm on Raspberry Pi
Hydrogen → Helium での Linux kernel の違い
Hydrogen → Helium での Linux kernel の違い
High Performance Networking with DPDK & Multi/Many Core
High Performance Networking with DPDK & Multi/Many Core
nftables: the Next Generation Firewall in Linux
nftables: the Next Generation Firewall in Linux
WebRTC meetup Tokyo 1
WebRTC meetup Tokyo 1
CppCon2016 report and Boost.SML
CppCon2016 report and Boost.SML
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
【19-C-L】Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」
MAP 実装してみた
MAP 実装してみた
Similar to QUIC標準化動向 〜2017/7
Ietf97 ソウル報告
Ietf97 ソウル報告
yuki-f
2016 February - WebRTC Conference Japan - 日本語
2016 February - WebRTC Conference Japan - 日本語
Alexandre Gouaillard
Webrtc最新動向
Webrtc最新動向
Yusuke Naka
HTTP/2.0と標準化
HTTP/2.0と標準化
Taketo Takashima
IPv6 最新動向 〜世界共通語で最適化が進むインターネット〜
IPv6 最新動向 〜世界共通語で最適化が進むインターネット〜
Akira Nakagawa
H.264で相互接続 - WebRTC Meetup Tokyo #10
H.264で相互接続 - WebRTC Meetup Tokyo #10
goforbroke
HTTP/2入門
HTTP/2入門
渉 米須
Let's begin WebRTC
Let's begin WebRTC
yoshikawa_t
WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側
Yusuke Naka
WebRTC SFU Mediasoup Sample update
WebRTC SFU Mediasoup Sample update
mganeko
Draft: Observability, Service Mesh and Microservices
Draft: Observability, Service Mesh and Microservices
Taiki
2013 WebRTC node
2013 WebRTC node
mganeko
Webrtc bootcamp handson
Webrtc bootcamp handson
mganeko
WebRTC SFU mediasoup sample
WebRTC SFU mediasoup sample
mganeko
WebRTC NextVersion時代のJavaScript開発
WebRTC NextVersion時代のJavaScript開発
Yusuke Naka
EchoyaGinhanazeSu_inoka.pptx
EchoyaGinhanazeSu_inoka.pptx
keink
OpenStack Summit Austin 2016 参加報告 - OpenStack最新情報セミナー 2016年5月
OpenStack Summit Austin 2016 参加報告 - OpenStack最新情報セミナー 2016年5月
VirtualTech Japan Inc.
Amalgam8 application switch for cloud native services
Amalgam8 application switch for cloud native services
Takehiko Amano
2013 WebRTC 概説 & ワークショップ
2013 WebRTC 概説 & ワークショップ
mganeko
JavaプログラマのためのWebSocket概要
JavaプログラマのためのWebSocket概要
Shumpei Shiraishi
Similar to QUIC標準化動向 〜2017/7
(20)
Ietf97 ソウル報告
Ietf97 ソウル報告
2016 February - WebRTC Conference Japan - 日本語
2016 February - WebRTC Conference Japan - 日本語
Webrtc最新動向
Webrtc最新動向
HTTP/2.0と標準化
HTTP/2.0と標準化
IPv6 最新動向 〜世界共通語で最適化が進むインターネット〜
IPv6 最新動向 〜世界共通語で最適化が進むインターネット〜
H.264で相互接続 - WebRTC Meetup Tokyo #10
H.264で相互接続 - WebRTC Meetup Tokyo #10
HTTP/2入門
HTTP/2入門
Let's begin WebRTC
Let's begin WebRTC
WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC SFU Mediasoup Sample update
WebRTC SFU Mediasoup Sample update
Draft: Observability, Service Mesh and Microservices
Draft: Observability, Service Mesh and Microservices
2013 WebRTC node
2013 WebRTC node
Webrtc bootcamp handson
Webrtc bootcamp handson
WebRTC SFU mediasoup sample
WebRTC SFU mediasoup sample
WebRTC NextVersion時代のJavaScript開発
WebRTC NextVersion時代のJavaScript開発
EchoyaGinhanazeSu_inoka.pptx
EchoyaGinhanazeSu_inoka.pptx
OpenStack Summit Austin 2016 参加報告 - OpenStack最新情報セミナー 2016年5月
OpenStack Summit Austin 2016 参加報告 - OpenStack最新情報セミナー 2016年5月
Amalgam8 application switch for cloud native services
Amalgam8 application switch for cloud native services
2013 WebRTC 概説 & ワークショップ
2013 WebRTC 概説 & ワークショップ
JavaプログラマのためのWebSocket概要
JavaプログラマのためのWebSocket概要
More from Kazuho Oku
HTTP/2で 速くなるとき ならないとき
HTTP/2で 速くなるとき ならないとき
Kazuho Oku
HTTP/2の課題と将来
HTTP/2の課題と将来
Kazuho Oku
Reorganizing Website Architecture for HTTP/2 and Beyond
Reorganizing Website Architecture for HTTP/2 and Beyond
Kazuho Oku
Recent Advances in HTTP, controlling them using ruby
Recent Advances in HTTP, controlling them using ruby
Kazuho Oku
Programming TCP for responsiveness
Programming TCP for responsiveness
Kazuho Oku
Programming TCP for responsiveness
Programming TCP for responsiveness
Kazuho Oku
Developing the fastest HTTP/2 server
Developing the fastest HTTP/2 server
Kazuho Oku
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
Kazuho Oku
Cache aware-server-push in H2O version 1.5
Cache aware-server-push in H2O version 1.5
Kazuho Oku
H2O - making the Web faster
H2O - making the Web faster
Kazuho Oku
H2O - the optimized HTTP server
H2O - the optimized HTTP server
Kazuho Oku
JSON SQL Injection and the Lessons Learned
JSON SQL Injection and the Lessons Learned
Kazuho Oku
JSX 速さの秘密 - 高速なJavaScriptを書く方法
JSX 速さの秘密 - 高速なJavaScriptを書く方法
Kazuho Oku
JSX の現在と未来 - Oct 26 2013
JSX の現在と未来 - Oct 26 2013
Kazuho Oku
Using the Power to Prove
Using the Power to Prove
Kazuho Oku
JSX - 公開から1年を迎えて
JSX - 公開から1年を迎えて
Kazuho Oku
JSX - developing a statically-typed programming language for the Web
JSX - developing a statically-typed programming language for the Web
Kazuho Oku
ウェブブラウザの時代は終わるのか 〜スマホアプリとHTML5の未来〜
ウェブブラウザの時代は終わるのか 〜スマホアプリとHTML5の未来〜
Kazuho Oku
JSX
JSX
Kazuho Oku
JSX Optimizer
JSX Optimizer
Kazuho Oku
More from Kazuho Oku
(20)
HTTP/2で 速くなるとき ならないとき
HTTP/2で 速くなるとき ならないとき
HTTP/2の課題と将来
HTTP/2の課題と将来
Reorganizing Website Architecture for HTTP/2 and Beyond
Reorganizing Website Architecture for HTTP/2 and Beyond
Recent Advances in HTTP, controlling them using ruby
Recent Advances in HTTP, controlling them using ruby
Programming TCP for responsiveness
Programming TCP for responsiveness
Programming TCP for responsiveness
Programming TCP for responsiveness
Developing the fastest HTTP/2 server
Developing the fastest HTTP/2 server
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
Cache aware-server-push in H2O version 1.5
Cache aware-server-push in H2O version 1.5
H2O - making the Web faster
H2O - making the Web faster
H2O - the optimized HTTP server
H2O - the optimized HTTP server
JSON SQL Injection and the Lessons Learned
JSON SQL Injection and the Lessons Learned
JSX 速さの秘密 - 高速なJavaScriptを書く方法
JSX 速さの秘密 - 高速なJavaScriptを書く方法
JSX の現在と未来 - Oct 26 2013
JSX の現在と未来 - Oct 26 2013
Using the Power to Prove
Using the Power to Prove
JSX - 公開から1年を迎えて
JSX - 公開から1年を迎えて
JSX - developing a statically-typed programming language for the Web
JSX - developing a statically-typed programming language for the Web
ウェブブラウザの時代は終わるのか 〜スマホアプリとHTML5の未来〜
ウェブブラウザの時代は終わるのか 〜スマホアプリとHTML5の未来〜
JSX
JSX
JSX Optimizer
JSX Optimizer
Recently uploaded
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツール
sugiuralab
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
Atomu Hidaka
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
iPride Co., Ltd.
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
Shota Ito
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
osamut
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価
sugiuralab
Recently uploaded
(7)
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツール
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価
QUIC標準化動向 〜2017/7
1.
QUIC標準化動向 〜2017/7 QUIC標準化動向 〜2017/7 Kazuho
Oku Fastly
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.
QUIC標準化動向 〜2017/7 • QUICとは •
標準化動向 • 標準化の論点 • まとめ • TLS 1.3動向 目次
4.
QUIC標準化動向 〜2017/7 QUICとは
5.
QUIC標準化動向 〜2017/7
6.
QUIC標準化動向 〜2017/7 • TCP/IPとTLSとHTTP/2の一体化 QUICとは HTTP/2 TLS TCP IP QUIC QUIC-HTTP UDP TLS 暗号化 多重化 トランスポート
7.
QUIC標準化動向 〜2017/7 • 接続確立の高速化 •
ヘッドオブラインブロッキングの回避 • ローミング • プライバシー保護と進化可能性 一体化の理由
8.
QUIC標準化動向 〜2017/7 • 従来:
2RTT – TCPハンドシェイク: 1RTT – TLSハンドシェイク: 1RTT • QUIC: 1RTT – SYNとTLSハンドシェイクを一体化 接続確立の高速化
9.
QUIC標準化動向 〜2017/7 • HTTP/2では、先行するレスポンスのパケット が欠落すると、後続するレスポンスのパケット が届いていてもデコードできない –
TCP(TLS)はデータを順に処理するモデルだから • QUICでは、パケット単位でデコード可能 – TLSを用いてハンドシェイク後、パケット単位の暗 号鍵をTLSスタックからexport – AEAD nonce=packet number ヘッドオブラインブロッキング
10.
QUIC標準化動向 〜2017/7 • QUICでは、IPアドレス/ポートではなく64bitの Connection
IDを用いて接続を判別すること が可能 – クライアントのアドレスがかわっても通信を継続 ローミング
11.
QUIC標準化動向 〜2017/7 • QUICでは、Connection
IDとパケット番号以 外の全てのデータを暗号化 – 通信の中継者に漏れる情報が少ない – ルータ等のバグにより、プロトコルの進化が阻害 されない • カーネルではなくユーザランドで実装可能 • 接続確立時にプロトコルバージョンのネゴシ エーション プライバシー保護と進化可能性
12.
QUIC標準化動向 〜2017/7 • GQUIC –
GoogleがChromeと自社サーバ間で利用してい るプロトコル – 定期的にバージョンアップ • いずれはIQUICになる • IQUIC – GQUICをもとにIETFで標準化中のプロトコル 2つのQUIC
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.
QUIC標準化動向 〜2017/7 • パケット構成: –
ヘッダ: • Type, Connection ID, Packet Numberは平文 • 残りはAEAD暗号化 – 平文部分はAEADの認証データ – フレーム群: • STREAM, ACK, MAX_DATA, … • HTTPのフレーム != QUICフレーム – HTTPのフレーム(例: PRIORITY)はSTREAM内のデータ IQUICのパケットフォーマット
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.
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.
QUIC標準化動向 〜2017/7 標準化動向
18.
QUIC標準化動向 〜2017/7 • 2016/11
ワーキンググループ設立 • 2017/7 初回相互接続テスト • 2018/3 コアドキュメント群のラストコール完了 • 2018/11 HTTPマッピングのラストコール完了 予定ロードマップ(2016/11)
19.
QUIC標準化動向 〜2017/7 • 2016/11
ワーキンググループ設立 • 2017/7 初回相互接続テスト • 2018/3 コアドキュメント群のラストコール完了 • 2018/11 HTTPマッピングのラストコール完了 実際
20.
QUIC標準化動向 〜2017/7 初回相互接続テスト 参照: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit •
当初はハンドシェイクのみにする予定だった • 次回はHTTP/0.9での相互接続が目標
21.
QUIC標準化動向 〜2017/7 • Rough
Consensus and Running Code • 基本はMLとGitHub Issuesで議論 • 年6回のミーティング – 年3回のIETF – 年3回のInterim Meeting – ハッカソンで相互接続を確認、問題の洗い出し 標準化の進め方
22.
QUIC標準化動向 〜2017/7
23.
QUIC標準化動向 〜2017/7 標準化の論点
24.
QUIC標準化動向 〜2017/7 • トランスポート –
Server-chosen Connection ID – Stateless Reset – Closing Connections – Unidirectional Streams – On-path RTT measurement – … • HTTPバインディング 標準化の論点
25.
QUIC標準化動向 〜2017/7 • GQUICの仕様:
IDはクライアントが決定 • やりたいこと: IDにPOP識別子を埋込みたい – 理由: クライアントのアドレスがローミングすると、 AnycastベースのCDNでは異なるPOPにパケット が届き始める – 元のPOPがどこかをどうやって判別するのか • 結論: ハンドシェイク終了時にサーバで Connection IDを発番 Server-chosen Connection ID
26.
QUIC標準化動向 〜2017/7 • QUICではRSTも暗号化される •
課題: エンドポイントがリセットされて暗号鍵 が失われたら、接続をリセットできない??? • 結論: 以下の手順でやる – 1. RSTを表すバイト列を接続確立時に発行 • このバイト列はstatic keyとconnection IDから導出 • 一見暗号化されたデータのように見える – 2. サーバはリセット時に、このバイト列を送信 – 3. クライアントはパケットの復号に失敗したら、こ のリセットでないか確認 Stateless Reset
27.
QUIC標準化動向 〜2017/7 • 接続レベルでの切断用パケットは不要? –
注: ストリーム単位でのFINはある – タイムアウト時に切断パケットを流すのは電力と ネットワークの無駄 • 結論: – 切断用パケットはQUICでは標準化しない – 必要なら各プロトコルバインディングで対応 • 例: DNS over QUICなら切断用パケット不要 • 例: HTTP over QUICなら、切断時に、サーバが最後 に処理したリクエストのstream IDを送信 Closing Connections
28.
QUIC標準化動向 〜2017/7 • ストリームを片方向として定義したい –
各バインディングで両方向のストリームを束ねれ ば、双方向ストリームを実現可能 • メリット: – QUICレイヤのステートマシン単純化 • デメリット: – バインディングの複雑化 • 結論: 提案の再検討 – コアで双方向ストリームをサポートする点は合意 Unidirectional Streams
29.
QUIC標準化動向 〜2017/7 • QUICでは、ルータはACKに含まれるpacket numberを観測できない(暗号化されるから) •
課題: ルータが接続のRTTを測定し、それに 基づいた最適化を施せない • 解決案: – パケットヘッダ内に、ルータが自由に書き換え可 能な1bitを用意する – エンドポイントはこの1bitをそのままエコー • 問題: プライバシーリスク On-path RTT measurement
30.
QUIC標準化動向 〜2017/7 • ECN対応 –
ルータが輻輳をエンドポイントに通知 – エンドポイントはピアにECN情報を通知※ – ※をQUICで行うべきか、どうやるか • Encrypting Metadata – packet numberも暗号化したい その他のコアのissue
31.
QUIC標準化動向 〜2017/7 • 問題:
ヘッダとボディを別々のストリームで送 るか否か – 注: ヘッダを送るストリームはリセットできない(圧 縮情報として後続のリクエストから参照されるた め)。ボディはリセット必須 • 結論: – 圧縮情報はcontrol streamで送信 – ヘッダとボディはリセット可能な単一ストリーム • ヘッダはcontrol streamの圧縮情報を参照 HTTPバインディング
32.
QUIC標準化動向 〜2017/7 • ヘッダ圧縮 –
HPACKは配送順に依存するので改良が必要 – ふたつの提案: QPACK, QCRAM – 両者の主要な差異: • header indexを絶対値で送るか、絶対値を復元可能 な相対値で送るか • トランスポートが受信したACKの情報を使ってヘッダ 圧縮器のステートを更新するか、HTTPバインディング レベルでACKを送るか HTTPバインディング
33.
QUIC標準化動向 〜2017/7 • 優先度制御 –
HTTP/2では、Idle Streamを使って、複数のスト リームをまとめて優先度制御していた – QUICにはIdle Streamが存在しない • すべてのStreamでHTTPリクエストを流さないと色々 面倒なことになるので… – 解決策: ストリームをまとめるグループ専用のID 空間を用意しよう HTTPバインディング
34.
QUIC標準化動向 〜2017/7 まとめ
35.
QUIC標準化動向 〜2017/7 • 議論錯綜中 –
特にunidirectional streamはコアの設計に影響 • interopはちょい遅れくらいでがんばり まとめ
36.
QUIC標準化動向 〜2017/7 TLS 1.3動向
37.
QUIC標準化動向 〜2017/7 • draft-21のWGLCなう •
一部のファイアウォールを通過できない問題 – Facebookがcleartext handshake messageの IDを変えることで、疎通率が改善したと報告 • Googleが追試中 • Using Early Data in HTTP TLS 1.3動向
Download now