こんにちは！ネットワークの世界に飛び込んだばかりの皆さん、日々のインフラ学習お疲れ様です。「Webの表示をもっと速く、もっと強くしたい！」そう思ったとき、避けて通れないのが最新のトランスポートプロトコル「QUIC（クイック）」ですよね。
HTTP/2が抱えていた「TCPの呪縛（ヘッド・オブ・ライン・ブロッキング）」を華麗に打ち破り、次世代のWebを支える主役としてGoogleや各ブラウザベンダーが全力で推し進めているこのQUIC。今回は、そのQUICが持つ数ある魅力の中でも、特に泥臭く、しかし美しく設計された「パケットロス回復メカニズム（Recovery）」にスポットを当てていきたいと思います。
「パケットロス？ 再送制御？ なんか難しそう……」と思ったそこのあなた、大丈夫です！ 一歩ずつ、身近な例えを交えながら優しく紐解いていきますので、コーヒーでも飲みながらリラックスして読み進めてくださいね。
—
1. そもそも「パケットロス」ってなに？（現実世界の郵便配達で例えてみよう）
私たちがインターネットを通じてWebサイトを見るとき、データは目に見えない小さなカプセル（パケット）に分割され、宛先に向かって一目散に駆け抜けています。
しかし、世の中のWi-Fi環境はいつだって完璧とは限りません。電子レンジの電波干渉があったり、カフェの回線が混み合っていたりすると、途中で「配達員が荷物を落として紛失してしまう」という事故が起きます。これがパケットロス（パケット損失）です。
昔のやり方（TCP）の悲劇
従来のHTTP/2などで使われていた「TCP」という通信規格は、いわば「真面目だけど融通のきかない一昔前の書留郵便」でした。
1. あなたが手紙を1番から10番まで順番に送ります。
2. 途中で「3番」の手紙が雨で濡れて消えてしまいました。
3. TCPは「3番が届くまでは、4番以降の荷物は絶対に開けてはいけない（見せてはいけない）！」という厳格なルールを持っていました。
その結果どうなるか？ 4番から10番の大切な荷物は手元に届いているのに、3番の再配達を待つために、画面の表示がフリーズしたように止まってしまうのです。これが「TCPのヘッド・オブ・ライン・ブロッキング」と呼ばれる現象ですね。
—
2. QUICの革命：パケット番号空間と独立したストリーム
ここで登場するのが、今日の主役であるQUICです。QUICはUDPをベースにしつつ、独自の強靭な制御メカニズムを持っています。
QUICは、先ほどの郵便配達の仕組みを根本から変えました。
- 「手紙（パケット）」全体には通し番号（パケット番号）振るけれど、その中身には「どの話題に関する手紙か（ストリームID）」を独立して持たせるようにしました。
- 万が一、ある話題の手紙が1通消えてしまっても、別の話題の手紙は、そんなことお構いなしにどんどん開封して画面に表示できるようになったのです。
「あれ、それじゃあ失くした手紙はどうやって見つけて、どうやって再送してもらうの？」という疑問が湧いてきますよね。ここからがQUICの真骨頂、「パケットロス回復メカニズム」の出番です！
—
3. ロスを検知する2つのアプローチ：タイマーと「数え間違い」
QUICがパケットの紛失（ロス）を検知する方法は、大きく分けて2つあります。一歩ずつ理解していきましょう！
① 再送タイマー（Loss Timer）による検出
もっとも基本なのが、「いつまで待っても返事（確認応答：ACK）が来ないな……？」とタイマーで測る方法です。
QUICは、パケットを送り出した瞬間にストップウォッチ（タイマー）をスタートさせます。「このネットワークの往復時間（RTT）なら、そろそろ相手から『受け取ったよ！』という返事が来るはずだ」と予測し、その時間を過ぎても返事が来なければ、「あ、途中で迷子になったんだな」と判断して同じパケットをもう一度送ります。
② パケット番号の「抜け（Gap）」による検出
これがQUICや前身のTCP（SACK機能など）で非常にスマートに使われている仕組みです。
例えば、あなたが相手に 1番、2番、3番、4番、5番 のパケットを送り出しました。しばらくして相手から「1番、2番、4番、5番を受け取りました！」という連絡（ACK）が返ってきました。
あれ……？ 3番が抜けていますよね？
QUICはここで、こう推測します。
> 「1番、2番のあとに4番、5番が届いているということは、宛先はちゃんと動いている。それなのに3番だけが届いていないということは、3番は途中でロスト（消失）した可能性が非常に高い！」
このように、パケットの番号の「抜け」を素早く察知することで、タイマーのタイムアウトを待つことなく、即座に「3番を再送してくれ！」と動くことができるのです。この機敏さこそが、QUICを爆速たらしめている秘密の一つです。
—
4. 重複を許さない！QUICの「パケット番号（Packet Number）」の美学
ここで、ネットワークの深い深い沼に足を一歩踏み入れるような、ちょっとマニアックで面白い話をさせてください。
TCPを使っていた頃、エンジニアを悩ませる「あるバグの温床」がありました。それは「再送されたパケットの識別問題」です。
例えば、パケットAを送ったけれどロスしたため、全く同じ中身のパケットA’を再送したとします。このとき、受信側（あるいは途中のルーター）からすると、「今届いたのは、最初に送ったやつが遅れて届いただけ？ それともロストして再送されたやつ？」という区別がパッと見ではつきにくかったのです。
QUICは「過去を振り返らず、常に未来の番号を振る」
QUICはこの問題を天才的なアプローチで解決しました。
QUICのパケット番号は、「再送するパケットであっても、元の番号とは違う、まったく新しい（より大きな）パケット番号を割り振って送る」というルールになっています。
| 送信のタイミング | 送った内容 | 割り振られたQUICパケット番号 | 備考 |
| :— | :— | :— | :— |
| 1回目 | データX | #101 | 初回送信 |
| (ロス発生) | – | – | タイムアウトまたは抜けを検出 |
| 2回目（再送） | データX | #145 | 中身は同じだが、番号は「#145」という全く新しいものとして送る！ |
「えっ、中身が同じなのに番号を変えちゃったら、受信側は混乱しないの？」
いいえ、これがめちゃくちゃスマートなんです。QUICのヘッダーには、「このパケット番号（#145）は、どのデータの再送なのか（Frame内での紐付け）」という情報がしっかり入っています。
これにより、送信側は次のような正確な計算ができるようになります。
- 「あ、#145のACKが返ってきたぞ。これは#101のデータに対する返事だな。ということは、今回のネットワークの往復時間（RTT）はこれくらいか！」
もし古い番号のまま再送していると、「今届いたACKは、1回目の#101に対する返事なのか、それとも再送した#101に対する返事なのか」という「ACK Ambiguity（確認応答の曖昧さ問題）」が発生してしまいます。QUICはこの問題を、番号を新しくするというシンプルな発想で完全にクリアしているのです。
—
コラム：実際のパケット解析や実装で意識するポイント
実務やトラブルシューティングでWiresharkなどのパケットキャプチャツールを開くと、QUICの通信がどのように流れているかを目の当たりにできます。
例えば、Go言語やRust、あるいはC++などのQUIC実装（quicheやpicoquicなど）を触る際、ロス回復のパラメータをチューニングする場面に出会うかもしれません。以下は、概念的な設定イメージのコードスニペットです。
// Go言語の擬似コード：QUICの損失回復（Recovery）設定のイメージ
package main
import (
“time”
)
type QuicRecoveryConfig struct {
// 損失検出のためのタイマー倍率（標準的なRTOの計算に使用）
LossDetectionMultiplier float64
// 輻輳ウィンドウ（Congestion Window: ネットワークに送り出せる最大パケット数）
InitialCongestionWindow int
}
func NewDefaultQuicRecovery() QuicRecoveryConfig {
return &QuicRecoveryConfig{
// ネットワークの揺らぎ（ジッター）を考慮し、タイマーが早すぎず遅すぎず動くように調整
LossDetectionMultiplier: 1.0,
// 初期状態では過剰にパケットを送りすぎず、徐々にウィンドウを広げていく
InitialCongestionWindow: 10,
}
}
func main() {
// ここで設定された回復ロジックが、パケットの抜けやタイマーを監視し、
// ロスが発生した瞬間に素早く再送パケット（新しいパケット番号を付与）を送り出します。
}
このように、フレームワークの内部では、パケットの抜けやタイマーの閾値をミリ秒単位で計算し、回線のコンディションに合わせたアグレッシブかつ安全な再送制御を行っているのです。
—
お疲れ様でした！今回はQUICのパケットロス回復メカニズムについて、郵便配達の例えからパケット番号の裏側まで、たっぷりと解説してきました。
最初は難しく感じた「パケットロス」「再送タイマー」「パケット番号空間」というワードも、一歩ずつ構造を紐解いていけば、ネットワークエンジニアたちの「どうにかして最速で安全にデータを届けたい！」という熱い工夫の結晶であることが見えてきたのではないでしょうか。
実務でWiresharkのログを見たり、Webアプリのパフォーマンスチューニングを行ったりする際、「あ、今この瞬間も、QUICは新しい番号を振って健気にロスイートを回復しているんだな」と想像していただけたら、インフラの世界がもっともっと楽しくなるはずです。
それでは、また次回の技術解説でお会いしましょう！素晴らしいネットワークライフを！
コメント