RFC 9000: QUIC

このRFCが決めたこと

横にスクロール

RFC 9000（2021年5月）は、UDPの上に構築された汎用トランスポートプロトコルQUICを定義した文書だ。Googleが実験的に展開していたプロトコルを母体にIETFで再設計されたもので、ストリーム多重化・TLS 1.3による暗号化・接続移行までをひとつのプロトコルとして一体設計し、TCPが数十年かけて積み上げてきた機能を別の形で作り直した。

QUICの標準は4本のRFCで構成される。中核のRFC 9000がコネクションとストリームの仕組みを、RFC 9001がTLS 1.3との統合を、RFC 9002が損失検出と輻輳制御を、RFC 8999がバージョンに依存しない不変部分を定める。翌2022年6月には、QUICを前提に再設計されたHTTP/3がRFC 9114として発行された。

なぜUDPの上に作ったのか。TCPはOSカーネルに実装されているため、新機能が全端末に行き渡るまでに何年もかかる。さらに経路上のルータやファイアウォールがTCPヘッダを覗き、書き換える前提で動いており、プロトコルを変更すると通信自体が壊れる。この「オシフィケーション（硬直化）」を避けるため、QUICはどの環境でも通るUDPを最小限の器として使い、トランスポートの機能一式をユーザー空間のライブラリとして実装できるようにした。カーネルを改修しなくても、アプリケーションの更新だけでプロトコルを進化させられる。

要点の精読

ストリーム多重化がトランスポート層に入った

TCP（RFC 9293）が運べるのは単一のバイト列だ。HTTP/2は1本のTCP接続に複数のストリームを多重化したが、パケットが1つ失われると、TCPは再送が届くまで後続データを（無関係なストリームの分まで）アプリケーションに渡せない。これがトランスポート層のヘッドオブラインブロッキングだ。

QUICはストリームをトランスポート層そのものの概念にした。各ストリームは独立した順序空間を持ち、あるストリームのパケットが失われても、他のストリームのデータは到着し次第アプリケーションへ渡される。損失の影響が当該ストリームだけに閉じる。

TLS 1.3統合による1-RTT/0-RTT接続確立

従来のHTTPSは、TCPの3ウェイハンドシェイクで1往復、その上のTLS 1.3（RFC 8446）でさらに1往復、計2-RTTを要した。QUICはトランスポートとTLSのハンドシェイクを一体化し（RFC 9001）、初回接続でも1-RTTで暗号化済みのアプリケーションデータを送り始められる。さらに一度接続したサーバーへの再接続なら、最初のパケットにデータを同乗させる0-RTTも使える。

TCP + TLS 1.3 : SYN → SYN/ACK → ACK → TLSハンドシェイク → データ（計2-RTT）
QUIC 初回     : Initial(ClientHello) → 応答 → データ（1-RTT）
QUIC 再接続   : Initial + 0-RTTデータ → 応答（0-RTT）

コネクションIDによる接続移行

TCPの接続は送信元・宛先のIPアドレスとポートの4タプルで識別されるため、Wi-Fiからモバイル回線に切り替わってアドレスが変わった瞬間に接続は切れる。QUICは接続をコネクションIDという識別子で管理する。経路やアドレスが変わってもコネクションIDが継続していれば同じ接続として扱われ、スマートフォンが自宅のWi-Fiを離れてもダウンロードや通話は張り直しなしで続く。なお移行先アドレスの正当性はパス検証で確認することが必須とされ、なりすましによる乗っ取りや、偽装アドレスへトラフィックを反射させる攻撃を防いでいる。

パケット番号は再送でも増え続ける

TCPのシーケンス番号はバイト位置を表すため、再送セグメントは元と同じ番号を持つ。届いたACKが元の送信と再送のどちらへの応答なのか区別できず、RTT測定が曖昧になる（再送曖昧性）。QUICのパケット番号は送信のたびに増え続け、失われたデータの再送も新しい番号の新しいパケットとして送られる。どの送信に対するACKかが常に一意に定まるため、RTT標本が正確になり、RFC 9002の損失検出と輻輳制御はこの土台の上に組み立てられている。

ほぼ全体が暗号化され、中間装置から見えない

TCPではシーケンス番号やフラグが平文で流れるため、中間装置がそれに依存した処理を積み重ね、結果としてプロトコルの進化を止めてきた。QUICはペイロードだけでなく、ACKや制御情報を含むパケットのほぼ全体を暗号化し、パケット番号すらヘッダ保護で隠す。ネットワークから観測できるのは、コネクションIDやバージョンなど、RFC 8999が不変と定めたごく一部にすぎない。中間装置が中身に依存できない構造にしたこと自体が、将来の変更可能性を守る設計になっている。

つまずきやすい点

まず、QUICはHTTP/3専用ではない。RFC 9000は汎用トランスポートであり、HTTP/3（RFC 9114）は最初の代表的な利用者にすぎず、DNS over QUIC（RFC 9250）のように他プロトコルの土台にもなっている。次に、0-RTTはリプレイ攻撃を前提に使う必要がある。攻撃者は盗聴した0-RTTパケットを複製して再送信できるため、そこに載せてよいのは再生されても害のない操作（HTTPなら安全なメソッド）に限られる。

また、UDPを遮断するネットワークは現実に存在する。そのためブラウザはHTTP/3への対応をAlt-Svcヘッダなどで知り、つながらなければTCPベースのHTTP/2以下へフォールバックする（HTTPのバージョンを参照）。最後に、コネクションIDはロードバランサと相性問題を起こす。4タプルが変わっても接続が続くため、アドレスベースの分散では移行後のパケットが別のサーバーに届いてしまう。コネクションIDに振り分け情報を埋め込むなど、QUICを理解した分散設計が必要になる。

まとめ

RFC 9000は、カーネルと中間装置に固定されて動けなくなったTCPの機能群を、UDPの上でユーザー空間に作り直した再出発だ。多重化・1-RTT接続・接続移行を標準装備にしたうえで、ほぼ全体の暗号化によって進化の自由まで確保した点にこのRFCの本質がある。関連するRFCの解説はRFC精読から辿れる。