QUICが書き換えるパケットロスの哲学：HTTP/3におけるACKフレームと極限の再送制御
インターネットの底流を支え続けてきたTCPは、偉大なプロトコルである。しかし、現代のモバイル環境や、数パーセントのパケットロスが日常茶飯事である無線ネットワークにおいて、TCPの「信頼性」の代償はあまりにも重かった。その最たるものが、かの有名な「Head-of-Line（HoL）ブロッキング」だ。
TCPはバイトストリームを厳格な順序で処理する。ひとつのセグメントが途中でドロップすると、その背後にあるすべてのデータはOSのソケットバッファで足止めを食らう。再送パケットが到着するまで、アプリケーション層は1バイトたりともデータを受け取ることができない。
この呪縛を断ち切るために登場したのが、UDPをベーストランスポートとして採用し、その上部にトランスポート層とセキュリティ層（TLS 1.3）を統合したQUIC、そしてそれをベースとするHTTP/3である。
今回は、QUICがパケットロスいかに立ち向かうか、その核心である「選択的確認応答（Selective ACK）」と、パケットレベルの厳密な挙動、そして現場のアーキテクトが知るべきチューニングの作法について深く潜っていく。
—
1. 忘却からの脱却：QUICパケット番号空間とACKフレームの構造
TCPの確認応答（ACK）は、基本的に「累積確認応答（Cumulative ACK）」をベースにしている。TCPのACK番号は「次に受信すべきシーケンス番号」を示しており、一部のパケットが欠落した場合、受信側はそれ以降に届いたパケットを保持しつつも、送信側に対して「ここが抜けている」という正確な位置を伝えるにはSACK（Selective ACK）オプションという複雑な拡張に頼らざるを得なかった。
一方、QUICの設計思想は根本から異なる。
パケット番号の単調増加と暗号化スペース
QUICでは、すべてのパケット（再送不可能なAcknowledgment専用パケットなどを除く）に単調増加するパケット番号（Packet Number）が付与される。特筆すべきは、このパケット番号が暗号化スペース（Encryption Level: Initial, Handshake, Application Data）ごとに独立して管理される点だ。
TCPのように「ロストしたセグメントと同じシーケンス番号で再送する」というアプローチをとると、暗号解析上の脆弱性や、古いパケットと新しいパケットの混同（Wrapped Sequence Number問題）のリスクが生じる。QUICでは、再送されるパケットは「全く新しいパケット番号」を付与されて送信される。しかし、内部のフレーム（STREAMフレームなど）は元のデータを維持しているため、受信側はどのデータストリームのどのオフセットであるかを正確に再構築できる。
ACKフレームの解剖
QUICのACKフレームは、単なる「ここまで届いた」という通知ではない。極めて効率的なビットマップとレンジ指定によって構成されている。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Type (0x02 or 0x03) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acknowledged (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Delay (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Delay Exponent (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Range Count (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Acknowledgment Range (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Repeated Ack Ranges…] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
この構造により、受信側は「パケット #100 から #110 までが届き、#111 と #112 が抜け、#113 から #120 までが届いた」という複雑な飛び石状態を、わずか数バイトのACKフレームで送信側に伝達できる。送信側は、この情報を元に「どのパケットが実際にロスしたのか」を推測ではなく確信を持って特定する。
—
2. パケットロス発生時の再送制御と「疑似輻輳」の回避
TCPにおけるパケットロス検出は、主に「3回の重複ACK（Fast Retransmit）」か「RTO（Retransmission Timeout）タイマーの満了」に依存している。しかし、パケットロス率が高い劣悪な無線環境では、重複ACK自体がロスしたり、RTTの揺らぎによって時期尚早なRTO（Spurious Timeout）が発生し、本来は流せるはずの帯域を不当に絞ってしまうという悪循環に陥りがちだ。
QUICでは、これに対してより洗練されたメカニズムを実装している。
空間的・時間的ロス検出の分離
QUICは、RFC 6675で定義されるような高度なロス検出アルゴリズムを標準で内蔵している。具体的には以下の2つのトリガーでロスを判定する。
1. パケット閾値（Packet Threshold）:
あるパケットよりも3つ以上大きいパケット番号が正常に確認応答された場合、その間に挟まれた未確認のパケットは「ロスした」とみなされる。この閾値（`kPacketThreshold` = 3）はTCPのFast Retransmitの思想を受け継いでいるが、QUICのパケット番号空間の明確さにより、誤判定が極めて少ない。
2. 時間閾値（Time Threshold）:
パケット番号ベースの閾値に達していなくても、最新のRTT計測値に基づいて計算された一定の時間（例: `max(4 latest_rtt, kGranularity)`）が経過した場合、ロスとして判定される。これにより、バースト的なロスの末尾で新しいパケットが届かない状況でも、迅速に再送をトリガーできる。
ロスしたストリームデータのみの独立した再送
ここがHTTP/3（QUIC）の真骨頂である。
もしTCP上で動画データとAPIリクエストを多重化（HTTP/2）していた場合、動画データのパケットが1つロスすると、同一TCPコネクション上のAPIリクエストの到着まで遅延していた。
しかしQUICでは、トランスポート層の上にある「QUICストリーム」が独立している。
仮にストリームID: 0（動画データ）のパケットがロスし、その再送を待っている最中であっても、ストリームID: 4（APIリクエスト）のデータを含むパケットは、全く別のQUICストリームとして何事もなかったかのようにアプリケーション層へ引き渡される。HoLブロッキングは、もはやネットワーク層・トランスポート層から完全に駆逐されているのだ。
—
3. ゼロRTTハンドシェイクと暗号化の極限最適化
パフォーマンスを語る上で、コネクション確立のオーバーヘッドを無視することはできない。従来の「TCP 3-wayハンドシェイク ＋ TLS 1.3 フルハンドシェイク」の組み合わせでは、データを1バイトも送信する前に、最低でも 2.5往復（2.5 RTT） の遅延が発生する。
HTTP/3（QUIC + TLS 1.3）は、このレイテンシを劇的に圧縮する。
[従来のTCP + TLS 1.3]
Client Server
|— SYN (1) —————–>|
|<-- SYN-ACK (1) --------------|
|--- ACK / Client Hello (2) -->|
|<-- Server Hello / Enc (2) ---|
|<-- Finished (3) -------------|
|--- HTTP Request -------------> (合計 2.5 ～ 3 RTT)
[QUIC + TLS 1.3 (0-RTT)]
Client Server
|— Initial (Client Hello) —|
|— 0-RTT (Encrypted Data) –>| (合計 0 RTT でアプリケーションデータ送信可能！)
|<-- Handshake / Server Hello -|
|<-- Application Data (1-RTT) -|
初回接続時であっても、QUICはUDPハンドシェイクとTLS 1.3の鍵交換を巧みにオーバーラップさせ、1 RTTで暗号化されたセッションを確立する。
さらに、一度接続実績のあるサーバーに対しては、前回のセッションチケット（Session Ticket）やトランスポートパラメータをキャッシュしておくことで、0-RTT（ゼロ往復遅延）でのデータ送信が可能になる。ユーザーがブラウザのURLバーにアドレスを入力したその瞬間に、暗号化されたHTTPリクエストをパケットに乗せて発射できるのである。
—
4. ヘッダー圧縮のパラダイムシフト：QPACKの内部挙動
HTTP/2では「HPACK」という画期的なヘッダー圧縮アルゴリズムが導入された。しかし、HPACKは「ヘッダーの順序を厳格に維持して復元する」という性質上、パケットロスが発生して前のパケットが届かない場合、後続のパケットにあるヘッダーすら復元できなくなるという「HPACKのHead-of-Lineブロッキング」を引き起こすジレンマを抱えていた。
HTTP/3はこの課題を解決するためにQPACKを採用している。
QPACKの二つのテーブルと「インデクシング」
QPACKは、静的テーブル（Static Table：RFCで定義された共通の99個のエントリ）に加え、動的テーブル（Dynamic Table）をエンコーダーとデコーダーの両方で維持する。しかし、HPACKとの決定的な違いは、「パケットロスによる順序逆転に耐える仕組み」にある。
- プレフィックスとしての制御ストリーム:
QPACKでは、動的テーブルの更新情報を伝えるために、通常のHTTPリクエストを送るストリームとは完全に独立した制御ストリーム（Control Stream）を使用する。
- 絶対インデックス（Absolute Indexing）:
動的テーブルのエントリには、順序に依存しない絶対インデックスが付与される。受信側は、仮にデータパケットがロスしていても、制御ストリーム経由でテーブルの更新情報が確実に届いていれば、欠落したパケットの到着を待たずに安全にヘッダーをデコードできる。
もし動的テーブルのエントリがまだ手元に届いていない場合は、HTTP/3層で一時的に処理を保留するか、あるいは参照を避ける仕組み（インデックスなしリテラル表現の活用など）によって、トランスポート層のメリットをスポイルしない工夫がなされている。
—
5. 実務のためのチューニングとセキュアな運用作法
ここまで理論を見てきたが、実際のLinuxサーバー環境でHTTP/3 / QUICを爆速で稼働させるためには、カーネルパラメータやネットワークスタックのチューニングが不可欠である。特に、QUICはUDPベースであるため、デフォルトのLinuxネットワーク設定のままだと、思わぬボトルネックに直面する。
以下の実務的な設定例と、パフォーマンス・セキュリティ両面からの注意点を確認してほしい。
Linuxカーネルパラメータの最適化（sysctl.conf）
UDPスループットを最大化し、バッファあふれを防ぐための設定例。
/etc/sysctl.d/99-quic-tuning.conf
UDP受信バッファの最大サイズを拡大 (デフォルトでは小さすぎて高スループット時にパケットロスが発生する)
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
UDP送信バッファの最大サイズを拡大
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
ネットワークデバイスの入力キューの最大長を増加 (バースト的なトラフィック対策)
net.core.netdev_max_backlog = 10000
ソケットごとの最大メモリ割り当て量を増加
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
> 技術解説:
> QUICはアプリケーション空間（あるいは先進的なkernel-bypass/eBPF実装）でパケット処理を行うことが多いが、標準的なNginx + ngtcp2 や Caddy などの環境では、OSのUDPソケットバッファ（`rmem_max` / `wmem_max`）のサイズがスループットの頭打ちを決定づける最大の要因になる。特に高帯域・高遅延（High BDP）環境では、ここを大きく見積もっておく必要がある。
セキュリティ面での注意点：UDPリフレクション攻撃とGSO/GRO
UDPをベースとするQUICは、DDoS攻撃（特にUDPリフレクション攻撃やアンプリフィケーション攻撃）の踏み台にされるリスクを内包している。
1. アドレス検証（Address Validation）:
QUICサーバーは、クライアントからの最初の `Initial` パケットを受け取った際、送信元IPアドレスが偽装されていないかを検証するため、トークン（Token）を含んだ `Retry` パケットを返すことがある。これを適切に有効化（あるいはアプリケーション側で設定）することで、リフレクション攻撃の踏み台になるリスクを大幅に軽減できる。
2. GRO (Generic Receive Offload) / GSO (Generic Segmentation Offload) の活用:
CPU負荷を激減させるため、NICドライバレベルでUDPのGSO/GROが有効になっていることを確認せよ。
# NICのUDP GSO/GROの状態確認
ethtool -k eth0 | grep -E ‘generic-receive-offload|generic-segmentation-offload’
これが無効な場合、カーネル空間でのパケット処理コストが急増し、CPUバウンドなボトルネックを引き起こす原因となる。
—
結びにかえて
HTTP/3とQUICがもたらしたパラダイムシフトは、単に「HTTPが速くなった」というレベルの話ではない。それは、30年近くインターネットを支配してきたTCPという呪縛からトランスポート層を解放し、アプリケーションの要請に応じた「真のマルチプレクシングと選択的再送」を勝ち取るための戦いであった。
パケットロスを恐れないプロトコルではなく、「パケットロスを前提として、その影響を極限まで局所化する」こと。これこそが、現代のインフラアーキテクトが理解し、使いこなすべきネットワークの新しい哲学なのだ。
コメント