【実務・中級編】QUICのパケット番号（Packet Number）のエンコーディング – HTTPプロトコル・通信規格実践ガイド

HTTP/3を支えるQUICの妙技：パケット番号エンコーディングと高速ロス検知の舞台裏

おい、そこの君。Web APIの設計やインフラ運用で日々奮闘している、未来のネットワークの担い手たちよ。最近「HTTP/3」って言葉を耳にする機会が増えたんじゃないか？「なんだか速いらしい」「UDPを使ってるらしい」くらいの認識で止まってないか？それじゃあ、今のWebを動かす心臓部、ひいては次世代のインターネットの深淵を覗き込むことはできないぞ。

今日は、そのHTTP/3の土台を支える「QUICプロトコル」の中でも、一見地味だが実はとんでもなく賢い仕組み、「パケット番号（Packet Number）」のエンコーディングに焦点を当てて深掘りしていく。ただの番号付けだと侮るなかれ。ここにQUICの高速化と信頼性確保の秘訣が隠されているんだ。

なぜ今、QUICのパケット番号なのか？

TCPの時代、パケットロス（パケットが途中で消えちゃうこと）の検知は、主にシーケンス番号とACK（確認応答）の欠落、そしてタイムアウトに頼っていた。でも、この仕組みは良くも悪くも「慎重」で、ロスが起きると再送までに時間がかかったり、ヘッドオブラインブロッキングの問題を引き起こしたりした。

そこでQUICは、TCPが抱えていたこれらの課題を解決すべく、UDPの上で独自の信頼性メカニズムを構築した。その根幹にあるのが、個々のQUICパケットに振られる「パケット番号」だ。

「パケット番号なんて、TCPのシーケンス番号と何が違うんだ？」と思った君、良い質問だ。TCPのシーケンス番号が「バイトストリームのオフセット」を表すのに対し、QUICのパケット番号は文字通り「パケットの識別子」だ。そして、その番号の付け方と送り方が、とんでもなく賢いんだ。

QUICパケット番号の賢さ：可変長エンコーディングの真髄

QUICは、パケット番号を常に単調増加させる。これはTCPと同じく、信頼性の基盤だ。しかし、ネットワークの状況は刻一刻と変わる。ハンドシェイクの初期段階ではパケット数は少ないかもしれないし、安定稼働中は大量のパケットが行き交う。この「状況の変化」に対応するため、QUICのパケット番号は可変長エンコーディングを採用している。

つまり、常に最大のパケット番号を表現できる固定長の領域を確保するのではなく、その時々で必要最小限のバイト数でパケット番号を表現するんだ。これによって、ヘッダのオーバーヘッドを劇的に削減している。

どうやってエンコードするのか？

QUICの仕様（RFC 9000）では、送信側が直前に受信側からACKされたパケット番号（`Largest Acknowledged Packet Number`、略して `LA` と呼ぼう）を基準として、次に送信するパケット番号を「何バイトで表現すれば、受信側が正しく解釈できるか」を判断する。

具体的には、パケットヘッダ内の`Packet Number Length`（PN Length）フィールドがそのサイズを示すんだ。PN Lengthは1バイトから4バイトまでの4段階があり、それぞれ表現できるパケット番号の範囲が異なる。

| PN Length (ビット) | PN Length (バイト) | 表現可能なパケット番号の最大値 |
| :—————– | :—————– | :—————————– |
| 00 | 1 バイト | 63 |
| 01 | 2 バイト | 16383 |
| 10 | 3 バイト | 4194303 |
| 11 | 4 バイト | 1073741823 |

送信側は、現在のパケット番号が `LA` からどれだけ離れているか（より正確には、受信側が次に期待するパケット番号の範囲内に収まるか）を考慮し、最も短いPN Lengthを選択する。

例えば、`LA` が 1000 だったとする。次に送信するパケット番号が 1001 なら、1バイトで表現できる範囲（63まで）では足りない。しかし、1001は16383の中に収まるので、2バイトで十分表現できる。
もし、ネットワークが非常に低速で、ACKがなかなか返ってこないような状況であれば、`LA` と送信するパケット番号の差が大きくなる。その場合は、より大きなPN Length（3バイトや4バイト）を使うことになる。

ポイントは、送信側が「受信側が次にどんなパケット番号を期待しているか」を推測し、それに基づいて最適なエンコーディング長を選ぶという点だ。この賢い機構によって、QUICはヘッダオーバーヘッドを最小限に抑えつつ、広範囲のパケット番号を効率的に扱うことができるんだ。

パケット番号空間 (Packet Number Space)

さらにQUICが賢いのは、パケット番号が「一つだけ」ではない点だ。QUICには以下の3つの独立したパケット番号空間がある。

Initial Space: ハンドシェイクの初期メッセージ（Initialパケット）で使用される。
Handshake Space: ハンドシェイクの中間メッセージ（Handshakeパケット）で使用される。
Application Data Space: ハンドシェイク完了後のアプリケーションデータ（1-RTTパケット）で使用される。

これらが独立しているため、例えばハンドシェイクが完了していなくてもアプリケーションデータを送信開始できる（0-RTTデータ）。また、それぞれの空間で独立してパケットロス検知や輻輳制御が行われるため、セキュリティと効率性を両立しているんだ。

パケットロス検知と順序管理：パケット番号の活躍

さて、この可変長エンコードされたパケット番号が、どのようにロス検知と順序管理に役立つのか。

QUICの受信側は、受信したパケットのパケット番号を記録し、ACKフレームで送信側に通知する。このACKフレームには、受信したパケット番号のリスト（レンジ）と、そのパケットの受信からACK送信までの遅延（`ACK Delay`）が含まれる。

送信側は、ACKフレームを受け取ると、どのパケットが受信されたかを知る。もし、特定のパケット番号がACKされずに、それより後のパケット番号がACKされた場合、送信側は「そのパケットはロストした可能性が高い」と判断する。いわゆる「3つのACK」を待たずに、より早くロスを検知できるんだ。

重要な違い: TCPでは再送されたセグメントには新しいシーケンス番号が振られることがあるが、QUICではロストしたパケットを再送する際も、同じパケット番号を使う。これは、ストリームオフセットとパケット番号が独立しているため、再送によってデータの一貫性が損なわれることがないからだ。受信側は同じパケット番号のパケットを複数回受け取っても、最初のパケットだけを処理すればよい。このシンプルさが、QUICの復旧を高速化する一因になっている。

実務でQUICのパケット番号を覗き込む

理論だけでは腹落ちしないのがエンジニアというもの。実際にHTTP/3の通信を覗いてみよう。

WiresharkでQUICパケットをキャプチャする

QUICのパケット番号エンコーディングの挙動を最も詳細に確認できるのは、やはりWiresharkだ。

1. QUIC通信の準備:
HTTP/3に対応したWebサーバー（例: Nginx 1.25.x以降、Caddy、あるいはCloudflareなどのCDN）を用意するか、アクセスできる環境を見つけよう。
例えば、`https://quic.cloud/` や `https://www.google.com/` などはHTTP/3に対応していることが多い。
2. Wiresharkを起動:
キャプチャインターフェースを選択し、キャプチャを開始する。
3. HTTP/3アクセス:
`curl` コマンドでHTTP/3を使ってアクセスしてみる。

# HTTP/3を明示的に指定してアクセス
curl -v –http3 https://www.google.com/

4. Wiresharkでフィルタリング:
キャプチャを停止し、フィルタバーに `quic` と入力してQUICパケットのみを表示させる。

Wiresharkのパケット詳細ペインで、`QUIC` レイヤーを展開してみよう。
そこには `Packet Number` のフィールドが見えるはずだ。そして、よく見ると `Packet Number Length` (PN Length) フィールドも確認できる。

例えば、以下のような表示が見つかるだろう。

Frame 1: …
Ethernet II, Src: …
Internet Protocol Version 4, Src: …, Dst: …
User Datagram Protocol, Src Port: …, Dst Port: …
QUIC
Header Form: Long Header (Initial) or Short Header (1-RTT)
# もしLong HeaderならInitial/Handshake/RetryなどのTypeが表示
# もしShort Headerなら1-RTT Key Phaseが確認できる
Packet Number Length: 1 # ここが重要！1, 2, 3, 4のいずれかになっているはず
Packet Number: 0x0a (10) # 実際のパケット番号
# …その他のQUICフィールド…

大量のパケットをキャプチャして、`Packet Number Length` の値がどう変化するかを観察してみよう。特に、接続確立の初期段階や、データ転送が活発なフェーズで、異なる長さが使われているのが確認できるはずだ。これは、QUICが状況に応じて賢くエンコーディング長を調整している証拠だ。

curlでのHTTP/3確認（低レベルなパケット番号は直接見えないが…）

`curl` は高レベルのHTTPクライアントなので、QUIC層のパケット番号のエンコーディング自体を直接トレースすることは難しい。しかし、HTTP/3での通信がどのように行われているか、そのパフォーマンスの片鱗を感じることはできる。

HTTP/3を使ってGitHub APIにアクセスし、詳細なトレース情報を表示
curl -v –http3 –trace-ascii trace.log https://api.github.com/users/octocat

`trace.log` を開いてみても、QUICのパケット番号に関する情報は直接は出てこないだろう。しかし、“ で始まる行に、接続確立の速さや、`ALPN` (Application-Layer Protocol Negotiation) で `h3` が選択されている様子などは確認できる。

trace.log の一部（QUICに関する直接の情報は少ないが、h3が使われていることはわかる）

Trying 140.82.113.5…
Connected to api.github.com (140.82.113.5) port 443 (#0)
ALPN, offering h3
ALPN, offering h2
ALPN, offering http/1.1
[HTTP/3] TLSv1.3 (IN), Handshake, Finished (22):
Using HTTP/3 Stream ID: 0 (easy handle 0x7fa3f7805400)

> GET /users/octocat HTTP/3
…

PythonでHTTP/3クライアントを使う（抽象化された世界）

Pythonなどのプログラミング言語でHTTP/3クライアントライブラリを使う場合、通常はQUICの低レベルなパケット番号エンコーディングを意識することはない。ライブラリがその複雑さを吸収してくれるからだ。しかし、裏側で何が起こっているかを知っているかどうかで、トラブルシューティングやパフォーマンスチューニングの際に大きく差が出る。

例えば、`httpx` ライブラリはHTTP/3をサポートしている。

import httpx
import asyncio

async def fetch_http3():
# HTTP/3を有効にしてクライアントを作成
# デフォルトではHTTP/3が優先されるが、明示的に指定することも可能
async with httpx.AsyncClient(http2=True, http3=True) as client:
try:
# HTTP/3対応のエンドポイントにアクセス
# GitHub APIはHTTP/3に対応していない場合もあるので、適宜変更してください
# 例: Cloudflare Pages や Fastly など、HTTP/3を積極的に提供しているサービス
response = await client.get(“https://www.cloudflare.com/”)
print(f”HTTP Version: {response.http_version}”)
print(f”Status Code: {response.status_code}”)
print(f”Response Body (truncated): {response.text[:200]}…”)
except httpx.HTTPStatusError as e:
print(f”HTTP Error: {e}”)
except httpx.RequestError as e:
print(f”Request Error: {e}”)

if __name__ == “__main__’:
asyncio.run(fetch_http3())

このようなコードで、私たちはQUICの恩恵を享受できるわけだが、もしネットワーク問題が発生し、通信が不安定になった場合、「もしかしたら、パケットロスが頻繁に発生し、QUICがパケット番号を大きなサイズでエンコードせざるを得なくなっているのかも？」といった仮説を立て、Wiresharkでの詳細調査に進むことができる。この「なぜ？」を掘り下げる力が、真のエンジニアリングの醍醐味だ。

まとめ：見えない賢さが、Webの未来を拓く

今日の話は、QUICのパケット番号エンコーディングという、一見すると地味なメカニズムに焦点を当てた。しかし、この「可変長エンコーディング」と「パケット番号空間」という賢い設計が、UDPというシンプルなプロトコルの上に、TCPを超える信頼性と高速性を築き上げているんだ。

ネットワークの裏側で、パケット番号が刻々と変化し、ロストしたパケットを効率的に再送し、そして最適なヘッダサイズでデータを運び続ける。この見えない部分の最適化こそが、HTTP/3がWebのユーザー体験を劇的に改善する原動力になっているんだ。

君たちがWeb APIを設計し、インフラを運用する際、ただ「HTTP/3は速い」と漠然と理解するだけでなく、その「速さ」の根源にあるQUICの賢さを知っていれば、より堅牢で高性能なシステムを構築するためのヒントが得られるはずだ。

さあ、これからもWebの深淵を覗き込み、その仕組みを理解し、次世代のインターネットを君たちの手で切り拓いていってくれ。今日の話が、その一助になれば幸いだ。