QUICについて (2020/06 追記)
手前味噌ですが、QUICについて別途まとめましたので、参考にして頂ければ
2020/06/01 時点でHTTP/3, QUICの解説書を書きました
https://github.com/flano-yuki/http3-note
あわせて個人ブログもどうぞ
QUICとは
QUICとはGoogleの考案したHTTPのメッセージを効率よく高速かつ安全にやりとりするためのプロトコルであり。UDP上でTCP+TLS1.3+HTTP/2のような機能を持ち、信頼性のある安全な通信を行う。
スタック図を見ると分かる通り、TCPのような輻輳制御やロスリカバリと、TLS1.3の機能、およびHTTP(アプリケーションプロトコル)からなる
(引用: https://datatracker.ietf.org/meeting/98/materials/slides-98-edu-sessf-quic-tutorial/ )
QUICは多くの機能があり様々なメリットがある
- UDP上で通信するのでTCPのように通信環境(IPアドレス)が変わってもセッションが切れない(UDP上でセッションIDが管理される)
- TCPの場合パケットロスが発生した場合、そのパケットを回復してからアプリケーションとして処理可能になるが、UDPなので届いたパケットから処理することが出来る
- 1-RTT(最速で0-RTT)のハンドシェイク
- ACKといった制御情報を含むほとんどの領域の暗号化し、データの保護
- TCPだと改善しようとするとカーネルを更新する必要があり時間が掛かるが、ユーザランドで動作するため更新が容易
概要を解説している記事は多くあるので参考になります
Google QUIC, IETF QUIC
QUICには現在GoogleがChromeや自社プロダクトで使用しているGoogle QUIC (gQUIC)と、IETFで標準化を行っているiQUICがあり、それぞれ互換性はありません。
ハンドシェイク時に使用するバージョンの空間も異なっています。
https://github.com/quicwg/base-drafts/wiki/QUIC-Versions
IETF側で議論されIETF QUICに盛り込まれた内容がGoogle QUICでも取り込まれ、デプロイした結果がまたフィードバックされたりと、両者はお互いに影響しながら改善が進められています。
Google QUIC利用状況
現状gQUICは、すでにGoogleのサービス及びブラウザでサポートされておりそのメリットは多く報告されております、またインターネットのトラフィックの内7%がQUICであることも書かれています。他の事例では以下の通り、幾つかの事例があります。
- Line事例：https://engineering.linecorp.com/ja/blog/detail/67
- Akamai事例：https://blogs.akamai.com/jp/2017/05/udpquic---akamai-media-acceleration.html
- LiteSpeed事例：https://blog.litespeedtech.com/2017/06/26/litespeed-is-powered-by-quic/
特にGoogleでのデプロイ結果については下記の論文で詳しく書いてあり、レイテンシの改善やYouTubeにおけるリバッファリング発生率の改善のことや、UDPのペイロードサイズの調査、ユーザスペースデプロイの容易さについて言及しており、非常に貴重なデータを見ることが出来ます
https://dl.acm.org/citation.cfm?id=3098842
自サイトで使いたい場合はCaddyが対応している
IETF QUICの実装状況
IETFでは標準化中のプロトコルの実装を持ち寄って相互接続テストを実施しながら標準化を進めていきます。
QUICも同様で現在も多くの実装が開発中です。現在は、「Third Implementation Draft」で示される機能を実装しています。ハンドシェイクを行い(0-RTTハンドシェイク、リサンプション)、HTTP/0.9のデータをやりとりし、クローズするようなテストを行っています。
「Third Implementation Draft」の相互接続状況は下記のとおりです
- V: version negotiation
- H: Handshake
- D: Stream Data
- C: Connection Close
- R: Resumption
- Z: 0-RTT
その他、実装のリストはWikiに書かれており、その多くはソースコードも公開されビルド出来る状況です。
https://github.com/quicwg/base-drafts/wiki/Implementations
IETF QUICと標準化状況
スケジュールとスコープ
2017年10月にスケジュールとスコープの見直しが入りました(URL)。
現在のスケジュールは、コアスペックである下記の4つの仕様を2018年11月にIESTに提出する（現在それぞれdraft-08）
- QUIC: A UDP-Based Multiplexed and Secure Transport
- QUIC Loss Detection and Congestion Control
- Using Transport Layer Security (TLS) to Secure QUIC
- Hypertext Transfer Protocol (HTTP) over QUIC
運用や適応性に関する下記の2つのドキュメントを同様に2018年11月にIESGに提出する予定になっています
これらのWGアイテムとなっているドキュメントはGithub上で確認できます
https://github.com/quicwg
また、十分な品質の仕様を策定するために初期バージョン(V1)で盛り込む機能は必要なものだけとなり、対応するアプリケーションもまずHTTPだけを目標としています。もちろん、将来をみすえて標準化を行っており、将来盛り込む機能の妨げにならないように注意しながら標準化は進められています。
今回スコープ外になっている機能
- 冗長データからパケットロスを回復するFEC機能
- 複数経路を用いた MultiPath通信 (Multipath Extension for QUIC)
- ビデオなどリアルタイム通信で信頼性が低い場合のストリーム機能(Partially Reliable Streams for QUIC)
- その他 マルチキャストQUICなど様々な提案が出ている
(ECN in QUICは議論継続中)
アプリケーションプロトコルはHTTPをメインターゲットとしているので、すでに提案としてある以下のプロトコルは、すぐには標準化されないでしょう
- RTP over QUIC
- [Specification of DNS over QUIC] (https://tools.ietf.org/html/draft-huitema-quic-dnsoquic)
また、W3CのORTC側でもQUICのAPIが策定されているが今後変わる可能性がある
今後の予定
仕様の品質をあげるために、相互接続テストとIETF本会合(年3回)の間にQUIC WGの中間会合を実施していく事になっています。
来週の1/22~25までオーストラリアで実施されます。アジェンダはすでに公開されています( https://github.com/quicwg/wg-materials/blob/master/interim-18-01/agenda.md )
相互接続テストおよび、多くの重要なトピックがアジェンダに上がっているので、ここで大きく進展するものと思われる。
その後、3月に本会合であるIETF101がロンドンで行われる予定になっているが、アジェンダはまだ公開されていない。
トピック
幾つか最近のトピックを紹介する。沢山有るのでほとんどは書ききれていない
ヘッダ圧縮
HTTP/2ではヘッダ圧縮にHPACKという仕組みを使っている。HPACKではテーブル操作をするため、パケットは送信側から受信側へ順番通り届く必要がある。QUICではUDPであり届いた順から処理できるはずだが、HPACKを使う都合上ロスしたパケットの回復待ちが発生してしまう。
QUIC用ヘッダ圧縮方式として、幾つかの提案が出ておりこれから議論をへて決定される見込み
- QCRAM Header Compression for HTTP over QUIC
- QMIN: Header Compression for QUIC
- QPACK Header Compression for HTTP/QUIC
Invariants
Version-Independent Properties of QUIC
将来のバージョンのQUICをデプロイしやすくするため、ロングヘッダで将来的にも変更されないフィールドを定義しておく。たとえば、バージョンネゴシエーションに関する領域などは将来的にも変更されないようにしておく。
こうすることで、ファイアウォールなどが将来のバージョンのQUICで誤作動しにくくしている。
また、DTLS・STUNなどを同一ポートでMultiplexingする時の問題も知られており考慮されることだろう(URL)
上記に加えさらにバージョンに対応してる場合のみパケットの領域が見えるようにする仕組みの議論も行われている。
More Apparent Randomization for QUIC
SpingBit
The Addition of a Spin Bit to the QUIC Transport Protocol
経路上のネットワーク機器は通信のRTTを測定し最適化している場合があります。
QUICではACKといった制御情報も暗号化されるため、経路上からRTTやパケットロスを測定することは出来ません。
そこで、経路上に1bit露出しパケットを往復するたびにそのbitをトグルする。そのビットを経路上で観測することによってRTTを推定できるように変更する提案。
RTTの測定可能性とプライバシーへの影響を考慮して導入される見込みとなっている。
その他
ミーティングの資料と議事録はGithub上で公開されている
https://github.com/quicwg/wg-materials
多くの議論はML上で行われている
https://mailarchive.ietf.org/arch/search/?email_list=quic