【実務・中級編】QUICのPath MTU Discovery(PMTUD)の挙動 – HTTPプロトコル・通信規格実践ガイド

TCPの呪縛からの解放：QUICにおけるPMTUDという「見えざる戦い」

こんにちは。ネットワークの深淵を覗き込み続けて早幾年、インフラの現場で「なぜかパケットが消える」「なぜかパフォーマンスが出ない」という怪奇現象と日々格闘している皆さんに、今日は少し踏み込んだ話をしましょう。

HTTP/3の登場により、私たちはTCPのヘッド・オブ・ライン・ブロッキングという長年の呪縛から解放されました。しかし、その裏側で、UDPという「荒野」へ漕ぎ出したQUICは、TCP時代とは全く異なる「パケットサイズ」との戦いを強いられています。それが、Path MTU Discovery（PMTUD）です。

1. なぜQUICでPMTUDが重要なのか？

TCPの場合、パケットの断片化やMTUの調整はOSのネットワークスタックが暗黙のうちに面倒を見てくれました。しかし、UDPベースのQUICは違います。QUICはOSのカーネル空間ではなく、ユーザー空間（アプリケーションレイヤー）でパケットのパッキングを制御しています。

もし、ネットワーク経路上のどこかにMTU（最大転送単位）が1500バイト未満のリンクが存在し、かつQUICパケットがそれを超えてしまったらどうなるか？

IP断片化の回避: QUICの設計思想では、IP断片化を極力避けます。断片化されると、中継ルーターでの負荷増大や、一部のファイアウォールによるパケット廃棄を招くからです。
PMTUDの自律制御: QUICは、自身で最適なパケットサイズを模索する「DPLPMTUD (Datagram Packetization Layer Path MTU Discovery)」を実装しています。これがうまく働かないと、通信がハングアップしたり、再送の嵐に巻き込まれてレスポンスが極端に遅延したりします。

2. QUICにおけるPMTUDのシーケンス

QUICのPMTUDは、主に「プローブ・パケット」の送信と応答によって行われます。

1. 初期値の選定: 最初は、安全なサイズ（通常は1200バイト）から開始します。
2. プローブの送信: 接続が確立されると、QUICスタックはより大きなサイズ（例: 1400バイトなど）のパケットを「プローブ」として送ります。
3. ACKによる確認: 相手側がそのサイズのパケットを無事に受け取ればACKが返ります。これにより「この経路のMTUは1400バイト以上である」と判断し、以降のペイロードサイズを拡大します。
4. ブラックホール対策: もしACKが返ってこない場合、経路のどこかでパケットがドロップされたと判断し、サイズを縮小します。

この「探り」が、HTTP/3の初期通信を高速化させるための非常に繊細な調整弁となっているのです。

3. 実務でのデバッグ：curlで「ブラックホール」を暴く

現場で「特定のAPIだけレスポンスが返ってこない」という相談を受けた際、私がまず疑うのはMTUのミスマッチです。`curl` を使って、QUICの挙動を覗いてみましょう。

–http3を指定し、詳細な通信ログを出力して確認
接続先で何バイトのパケットが送受信されているかを確認する
curl -v –http3 https://api.example.com \
–trace-ascii /dev/stdout \
| grep “Sending” # パケットサイズが想定より小さくなっていないか確認

もし、サーバー側で設定したMTU制限や、ネットワーク経路上のVPN、トンネリング技術によってMTUが削られている場合、Wiresharkで見てみると「1200バイトのパケットは通るのに、それ以上を投げるとACKが一切返ってこない」という典型的なブラックホール現象が観測されます。

4. サーバーサイドでの最適化（設定例）

もしあなたがAPIサーバーのインフラを設計しているなら、UDPの最大パケットサイズを適切に制御する必要があります。例えば、`quic-go` などのライブラリを使用している場合、以下のようにMTU制限を考慮した実装が可能です。

// Go言語による簡易的なQUIC設定例
config := &quic.Config{
// MaxDatagramFrameSizeはPMTUDの結果に合わせて動的に変化するが、
// インフラの物理的な制約がある場合は上限を意識する必要がある
MaxDatagramFrameSize: 1350,
// ハンドシェイク完了時の0-RTTを有効化する設定
EnableDatagrams: true,
}

5. エンジニアへのアドバイス：トラブルシューティングの極意

最後に、現場で「HTTP/3が遅い」と言われたら、以下の手順で切り分けてください。

1. ICMPの確認: 経路上のルーターが「ICMP Fragmentation Needed」を適切に返しているか。これが遮断されていると、PMTUDは機能せず、パケットロスが頻発します。
2. MSS Clampingの再考: 従来のTCP時代の設定（MSS Clamping）が、UDPに悪影響を与えていないか。
3. クライアント環境の確認: VPNを利用しているクライアントでは、カプセル化オーバーヘッドによりMTUが1300バイト程度まで下がることがあります。QUICの実装がこの変動に追従できているかを確認してください。

HTTP/3は確かに魔法のようなプロトコルですが、その魔法は「ネットワーク層の物理的な制約」という現実の上に成り立っています。パケットが光の速度で駆け巡るその先に、どんな制限があるのか。それを想像できるエンジニアこそが、真のインフラスペシャリストだと私は信じています。

さあ、次はあなたの番です。`tcpdump` を片手に、UDPの海へ飛び込んでみましょう。何か困ったことがあれば、いつでもまた聞きに来てください。