HTTP/3の心臓部：QUIC STREAMフレームが制御する「順序なき信頼性」の深淵
TCPの時代、私たちは「パケットの順序」という呪縛に縛られていた。ヘッド・オブ・ライン・ブロッキング（HOLB）という名の悪魔は、たった一つのパケットロスで後続の全ストリームを停止させた。しかし、QUICプロトコルはそのパラダイムを根本から破壊した。
今回は、HTTP/3のパケットレベルで最も重要かつ、インフラエンジニアが理解しておくべき「STREAMフレーム」のオフセットと再送ロジックについて、現場の視点から掘り下げていこう。
1. STREAMフレームの構造とオフセットの魔力
QUICのSTREAMフレームは、UDPの上で「信頼性」をエミュレートするための最小単位だ。TCPがストリーム全体をシーケンス番号で管理するのに対し、QUICは各ストリームが独立したオフセットを持つ。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (i) | Stream ID (i) | [Offset (i)] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] | Data (..) …
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
この「Offset」フィールドこそが、HTTP/3の高速化の鍵だ。受信側は、届いたパケットがストリームのどの位置にあるかを即座に判別する。もし、中間のパケットが欠落しても、QUICのスタックはストリームを止めない。届いた順にバッファへ配置し、欠落したオフセットを待ちつつ、届いたデータは上位レイヤーへ即座に引き渡す。これがQUICによるHOLB回避の物理的な正体である。
2. 順序保証と再送のメカニズム：OSカーネルの深部
TCPでは、カーネルの`tcp_input.c`がシーケンス番号をガチガチに管理するが、QUICはユーザー空間（あるいは特殊なカーネル実装）でこの再送制御を行う。
ここで重要なのは、「ACKフレーム」の設計だ。QUICは累積ACKだけでなく、ギャップ情報を含めたACKを送信する。再送が必要と判断された際、QUICスタックは失われたオフセット範囲を特定し、新しいパケットとして再送するが、ここで興味深いのは「元パケットと同じIDである必要はない」という点だ。
パケット再送の最適化コード（概念モデル）
// 疑似コード: QUICパケットの再送判断ロジック
void on_packet_lost(packet_t lost_pkt) {
// 失われたオフセット範囲を特定
uint64_t start = lost_pkt->offset;
uint64_t end = lost_pkt->offset + lost_pkt->length;
// 新しいパケット番号を割り当てて再送
// 重要なのは、元のパケットIDではなく新しいパケットIDで送信すること
// これにより、ACKの混同（Retransmission Ambiguity）を完全に回避する
send_stream_frame(stream_id, start, end, data_buffer + start);
}
この「新パケットIDでの再送」は、TCPの再送タイマー問題（Karn/Partridgeアルゴリズムの複雑さ）を過去のものにした。インフラエンジニアとしては、この再送がUDPの輻輳制御（CUBICやBBRv2）とどう連動するかを注視すべきだ。
3. RTT削減と0-RTTハンドシェイクの罠
HTTP/3の目玉である0-RTTは、前回の通信で得た鍵情報（PSK）を使い、最初のパケットから暗号化データを送る。だが、これはセキュリティ上の諸刃の剣だ。「リプレイ攻撃」の耐性を考慮しない実装は、即座にサーバーの脆弱性となる。
- 対策: サーバー側では、0-RTTで受け取ったリクエストに対し、副作用（POSTやPUTなど）を伴う処理を厳格に制限する。
- インフラとしてのチューニング: UDPバッファの拡大は必須だ。`sysctl -w net.core.rmem_max=26214400` のような設定は、高スループット環境ではスタートラインに過ぎない。QUICは多重化されるため、TCPよりも多くのパケットがカーネルの受信キューに滞留する傾向があるからだ。
4. QPACKヘッダー圧縮とストリームの相関
HTTP/2のHPACKは、前後の順序に完全に依存していた。しかし、HTTP/3のQPACKは、ストリームを跨いだデコードの依存性を排除できるよう設計されている。
もし、ストリームAのヘッダーが未到着で、ストリームBのヘッダーが先に届いた場合、QPACKは「Blocking」状態に入る。これを防ぐには、クライアントとサーバー間の「Encoder Stream」と「Decoder Stream」の同期状態を監視する必要がある。大規模な負荷テストを行う際、このデコーダーの詰まりがCPU使用率にどう跳ね返るか、プロファイリングツールで可視化することを強く推奨する。
総括：これからのアーキテクトに求められる視点
QUICとHTTP/3は、単なるプロトコルのアップデートではない。それは、ネットワークスタックの制御権をカーネルからアプリケーションへ奪還する革命だ。
パケットが届かない、オフセットが飛ぶ、再送が止まらない。そんなトラブルに直面したとき、パケットキャプチャのヘッダーを眺めるだけでなく、アプリケーションが保持している`Stream Offset Map`を覗き込む勇気を持ってほしい。そこに、現代のWebの真実が隠されているのだから。
次は、BBRv3を用いたQUICの輻輳制御のチューニングについて、深掘りしていこうと思う。ネットワークの速度は、結局のところ、いかに「正しく待つか」に集約されるのだ。
コメント