皆さん、こんにちは！ネットワークの深淵を覗き込む旅へようこそ。
世界中を駆け巡るパケットの息遣いを肌で感じながら、最新技術の「なぜ？」を紐解いていくのが、この連載の醍醐味ですよね。
今回は、次世代のインターネットを支える主役、HTTP/3 の根幹をなす QUICプロトコル の中でも、特に賢くて地味にすごい働きをしている「パケット番号（Packet Number）」の秘密に迫ります。
「パケット番号？そんなのTCPにもあるシーケンス番号と同じでしょ？」と思ったそこのあなた！
いやいや、QUICのパケット番号は一味も二味も違うんです。特に、その「賢いエンコーディング（符号化）」の仕組みは、QUICがなぜ速くて安定しているのかを理解する上で、決して避けて通れないテーマになります。
小難しい専門用語は一旦脇に置いて、私たちが日々受け取る郵便物や宅配便のイメージを借りながら、一歩ずつ、QUICのパケット番号の奥深さを探っていきましょう！
—
QUICの「パケット番号」って、いったい何者？
まずは、QUICの「パケット番号」がどんな役割を担っているのかを、ざっくりと掴んでいきましょう。
想像してみてください。あなたは、毎日たくさんの荷物を届けてくれる、とっても優秀な郵便屋さんです。荷物にはそれぞれ「追跡番号」が振られていますよね。この「追跡番号」が、QUICでいうところの「パケット番号」に相当します。
QUICでは、データを小さな塊（パケット）に分割して送信します。このパケット一つ一つに、連番で「パケット番号」がつけられているんです。
なぜパケット番号が必要なの？
1. 信頼性の確保:
ネットワークの世界では、残念ながら途中でパケットが迷子になったり、壊れてしまったりすることが日常茶飯事です。郵便物で言えば、途中で紛失したり、雨で濡れて読めなくなったりするようなものですね。
このとき、受信側は「この追跡番号の荷物が届いてない！」と気づけます。そして、送信側は「あ、あの番号の荷物、もう一回送らなきゃ」と判断できるわけです。これが、データの「再送」と「信頼性」の基本的な考え方になります。
2. 順序の管理:
パケットは、送られた順番通りに届くとは限りません。道路が混んでるルートを通ったり、途中で寄り道したりして、順番が入れ替わってしまうこともあります。
でも、郵便屋さん（受信側）は、荷物の追跡番号を見れば、「あ、これは3番目に送られた荷物だな」「これは1番目だ」と、正しい順番に並べ替えることができますよね。QUICも同じように、受信側はパケット番号を使って、バラバラに届いたパケットを正しい順序に並べ直し、元のデータとして組み立てるんです。
TCPのシーケンス番号との違いは？
TCPにも「シーケンス番号」という似たようなものがありますが、QUICのパケット番号は、それよりもっと直接的に「パケットの識別子」として機能します。
TCPのシーケンス番号は「バイトストリームのどこまでデータが流れたか」を示すのに対し、QUICのパケット番号は「何番目のパケットが送られたか」をダイレクトに示します。
このシンプルな連番管理が、QUICの高速なロス検知や再送メカニズムを支える土台になっているんですよ！
—
なぜ「可変長エンコーディング」が必要なの？
さて、パケット番号の重要性は理解できましたね。では次に、今回の本題である「可変長エンコーディング」という、ちょっと聞き慣れない言葉について考えてみましょう。
「可変長」というのは、「長さが変わる」という意味です。
つまり、QUICのパケット番号は、毎回同じ長さのデータで送られるわけではなく、その時々で適切な長さに「変化」するんです。
郵便物の追跡番号で考えてみよう
例えば、あなたが郵便屋さんで、1日に何万件もの荷物を扱っているとします。
追跡番号は、最初は「1」「2」「3」…と小さく始まりますよね。でも、何億件もの荷物を送っていると、「123456789」のように、どんどん番号が大きくなっていきます。
もし、この追跡番号を毎回、最大の桁数（例えば9桁）で書かなければならないとしたらどうでしょう？
まだ番号が「1」なのに、「000000001」と書くのは、ちょっと非効率的ですよね。紙の無駄遣いにもなりますし、書き込む手間も増えます。
ネットワークの世界でも全く同じことが言えます。
パケット番号を常に最大の長さ（例えば8バイト、つまり64ビット）で送ると、まだ番号が小さい時でも、余計なデータをネットワーク上に流すことになります。これは、私たちが「帯域幅（バンド幅）」と呼ぶ、貴重な通信リソースの無駄遣いになってしまいます。
特に、モバイル環境のように帯域が限られている場所では、この「無駄」が通信速度の低下に直結してしまうんです。
そこでQUICは考えました。「よし、パケット番号の長さは、その時々で一番効率的な長さに変えよう！」と。これが「可変長エンコーディング」の始まりです。
—
QUICの賢い「パケット番号エンコーディング」の仕組み
さあ、ここからがQUICの真骨頂です！
QUICは、一体どうやってパケット番号の長さを賢く変えているのでしょうか？
ポイントは、「受信側が、最後に受け取ったパケット番号を覚えている」 という点です。
差分で伝える「郵便屋さんのひそひそ話」
再び郵便屋さんの例えに戻りましょう。
あなたが荷物を送る側で、相手が荷物を受け取る側です。
相手は、最後に「1000番」の荷物を受け取ったことを知っています。
もし、次にあなたが「1001番」の荷物を送るとします。このとき、あなたはわざわざ「1001」とフルで伝える必要はないですよね？
相手は「1000番の次だから、きっと1001番だろう」と予想できます。あなたは「プラス1！」とだけ伝えれば、相手は「なるほど、1000 + 1 = 1001番の荷物ね！」と理解できます。
さらに、もし「1050番」の荷物を送るとしたら？
あなたは「プラス50！」と伝えれば、相手は「1000 + 50 = 1050番ね！」と理解できます。
このように、基準となる番号からの「差分」だけを伝えることで、送る情報の量を大幅に減らすことができます。これが、QUICのパケット番号エンコーディングの基本的な考え方なんです。
QUICがパケット番号の長さを決めるロジック
QUICは、送信側が次に送るパケット番号を、受信側が「最後に確認したパケット番号」 を基準にして、どれくらいの長さで表現するかを決定します。
具体的には、以下のルールで長さを変えます。
1. 最も短く送れるのは「1バイト」
もし、次に送るパケット番号が、最後に受信側が確認した番号から255番以内の差であれば、たった1バイト（0〜255）で表現できます。
例えば、受信側が「1000番」まで受け取っているとして、次に「1001番」を送るなら、差は「1」なので、1バイトで十分ですよね。
2. ちょっと長くなって「2バイト」
差が255番を超えて、65,535番以内であれば、2バイト（0〜65535）で表現します。
郵便屋さんの例で言えば、「プラス50000！」と伝えるようなものです。
3. さらに長くなって「4バイト」
差が65,535番を超えて、約42億番以内であれば、4バイトで表現します。
これだけあれば、ほとんどの通信で事足ります。
4. 最大で「8バイト」
そして、どんなに大きな番号になっても大丈夫なように、最大で8バイト（約1.8京番まで！）まで対応しています。
重要なのは、送信側は「受信側がこの番号まで受け取っているだろう」と推測して、一番短いバイト数を選ぶということです。
この推測は、受信側から定期的に送られてくる「ACKフレーム（確認応答）」によって更新されます。
具体例で見てみよう！
仮に、受信側が最後に確認したパケット番号が `1000` だとします。
- 次に送るパケット番号が `1001` の場合：
`1001 – 1000 = 1`。差が `1` なので、1バイトで十分です。
- 次に送るパケット番号が `1200` の場合：
`1200 – 1000 = 200`。差が `200` なので、これも1バイトで十分です。
- 次に送るパケット番号が `10100` の場合：
`10100 – 1000 = 9100`。差が `9100` なので、2バイトが必要になります。
- もし何らかの理由で、受信側が長く確認応答を送れず、送信側が送るパケット番号が大きく離れてしまった場合、例えば `1,000,000` 番になったら：
`1,000,000 – 1000 = 999,000`。差が `999,000` なので、4バイトが必要になります。
このように、QUICは常に「一番効率の良い長さ」を選んでパケット番号を送信することで、ネットワークの帯域を賢く節約しているんです。
まるで、必要な情報だけを簡潔に伝え合う、ベテランの郵便屋さんと受け取り人さんのような関係ですよね！
—
パケットロスをどうやって見つけるの？ ～パケット番号の真価～
パケット番号の賢いエンコーディングによって、効率よく情報を送れることは分かりました。
では、このパケット番号が、ネットワークで一番やっかいな問題の一つである「パケットロス（パケットが途中で失われること）」の検知にどう役立つのでしょうか？
郵便屋さんの「欠品リスト」
再び郵便屋さんの例です。
あなたが、たくさんの荷物を受け取る側だとします。
送られてきた荷物の追跡番号をチェックしていくと、
「1番、2番、4番、5番、6番が届いたぞ！」
あれ？「3番」がない！
あなたはすぐに気づきますよね。「3番の荷物が届いてない！」と。
QUICの受信側も全く同じことをしています。
受信側は、届いたパケットのパケット番号を一つ一つ確認し、連続しているべき番号が飛んでいる（ギャップがある）ことを見つけると、「あ、この番号のパケットはロスしたな」と判断します。
そして、その「届いていないパケット番号」のリストを、今度は「ACKフレーム」という形で送信側に送り返します。
「1番から5番まで受け取ったけど、3番が届いてないよ！」という連絡ですね。
この仕組みによって、送信側はどのパケットが届いていないのかを正確に把握し、必要なパケットだけを効率的に再送することができるんです。
TCPでは、シーケンス番号でロスの可能性を推測したり、タイムアウトを待ったりするケースもありましたが、QUICはパケット番号のおかげで、より迅速かつ正確にロスを検知し、リカバリーできるんですよ。
この一連の流れが、QUICの高速な接続確立（0-RTTなど）や、通信中の安定性に大きく貢献しているんです。
—
現場での「パケット番号」との付き合い方（ツールでの確認）
ここまでQUICのパケット番号の賢さを見てきましたが、実際にネットワークを流れるパケットの中身を覗いてみたくなりませんか？
そんなときに活躍するのが、ネットワークアナライザの定番「Wireshark」です。
Wiresharkを使えば、実際にQUICのパケットをキャプチャし、その中に含まれるパケット番号がどのようにエンコードされているかを観察することができます。
WiresharkでQUICのパケット番号を見てみよう！
1. QUIC通信のキャプチャ:
まずは、QUIC（HTTP/3）で通信しているウェブサイト（例えば、GoogleやCloudflareなどが提供するサイト）にアクセスしながら、Wiresharkでネットワークトラフィックをキャプチャします。
2. フィルタリング:
キャプチャしたデータの中からQUICパケットだけを抽出するために、以下のフィルタを適用します。
# Wiresharkの表示フィルタ入力欄に貼り付けて使ってみましょう！
# QUICパケット全般をフィルタします
quic
# さらに具体的に、パケット番号のフィールドを持つパケットをフィルタします
quic.packet_number
3. パケット詳細の確認:
フィルタリングされたQUICパケットの一つを選択し、中央の「Packet Details」ペインを見てみましょう。
おそらく、「QUIC」のセクションを展開すると、その中に「Packet Number」という項目が見つかるはずです。
そして、その「Packet Number」の横に表示されている値だけでなく、そのフィールドが実際にネットワーク上では何バイトで表現されているか（「Length」や「Size」といった形で表示されることがあります）にも注目してみてください。
異なるパケットで、この「Packet Number」のフィールドの長さが変わっているのが観察できるはずです。
これがまさに、QUICの「可変長エンコーディング」が実際に動いている証拠なんですよ！
Wiresharkを触ってみると、「あぁ、本当にこんな風に動いているんだな！」と、机上の知識がリアルな実感に変わる瞬間を味わえるはずです。ぜひ、ご自身の環境で試してみてくださいね！
—
まとめ
今回の旅では、QUICプロトコルの心臓部とも言える「パケット番号」と、その賢い「可変長エンコーディング」の仕組みを深掘りしてきました。
- パケット番号は、ネットワーク上でパケットが迷子になったり、順番が入れ替わったりしても、データの信頼性と順序を保つための「追跡番号」のような存在であること。
- 通信の効率を最大化するために、パケット番号を常に最適な（最短の）長さで送る「可変長エンコーディング」という技術が使われていること。
- この可変長エンコーディングは、受信側が最後に確認したパケット番号を基準に、次に送るパケット番号の「差分」を最も短いバイト数で表現する、という賢いロジックに基づいていること。
- そして、このパケット番号のおかげで、QUICはパケットロスを素早く正確に検知し、効率的な再送を行うことで、高速かつ安定した通信を実現していること。
これらは、私たちがインターネットを快適に利用できる、まさにその根底を支える大切な技術なんですね。
目に見えないパケットの世界で、こんなにも細やかな工夫がされているなんて、驚きですよね！
QUICの旅はまだ始まったばかりです。0-RTT（ゼロアールティーティー）接続確立の高速化や、多重化ストリームなど、まだまだ語り尽くせない魅力がたくさんあります。
今回の内容が、皆さんのネットワークへの好奇心をさらに刺激し、日々の業務や学習の一助となれば幸いです。
次回も、パケットの深淵を一緒に探検していきましょう！それでは、また！
コメント