こんにちは！ネットワークの面白さを世界中に伝えるウェブメディアへようこそ。主筆ライターの私と一緒に、パケットが駆け巡るインターネットの裏側に迫っていきましょう。
Webの通信といえば、かつては「TCP」というプロトコルが主役でした。しかし、今の最新規格であるHTTP/3では、これまで「速いけれど大雑把」と言われていたUDPをベースにした新プロトコル「QUIC（クイック）」が使われています。
「UDPって、相手に届いたかどうか確認しないプロトコルなんじゃないの？」
「パケットが途中で消えたらどうするの？」
そう疑問に思ったあなた、大正解です！
UDPそのものは打ちっぱなしの通信ですが、QUICはUDPの上に「超絶賢い確認応答の仕組み（ACKフレーム）」を独自に構築することで、信頼性と圧倒的なスピードを両立しています。
今回は、QUICの心臓部とも言える「ACK（アック）フレーム」の仕組みと、通信を遅らせないための工夫、そしてパケットロス（手紙の紛失）を見つける魔法のメカニズムを、初心者の方にも分かりやすく紐解いていきます。一歩ずつ一緒に理解していきましょう！
—
1. 郵便配達で例える「パケット確認応答」
まずは、パケットの確認応答（ACK）とは何かを、身近な「手紙のやり取り」で考えてみましょう。
あなたが友達に、1番から10番までの番号を振った10通の手紙を順番に送るとします。
もし、友達から1通届くたびに「1番届いたよ！」「2番届いたよ！」と毎回電話がかかってきたらどうでしょう？ ちょっとうるさいですし、電話代（ネットワークの負担）がもったいないですよね。
でも逆に、10通すべて届くまで全く返事がなかったら、「途中で迷子になってないかな…」と不安になります。
通信の世界でも全く同じことが起きています。
- パケット＝送る手紙
- ACK（Acknowledgement）フレーム＝「届いたよ！」という受領告知の返信
QUICでは、この「受領告知の手紙（ACKフレーム）」の書き方と送り方が、従来のTCPに比べて劇的に進化しているのです。
—
2. QUICのACKフレームは何がすごいの？
従来のTCPでは、手紙（パケット）の再送が起きると「これは最初に送った手紙の返事？ それとも再送した手紙の返事？」という混乱（再送あいまい性）が起きることがありました。
しかし、QUICはこの問題を「パケット番号は絶対に巻戻さず、1ずつ増やし続ける」というシンプルなルールで解決しました。
QUICの「受領告知（ACKフレーム）」の中身を覗くと、主に次のような情報が書かれています。
ACKフレームに含まれる主な情報
1. 一番大きなパケット番号（Largest Acknowledged）
「手元に届いた中で、一番大きな番号は『10番』でした！」
2. 返信にかかった時間（ACK Delay）
「10番が届いてから、この返事（ACK）を書くまでに『2ミリ秒』考えました！」
3. 抜け漏れのリスト（ACK Range）
「ちなみに『1〜7番』と『9〜10番』は届いていますが、『8番』だけ届いていません！」
この「抜け漏れのリスト（ACK Range）」がとても優秀です。
「8番だけ届いてない」とピンポイントで教えてくれるため、送り手は「あ、じゃあ8番だけもう一度送るね！」と無駄なく再送できるのです。
—
3. 遅延ACK（Delayed ACK）の最適化〜返事はまとめてスマートに〜
通信の負担を減らすため、QUICは手紙が1通届くたびにACKを返さず、「少しだけ待って、まとめて返信（遅延ACK）」をします。
ですが、ここで重要なのがバランス（最適化）です。
- 待たなさすぎる：ACKパケットが大量に飛び交い、回線が混雑する（ACK嵐）。
- 待ちすぎる：送り手が「届いてないのかな？」と心配して、余計な再送をしてしまう。
そのため、QUICには「最大でどれくらい返事を遅らせて良いか（Max ACK Delay）」というルールが定められています。
一般的には「パケットを2つ受け取るか、あるいは最大数ミリ秒（例: 25ミリ秒）経過したら、絶対にACKを返す」といった調整が自動で行われています。この絶妙な間合い（タイマー調整）こそが、HTTP/3の高速なレスポンスを支えているのです。
—
4. パケットロス（紛失）はどうやって見つけるの？
ネットワークの途中でパケットが消えてしまった時、QUICはどうやって「あ、事故が起きたな」と判断するのでしょうか？
QUICには主に2つの判別ルールがあります。
送り手「1番、2番、3番、4番、5番を送ったよ！」
受け手「1番、2番、3番、 5番 が届いたよ！」 (4番が届かない)
│
▼
【個数ルール】「3個あとの『5番』が届いたのに、4番が来ない… 4番は消えたな！」
【時間ルール】「3番が届いてから規定時間が過ぎたのに、4番が来ない… 4番は消えたな！」
① 個数ルール（Packet Threshold）
受け手から「1, 2, 3, 5番が届いたよ！」というACKが来たとします。
「4番」を飛ばして「5番」が届いているということは、4番は途中で落っこちた可能性が高いですよね。
QUICでは、「○個先のパケットが届いたら、飛ばされたパケットはロスしたとみなす」という基準（デフォルトは3個など）を持っています。
② 時間ルール（Time Threshold）
パケットの順番が入れ替わって遅れて届くこともあるため、個数だけでなく「時間」も見ます。
「最後にパケットを受け取ってから、通信の往復時間（RTT）の1.125倍の時間が過ぎても届かなければ、ロスとみなす」といった柔軟なタイマーが動いています。
—
5. 実務で役立つ！QUIC通信とACKの挙動を見てみよう
ここからは、実際にエンジニアがデバッグや設定変更をする際の世界を少しだけ覗いてみましょう。
Wiresharkなどで見られるQUIC ACKの概念表現
ネットワーク解析ツール（Wiresharkなど）で通信をキャプチャすると、QUICのACKフレームは概念的に以下のように解釈されて表示されます。
QUIC Frame Type: ACK (0x02)
├─ Largest Acknowledged: 100 # 受信できた最大のパケット番号は 100
├─ ACK Delay: 12 (1.5ms) # ACKを生成するまでに受取側で発生した遅延時間
├─ ACK Range Count: 1 # 抜け漏れのエリアが何箇所あるか
└─ ACK Ranges:
├─ Range [100 – 95] # 95番〜100番は無事に届いた！
└─ Gap: 2, Range [92 – 90]# (93, 94番が抜け) 90番〜92番も届いていた！
このように、1つのACKフレームを見るだけで「何番まで届いていて、どこが欠けているか」がひと目で分かります。
NginxなどのWebサーバーでのQUIC設定例
最新のWebサーバー（例: Nginx）などでは、HTTP/3（QUIC）を有効化する際に、ACKの挙動に関連するパラメーターやネットワーク調整を行います。
以下は、QUIC（HTTP/3）を有効化する設定のイメージです。
server {
# UDPの443番ポートでHTTP/3 (QUIC) を有効化します
listen 443 quic reuseport;
# 従来のTCP用のHTTPSもフォールバック（予備）として残しておきます
listen 443 ssl;
server_name example.com;
# SSL/TLS証明書の設定（QUICでもTLS 1.3が必須です）
ssl_certificate /etc/ssl/certs/example.crt;
ssl_certificate_key /etc/ssl/certs/example.key;
# HTTP/3をサポートしていることをブラウザに伝えるヘッダーを付与
add_header Alt-Svc ‘h3=”:443″; ma=86400’;
location / {
# QUIC通信が途切れたと判断するタイムアウト時間の設定
# （パケットロスが多発した際などの接続維持に関わります）
quic_gso on; # Generic Segmentation Offloadを有効にしてUDPパケット送信を効率化
root /usr/share/nginx/html;
index index.html;
}
}
> ワンポイント解説: `quic_gso on;` は、OS（Linux Kernel）の機能を使い、複数のUDPパケットをまとめて網に流す仕組みです。ACKの最適化と組み合わせることで、CPU負荷を劇的に下げることができます。
—
まとめ：仕組みが分かると通信はもっと面白い！
今回はHTTP/3とQUICの「ACKフレーム」にスポットを当てて解説しました。
ポイントを振り返ってみましょう。
1. UDPだけど安心：QUICはUDPの上に「自前の賢い確認応答（ACK）」を持っているので信頼性が高い。
2. 通し番号が巻き戻らない：TCPと違ってパケット番号が増え続けるため、再送の混乱が起きない。
3. ACK Rangeで無駄なく伝達：「ここからここまで届いた」をまとめて伝えられるので、歯抜けの再送がスマート。
4. 遅延ACKとタイマーの最適化：毎回返信せず、絶妙なタイミングでまとめて返事をするから速い。
ネットワークプロトコルと聞くと「小難しいビットの羅列」に思えるかもしれません。しかし、その根底にあるのは「どうやったら遠くの相手と、間違いなく、無駄なく会話ができるか？」という人間味あふれる知恵の結集なのです。
HTTP/3やQUICの導入が進む現代、この裏側のドラマを知っているだけでも、インフラエンジニアとしての視野がグッと広がるはずですよ。
焦らず、一歩ずつ一緒にマスターしていきましょう！
コメント