【テクニカル・上級編】0-RTT(Zero Round Trip Time)ハンドシェイクの仕組み – HTTPプロトコル・通信規格実践ガイド

パケットは1秒も待てない：HTTP/3とQUICがもたらす「0-RTT」の魔術と、エンジニアが背負うべき代償

ネットワークエンジニアの端くれであれば、SYNパケットを送ってからACKが返ってくるまでのあの数ミリ秒——「RTT（Round Trip Time）」の往復遅延がいかにアプリケーションの体感速度を殺しているか、身をもって知っているはずだ。TCPの3wayハンドシェイクにTLSの鍵交換が重なれば、ユーザーが最初の文字を目にするまでに、光速でさえ地球を何往復もしなければならないほどのオーバーヘッドが生じる。

しかし、HTTP/3とQUICの登場はこの物理法則に真っ向から反逆した。
「過去に会ったことがあるなら、挨拶代わりのパケットと一緒に、本題のデータも送りつけてくれ」——そう言い放つのが、今回スポットを当てる 「0-RTT（Zero Round Trip Time）ハンドシェイク」 だ。

今回は、このパケットレベルの魔術がいかにして実現されているのか、そしてその圧倒的な速度の裏に潜む「リプレイ攻撃」というダークサイドに、プロトコルの深淵から迫っていこう。

—

1. 0-RTTハンドシェイクのパケットレベル内部挙動

従来のTLS 1.3でも「早期データ（Early Data）」として0-RTTの概念は存在したが、TCPの上でそれを実装することは、パケットロスや輻輳制御の観点から常にパンドラの箱を開けるようなものだった。UDPベースのQUICにおいて、0-RTTはその真価を極限まで発揮する。

1-1. 初回接続（1-RTT）で何がキャッシュされるのか？

クライアントが最初にサーバーへ接続する際、通常のQUICハンドシェイク（バージョン交渉、Cryptoフレームの交換など）が行われる。この時、サーバーは将来の再接続のために 「NewSessionTicket（NST）」 と呼ばれる暗号学的チケットをクライアントに発行する。

このチケットには、以下の極めて重要な機密情報が含まれている。

サーバー側のマスターシークレットから派生した resumption_secret
暗号スイートの識別子
サーバーが認可した暗号パラメータ（ALPNなど）

クライアントはこのNSTをローカルのセッションキャッシュに大切に保管し、同じサーバーへの「2回目以降の接続」に備える。

1-2. 0-RTTパケットの飛翔（ゼロ往復の現実）

ユーザーが再びそのオリジンサーバーへリクエストを送ろうとした瞬間、クライアントはサーバーからの応答を待つことなく、以下のパケット群を1つのUDPデータグラムに詰め込んで容赦なく送出する。

1. QUIC Initial / Handshake パケット: 新しい接続IDの確立と、TLS 1.3のClient Hello。
2. 0-RTT Protected Packet: キャッシュしておいた `resumption_secret` から即座に生成した暗号鍵（0-RTT Key）でスクランブルされた、実際のHTTP/3リクエスト（HEADERSフレームやGETメソッド）。

[Client] [Server]
|—- (1) Initial (Crypto: ClientHello) ———————->|
|—- (2) 0-RTT Packet (Encrypted HTTP/3 GET Request) ——->| (即座に処理開始！)
| |
|<--- (3) Handshake (Crypto: ServerHello / Finished) ----------| |<--- (4) 1-RTT (Encrypted Response / NewSessionTicket) -------| サーバーは、まだハンドシェイクが完了していなかろうが、手元にある秘密鍵で `resumption_secret` を復元できれば、UDPペイロードの暗号を即座に解読し、バックエンドのアプリケーション層へリクエストを流し込むことができる。サーバー側からすれば、「まだ身元確認は途中だが、お前の顔パス（チケット）は本物だ。先に仕事を始めてやる」という状態だ。 ---

2. 実装の壁：リプレイ攻撃という致命的な脆弱性

ここで、セキュリティエンジニアとしての警鐘を鳴らさなければならない。
0-RTTは「過去に送られた暗号化されたパケットを、悪意ある第三者がそのままコピーして再送する（Replay）」という攻撃に対して、構造的に無防備である。

なぜTCPでは起きにくく、QUIC/0-RTTで致命的なのか？

TCPのハンドシェイクや通常のTLS接続では、チャレンジ＆レスポンスの仕組みやシーケンス番号の厳密な同期があるため、古いパケットの単純な再送はトランスポート層で弾かれるか、ハンドシェイクの段階で破棄される。

しかし、0-RTTで送られるデータ（Early Data）は 「サーバー側でまだ検証が完了していない過去のセッション情報」 を使って暗号化されている。もし攻撃者が、クライアントが最初に送った「決済ボタンを押したときの0-RTTパケット（例: `POST /buy?item=123`）」を傍受し、全く同じものを数百万回送りつけたとしたらどうなるか？

サーバーがこのリクエストを「冪等（Idempotent）ではない」重要処理（決済、データ削除、アカウント作成など）として愚直に処理してしまった場合、システムは崩壊する。

サーバー側の防衛策：アンチ・リプレイの実装

この脅威に対抗するため、ハイパフォーマンスなQUICサーバー（Nginx, Envoy, あるいはCloudflare等のEdge環境）は、以下のいずれかの、あるいは複合的なアンチ・リプレイ機構を備えている必要がある。

1. タイムスタンプ検証: チケットの発行時刻と0-RTTパケットの受信時刻の差が許容範囲（数秒以内）であることを確認する。ただし、クライアントの時計のズレに弱い。
2. ステートフルなチケットID追跡（Single-Use Tickets）: サーバークラスター全体で共有される分散KVストア（Redisなど）を使い、「一度使われた `resumption_secret` やチケットID」を即座に無効化・ブラックリスト化する。しかし、大規模分散環境においてすべてのノード間でミリ秒単位の同期を取ることは、可用性（CAP定理）とのトレードオフになる。

—

3. インフラ・カーネルチューニング：UDPの限界を超える

HTTP/3の0-RTTを実運用で限界まで活かすためには、アプリケーション層の手前、Linuxカーネルおよびネットワークインターフェースのチューニングが不可欠である。TCPからUDPへのパラダイムシフトは、インフラエンジニアに全く新しい負荷特性をもたらす。

3-1. GRO / GSO によるパケット処理のオフロード

QUICはUDPベースであるため、デフォルトのままではパケット数が膨大になり、カーネルのCPU割り込み（SoftIRQ）が即座に天井に張り付く。これを回避するためには、Linuxカーネルの GSO（Generic Segmentation Offload） と GRO（Generic Receive Offload） を有効化し、NICレベルでパケットを束ねて処理させる必要がある。

NICのUDP GSO/GRO機能が有効か確認し、必要に応じて設定する例
sudo ethtool -K eth0 rx-udp-gro-forwarding on
sudo ethtool -K eth0 tso on gso on

3-2. Linuxカーネルパラメータ（sysctl）の最適化

高スループットかつ多数の0-RTT接続を受け入れるサーバーでは、UDPのソケットバッファサイズを大幅に拡張しておかなければ、バッファあふれ（Dropped packets）による再送の嵐に見舞われる。

以下の設定を `/etc/sysctl.d/99-quic-tuning.conf` などに記述し、適用してほしい。

受信UDPソケットバッファの最大値（バイト単位。32MBに設定）
net.core.rmem_max = 33554432

送信UDPソケットバッファの最大値（32MBに設定）
net.core.wmem_max = 33554432

デフォルトのソケットバッファサイズ
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576

ネットワークデバイスの入力キューの最大長（大量のUDPパケットをドロップさせないため）
net.core.netdev_max_backlog = 10000

> Architect’s Note:
> チューニングの際は、単にバッファを大きくするだけでなく、サーバーのRAM容量とコネクション数（`ulimit -n`）のバランスを常に監視すること。UDPはTCPのようなフロー制御を自前で持たないため、カーネルバッファがあふれた瞬間にパケットが容赦なく捨てられる。

—

4. 0-RTTを安全に使いこなすための設計哲学

ここまで読み進めた読者であれば、0-RTTが「魔法の杖」ではなく、速度と安全性の絶妙なバランスの上に成り立つ「諸刃の剣」であることが痛いほど理解できたはずだ。

実務の現場において、HTTP/3の0-RTTを有効化（例：Nginxの `quic_retry` や Envoyの `transport_socket` 設定）する際には、以下の鉄則を守るべきである。

GET / HEAD などの冪等なリクエストに限定する: 決済やデータ更新を伴う `POST / PUT / DELETE` などのリクエストについては、アプリケーション層（あるいはプロキシ層）で0-RTT経由のペイロードを意図的にブロックするか、厳密なべき等性キー（Idempotency-Key）を強制する。
セッションキャッシュの寿命を適切に絞る: チケットの有効期限（Lifetime）を数時間〜数日に設定しすぎると、漏洩したチケットが悪用されるウィンドウが広がる。セキュリティとUXのスイートスポットを見極めよ。

パケットが光の速度でネットワークを駆け巡る現代において、0-RTTはユーザー体験を極限まで高めるための強力な武器だ。しかし、その裏側にある暗号学的メカニズムとOSカーネルの挙動を正しく理解しコントロールできて初めて、真のプロこと呼べる。さあ、今すぐあなたのインフラストラクチャのパケットキャプチャを開き、最初のUDPデータグラムがどのように世界と対話しているかを確認してみよう。