【実務・中級編】QUICのパケットロス回復(Loss Recovery) – HTTPプロトコル・通信規格実践ガイド

TCPの亡霊を振り払え：QUICの「ロス回復」が変えるWebのリアルな挙動

TCPがインターネットを支配して数十年。我々は「パケットが失われたら、とりあえず待つ」というTCPの生真面目すぎる性格に、長らく付き合わされてきました。しかし、HTTP/3の心臓部であるQUICプロトコルは、その前提を根底から覆します。

今日は、インフラエンジニアとして避けて通れない、しかし教科書では決して教えてくれない「QUICのパケットロス回復（Loss Recovery）」という現場の深淵に触れてみましょう。

TCPの「HOLブロッキング」という呪縛からの解放

まず、なぜQUICがUDPベースなのか。それは、TCPの「1つのパケットの欠落が、後続のすべてのストリームを止める」というHead-of-Line (HOL) ブロッキングという呪縛を断ち切るためです。

QUICでは、各ストリームが独立して扱われます。パケットが1つ消えたとしても、そのパケットを含むストリーム以外は影響を受けません。これが実現できるのは、QUICがトランスポート層の再送制御を、OSのカーネルではなく「ユーザー空間のプロトコルスタック」で完結させているからです。

パケットロスをどう検知するか：タイマーとSACKの連携

QUICのパケットロス回復メカニズムは、主に「タイマー」と「ACK（受信確認）」の2つのアプローチで構成されています。

1. Packet Threshold（パケット閾値）

QUICは、受信側から送られてくるACKフレームを監視します。もし、パケット番号 `N` が未到達の状態で、`N+3` のパケットが届いたと認識された場合、QUICは「`N`はロストした」と即座に判断します。この閾値（デフォルトでは3）は、ネットワークのジッターを考慮しつつ、TCPよりも遥かに高速にロスを検知するための工夫です。

2. Tail Loss Probe (TLP)

通信の最後尾でパケットを失うと、ACKが返ってこないため、タイムアウトを待つしかありません。QUICのTLPは、あえて「プローブ用パケット」を送信することで、相手側にACKを強制的に発行させます。これにより、最終パケットのロスを最小限のオーバーヘッドで検知します。

現場で役立つ確認方法：curlで「生の挙動」を見る

理屈はわかった。では、目の前のサーバーがQUICで通信しているとき、パケットロスがどう処理されているかを確認するにはどうすればいいか。最も手軽なのは、`curl`を使ってQUICのヘッダー情報をダンプすることです。

–http3を指定し、詳細な情報を取得する
QUICコネクションの統計情報を見るために –trace-ascii を使うのがコツ
curl -I –http3 https://your-api-server.com/ –trace-ascii dump.txt

dump.txt内の「Connection state」を確認すると、
再送発生時のフレーム制御や、ACKのシーケンス番号の飛びが確認できます。

もし、あなたがAPI開発者で、特定のネットワーク環境下でパケットロスが頻発しているなら、Pythonの`aioquic`ライブラリを使って、あえてパケットをドロップさせるテストコードを書くことをお勧めします。

aioquicを使ったロス発生のシミュレーション（概念コード）
from aioquic.quic.connection import QuicConnection

再送タイマーの振る舞いをログ出力し、意図的にロスさせるデバッグ
def handle_packet_loss(connection: QuicConnection):
# 特定のパケット番号を隠蔽して、Loss Recoveryの挙動を観測する
# RFC 9002 (QUIC Loss Recovery) に基づくタイマー推移を確認
print(f”現在の再送タイムアウト値: {connection._loss.retransmission_timeout}”)

パラメーターチューニングの「罠」

インフラ担当者が陥りがちなのが、`Max Ack Delay` や `Initial RTT` の過度な最適化です。

Max Ack Delay: これを小さくしすぎると、クライアントからのACKが頻発し、アップリンク側の輻輳を招きます。
Initial RTT: サーバー側でこれを小さく見積もりすぎると、接続確立直後に「パケットが届いていない」と誤認し、不要な再送が雪崩のように発生します。

現場の知見： 特にモバイル環境を考慮する場合、QUICのパラメータはデフォルトが最も優秀に設計されています。無理にチューニングする前に、`qlog`（QUICの標準的なログ形式）を出力し、Wiresharkでパケットのシーケンス番号の「欠落」と「再送パケット番号」を突き合わせることから始めてください。

まとめ：ネットワークは「生き物」である

QUICのパケットロス回復は、単なるエラー訂正アルゴリズムではありません。ネットワークという不確実な環境下で、いかに「ユーザー体験を止めないか」という執念の結晶です。

もしあなたがAPIのレスポンス遅延に悩んでいるなら、TCPの再送ログを見る前に、QUICのコネクションが「どのタイミングで再送を行っているか」を追ってください。そこには、パケットが消えた理由（バッファ溢れなのか、無線環境の瞬断なのか）が必ず刻まれています。

技術は常に進化しますが、パケットの挙動を追いかける泥臭いスキルだけは、どんな時代でも最強の武器になります。次回の運用会議では、ぜひ「TCPなら死んでいた通信が、QUICのおかげで救われた」という実例を、皆さんの手で報告してみてください。