【入門編】HTTP/3のパケットロス回復とACKフレームの挙動 – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの世界へようこそ。インフラ・プロトコルスペシャリストの私と一緒に、今日もワクワクする通信の裏側を覗いていきましょう。

私たちが普段何気なく使っているWebブラウザ。URLを入力すれば一瞬でページが表示されますよね。「どうやってそんなに速くデータが届いているんだろう？」と疑問に思ったことはありませんか？

実はインターネットの裏側では、データの配達員たちが日々大忙しで走り回っています。今回は、その配達員たちの最新の働き方改革である「HTTP/3」、そしてその心臓部である「QUICのACK（確認応答）とパケットロス回復の仕組み」について、難しい専門用語の壁をなるべく取り払って、現実世界のたとえ話を交えながら優しく紐解いていきたいと思います。

一歩ずつ理解していきましょう！

—

1. 昔ながらの「手紙のやり取り（TCP）」が抱えていたもどかしさ

HTTP/3のすごさを知るためには、インターネットの長年の相棒であった「TCP」というプロトコルが抱えていた、ちょっとした「おせっかいなルール」を知る必要があります。

イメージしてください。あなたは今、何枚もの大切な書類を友達に郵送しようとしています。
TCPのやり方はこうです。

1. あなたは書類に「1番」「2番」「3番」と番号を振って送ります。
2. 友達は「1番届いたよ！」「2番届いたよ！」とお返事（ACK）をくれます。
3. ところが、「2番」の封筒が途中で雨に濡れて破れてしまいました！ 友達の元には「1番」と「3番」しか届きません。
4. ここでTCPの真面目すぎるルールが発動します。友達は「3番が届いたけど、2番がないから、全体の処理をいったんストップ！」とあなたに伝えます。
5. あなたは「えっ、3番までいってるのに？」と思いつつ、もう一度「2番」を送り直します。そして2番が届いて初めて、みんなで次の作業に進めるのです。

これをネットワークの世界では「ヘッド・オブ・ライン・ブロッキング（Head-of-Line Blocking / 隊頭ブロック）」と呼びます。たった1つのパケット（封筒）が迷子になっただけで、その後ろを走っていた無関係なデータまで全員が足止めを食ってしまう……。これが、従来のWebを少しだけ遅くしていた原因でした。

—

2. HTTP/3とQUICの登場：バイク便の「選択的確認応答」

そこで登場したのが、次世代の通信規格「HTTP/3」を支える下回り、「QUIC（クイック）」というプロトコルです。UDPという少し乱暴だけど速いトランスポート層をベースにしつつ、TCPの弱点を華麗に克服しています。

QUICがすごいのは、「あ、2番が濡れちゃった？じゃあ1番と3番はそのまま受け取っといて！ 2番だけあとで持ってきて！」という、柔軟な受け渡しができる点です。

これを実現しているのが、今回主役の「ACKフレーム（確認応答）」と「選択的確認応答（Selective Acknowledgement）」という仕組みです。

現実世界で例えると？

あなたがアマゾンで注文した10冊の本が、10個の別々のダンボール箱（パケット）で届くとします。
従来のTCPだと、2箱目が配達途中でトラックから落ちて行方不明になると、配達員は「2箱目が揃うまで、1箱目も3箱目以降も全部お渡しできません！」と頑なに拒否していました。

しかし、QUIC（HTTP/3）の世界では違います。配達員（QUIC）はこう言います。
「あ、2箱目だけ行方不明ですね。分かりました！じゃあお手元にある1箱目と3箱目〜10箱目は先に開封して読んでおいてください。行方不明の2箱目は、僕が今から急いで裏道から再配達してきます！」

この「どの箱が届いていて、どの箱がまだ届いていないか」を正確に仕分けして伝える伝票が、ACKフレームなのです。

—

3. パケットロスが発生したとき、QUICはどう動く？

では、実際にネットワーク上でパケットロス（データの紛失）が発生したとき、QUICの内部ではどのようなドラマが繰り広げられているのでしょうか。その流れを覗いてみましょう。

[クライアント（ブラウザ）] [サーバー（Webサイト）]
| |
| — パケット #1, #2, #3 を送信 ——–> |
| (ここで #2 が途中で消滅！) |
| |
| <--- ACKフレーム (#1 と #3 到着!) ------ | | 「#2 がまだ届いていませんよ！」 | | | | --- パケット #2 (再送) を送信 ---------> |
| |
| <--- ACKフレーム (#2 到着!) ------------ | | 「全部揃いました！」 | | |

ACKフレームの中身をのぞき見してみよう

QUICがやり取りするACKフレームは、非常に頭が良くできています。ただ「届いたよ」と言うだけでなく、「どこからどこまでの連続したパケットが届いていて、飛び番はどこか」をコンパクトに表現します。

イメージとしては、以下のようなデータ構造（※概念的な表現です）でサーバーに伝えています。

{
なにかのACKフレーム: {
“最新の最大確認パケット番号”: 3,
“前回から今日までの遅延時間（マイクロ秒）”: 12500,
“到着ブロックの範囲”: [
{ “開始”: 1, “終了”: 1 },
{ “開始”: 3, “終了”: 3 }
]
}
}

「パケット1と、パケット3は無事に受け取りました。でも、その間のパケット2がまだ見当たりません！」というメッセージを、この数バイトのフレームにギュッと詰め込んで一瞬で送り返します。

サーバー側はこのACKを受け取ると、「なぬ、#2だけ落としたな！」と瞬時に判断し、未達だった#2のデータだけをピンポイントで再送します。他のデータはすでにクライアントに渡っているので、全体としてのスピードが落ちないわけです。

—

4. 現場のエンジニアとしての視点：パケットロスとどう向き合うか

私たちインフラエンジニアや開発者が、このHTTP/3・QUICの挙動を意識する場面は、主にトラブルシューティングやパフォーマンスチューニングのときです。

例えば、Wi-Fiの電波が悪いカフェや、移動中のトンネル内などでスマホを使っているとき、パケットロスは日常茶飯事に発生します。従来のTCPであれば、こういった悪条件の環境では「再送待ちの渋滞」が頻発し、画面がクルクルと回り続けてしまいます。

しかし、HTTP/3（QUIC）が有効な環境であれば、ロスしたパケットのせいで他のリクエスト（画像やスタイルシート）までブロックされないため、「悪条件の中でも体感速度が落ちにくい（粘り強い）」という恩恵をユーザーにもたらすことができます。

実務でのデバッグ：WiresharkでQUICのパケットを見てみよう

もし、実際のネットワーク通信でQUICやACKの挙動を確認したい場合は、パケットキャプチャツール「Wireshark」が強力な相棒になります。

Wiresharkのフィルターに以下のように入力してみましょう。

Wiresharkのディスプレイフィルター例
quic

これによって、UDPポート（通常は443番など）を流れるQUICのパケットだけを綺麗に抽出できます。パケットの詳細パネルを開くと、以下のような項目を確認できます。

Packet Number (パケット番号): 通信のたびにインクリメントされる番号
Frames: ACK: クライアント/サーバー間で行き交う確認応答フレーム
Largest Acknowledged（確認された最大のパケット番号）
Ack Delay（応答遅延時間）
Ack Ranges（どの範囲のパケットが届いたかのリスト）

実務の現場で「なんだかこの回線、特定のサーバーとの間でパケットロスが多いな？」と感じたときは、WiresharkでこのACKフレームのやり取り（再送が頻発していないか、ACKの遅延が大きくなっていないか）を追うことで、ボトルネックの原因を鮮やかに特定できるようになります。

—

5. まとめ

いかがでしたでしょうか？今回はHTTP/3の心臓部である「QUICのACKフレームとパケットロス回復」について解説しました。

従来のTCPは、途中のデータが1つでも欠けると全体がストップしてしまう（ヘッド・オブ・ライン・ブロッキング）。
QUIC（HTTP/3）のACKフレームは、「選択的確認応答」をサポートしているため、欠けたデータだけをピンポイントで教えてくれる。
結果として、パケットロスが多い不安定なネットワーク環境でも、Webページがサクサクと表示され続ける高い耐障害性を発揮する。

普段何気なく見ているWebサイトの裏側では、こうした郵便配達の仕組みのような、泥臭くてスマートな工夫が毎秒何万回も行われています。この仕組みを知っているだけでも、ネットワークのトラブルに直面したときの「アプローチの引き出し」がぐっと広がりますよね。

それでは、次回の技術解説もお楽しみに！日々のインフラ・開発ライフを一緒に楽しんでいきましょう！