［HTTP/3深掘り］TCPの呪縛を解き放て！QUICのACKフレームとパケットロス回復のリアル
こんにちは。ネットワークとプロトコルの泥臭い世界に身を置いて早幾年、数々の夜間障害や不可解なスループット低下と格闘してきたシニアエンジニアの私です。
Web APIの設計や大規模インフラの運用に携わる皆さんなら、日頃から「いかにレイテンシーを削り、パケットロスに強い通信基盤を作るか」に神経をすり減らしていることでしょう。HTTP/2でマルチプレクシングが実用化され、見かけ上の「ヘッド・オブ・ライン（HOL）ブロッキング」は解消されたかに見えました。しかし、その下層で支えるTCPの仕様そのものが持つ「単一の順序保証ストリーム」という呪縛は、依然として私たちを苦しめ続けてきました。
無線LANやモバイル回線など、パケットロスが日常茶飯事の現代において、TCPの「1つのパケットが消えただけで、後続の全データがバッファで足止めを食らう」挙動は、もはや足かせでしかありません。
そこで登場したのが、UDPベースのトランスポート層プロトコル「QUIC」を土台とするHTTP/3です。今回は、そのHTTP/3の心臓部であり、パケットロス耐性の要である「QUICのACKフレームと選択的確認応答、そして再送制御のリアルな挙動」について、現場の視点から徹底的に解剖していきましょう。
—
1. なぜTCPのACKはダメだったのか？（復習と課題）
まずは、私たちが長年付き合ってきたTCPのACK（確認応答）の限界を振り返っておく必要があります。
TCPのACKは「累積確認応答（Cumulative ACK）」が基本です。例えば、シーケンス番号 1 から 5 までのパケットを送信したとします。このうちパケット3だけが途中でロストした場合、受信側はパケット4や5を受け取っても、「次に欲しいのはパケット3だ」という旨のACKしか返せません。
送信側: [PKT 1] [PKT 2] [PKT 3 (ロスト)] [PKT 4] [PKT 5]
受信側: ◯ ◯ × ◯ ◯
↓
受信側からのTCP ACK: 「次に欲しいのは PKT 3 です (DUP-ACK)」
送信側は「パケット3が消えた」と判断するまで（あるいはSACKオプションが有効に機能するまでのわずかなタイムラグの間）、後続のデータ処理や輻輳ウィンドウの進捗にモタつきが生じます。これがモバイル環境での「プチフリーズ」やレイテンシー悪化の元凶でした。
—
2. QUICのACKフレームによる「選択的確認応答」の仕組み
HTTP/3の基盤であるQUICは、UDP上で動くにもかかわらず、TCPの良いところ（信頼性・順序保証）を抽出しつつ、根本的な設計思想を刷新しました。その象徴がQUICのACKフレームです。
QUICでは、すべてのパケットに「パケット番号（Packet Number）」が一意に振られますが、TCPとは異なり、パケットロス検知や再送のための番号スペースと、アプリケーションデータの順序保証（ストリームIDとオフセット）が完全に分離されています。
ACKフレームの構造と「Ack Delay（遅延）」
QUICのACKフレームは、単に「ここまで届いた」と言うだけではありません。極めて精緻に、どのパケットが届いて、どのパケットが欠損しているかをビットマップや範囲指定（Ranges）で伝えます。
実際のQUICパケットに含まれるACKフレームの概念的な構造を見てみましょう。
- Largest Acknowledged: 受信側が今回確認した中で最大のパケット番号
- ACK Delay: Largest Acknowledgedを受信してから、このACKフレームを送信するまでに要した時間（RTTの正確な計測に極めて重要）
- ACK Range Count: 連続して受信できたパケットの塊がいくつあるか
- First ACK Range: Largest Acknowledgedから逆方向に、何個連続してパケットが届いているか
- Gap / ACK Range (繰り返しの配列): ロストしたパケットを挟んで、さらに過去にどこまで届いているかの範囲指定
この仕組みにより、受信側は「パケット1、2、4、5は届いたが、3だけが抜けている」という状態を、1つのコンパクトなACKフレームで送信側に正確に伝える（＝選択的確認応答 / Selective ACK）ことができます。
—
3. パケットロス発生時の再送制御アルゴリズムの挙動
では、パケットロスが発生した際、QUICの送信側はどのように振る舞うのでしょうか。ここにTCPとの決定的な違いがあります。
シーケンスで見るQUICのリカバリーフロー
[送信側] [受信側]
| |
|— PKT #10 (Stream A) —————————>| (受信成功)
|— PKT #11 (Stream B) — [× ネットワークでロスト] ->| (未達)
|— PKT #12 (Stream A) —————————>| (受信成功)
| |
| | (PKT #11の欠落を検知)
|<-- ACK (Largest: 12, Ranges: 12-12, 10-10) -------| (選択的ACK送信)
| |
| (PKT #11 のロストを即座に認識！) |
| |
|--- PKT #13 (Stream B 再送用パケット番号) ------->| (リカバリー完了！)
ここで重要なポイントは、パケット11がロストしたにもかかわらず、同じコネクション上で多重化されているStream Aのパケット（#10や#12）の処理や配信が一切ブロックされていないという点です。これがHTTP/3（QUIC）における真のマルチプレクシングです。TCPの時代には、TCPセグメントがロストするとその上の全ストリームが止まっていましたが、QUICではトランスポート層のパケットロスが、論理的なストリーム同士を完全に孤立させています。
新たなパケット番号の付与（Re-transmission vs New Transmission）
実務上、非常に興味深いQUICの仕様として、「再送パケットであっても、元のパケット番号は使い回さず、新しいパケット番号を付与して送る」というルールがあります。
これにより、送信側は「このパケットは初送なのか、それとも再送なのか」をタイムスタンプやパケット番号の空間で一意に識別でき、ACKがどちらに対するものかを混同することがなくなります。輻輳制御（Congestion Control）の計算においても、非常にクリーンなRTO（Retransmission Timeout）の算出が可能になります。
—
4. 実務で役立つ！HTTP/3 & QUICの観測・デバッグ・設定Tips
現場のインフラエンジニアやAPI開発者にとって大切なのは、「仕様を知っていること」ではなく、「いざという時にパケットを覗き、正しく動いているか検証できること」です。
1. curlでHTTP/3（QUIC）の挙動を強制する
手元の環境でHTTP/3が正しく有効化されているか、NginxやCaddyなどのエッジサーバーに対して確認するための鉄板コマンドです。HTTP/3はALPN（Application-Layer Protocol Negotiation）で `h3` を交渉します。
HTTP/3 (QUIC) を強制してリクエストを投げる
※curlがHTTP/3 (nghttp3/quiche等) をサポートしている必要があります
curl –http3-only -I https://api.yourdomain.com/v1/health
レスポンスヘッダに `HTTP/3 200` や、Alt-Svcヘッダが返ってきていることを確認する
2. Python (aioquic) を使ったQUICパケット・ACKの実験的スクリプト
QUICの低レイヤーの挙動や、カスタムクライアントを実装・検証したい場合、Pythonの `aioquic` ライブラリは非常に強力な武器になります。以下に、QUICコネクションを張る最小限のコードスニペットを示します（実務でのプロトコル検証の足がかりとして活用してください）。
import asyncio
from aioquic.asyncio import connect
from aioquic.quic.configuration import QuicConfiguration
async def test_quic_connection():
# QUICクライアントの設定を作成
# 開発環境などの自己署名証明書を検証する場合は verify_mode を調整してください
configuration = QuicConfiguration(is_client=True)
configuration.verify_mode = False # 実運用ではTrueにすること
# エッジサーバーへQUIC (UDP 443) で接続
async with connect(“api.yourdomain.com”, 443, configuration=configuration) as protocol:
print(“QUICコネクションの確立に成功しました！”)
# 内部でStreamを開き、HTTP/3リクエスト等を流す準備を行う
stream_id = protocol._quic.get_next_stream_id(is_local=True)
print(f”新しく割り当てられたーストリームID: {stream_id}”)
# 接続を維持してACKやパケットのやり取りを確認
await asyncio.sleep(2)
if __name__ == “__main__”:
asyncio.run(test_quic_connection())
3. Wiresharkでのパケットキャプチャと復号（Decryption）のコツ
HTTP/3の通信は、TLS 1.3をベースにしたQUICにより完全に暗号化されています。そのため、そのままWiresharkでパケットキャプチャをしても、ペイロードはもちろん、内部のACKフレームの細かな中身まで覗くことはできません。
現場でパケットロスやACKの遅延をデバッグする際は、環境変数に以下を設定し、TLSの秘密鍵（Session Key）をWiresharkに読み込ませるのが鉄則です。
クライアント側（ブラウザやcurl）を実行する前に環境変数を設定
export SSLKEYLOGFILE=/path/to/your/sslkeylog.log
このログファイルをWiresharkの `Preferences -> Protocols -> TLS -> (Pre)-Master-Secret log filename` に指定することで、暗号化されたQUICパケットの内部構造、パケット番号、そしてACKフレームがどのように往来しているかを裸眼で見ることができるようになります。トラブルシューティングの際には必須のテクニックです。
—
まとめ
HTTP/3におけるQUICのACKフレームとパケットロス回復機構は、単なる「TCPのUDP移植」ではありません。「ストリームの独立性」と「精緻な選択的確認応答」を組み合わせることで、ネットワークの揺らぎやロスをアプリケーション層から完全に隠蔽する、極めて洗練されたアーキテクチャです。
私たちが構築・運用するWeb APIやインフラにおいて、モバイルユーザーや不安定な回線を使うクライアントが増えれば増えるほど、このQUICの恩恵は計り知れないものになります。
「なぜかこのAPIだけモバイルで遅延する」「パケットロス率が高い環境でスループットが頭打ちになる」――そんな壁にぶぶかったときは、ぜひこの記事で紹介したACKフレームの挙動や、Wiresharkによるパケット解析を思い出してください。プロトコルの底流にある仕組みを理解していれば、どんな難解なネットワーク障害も必ずロジカルに解決の糸口が見つかるはずです。
それでは、次回のインフラ・プロトコル談義でお会いしましょう。現場からは以上です！
コメント