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

なぜ「HTTP/3」は郵便物のサイズにこだわるのか？QUICの「PMTUD」を解き明かす

こんにちは！ネットワークの世界へようこそ。

普段、私たちが何気なくWebサイトを見るとき、裏側では膨大なパケットが光の速さで飛び交っています。近年、主流になりつつある「HTTP/3」は、これまでの通信の常識を覆すほどの高速化を実現しました。

その心臓部である「QUIC」というプロトコルは、実は非常に「慎重で賢い郵便局員」のような動きをしています。今回は、QUICが通信の効率を最大化するために行っている「PMTUD（経路最大転送単位の探索）」という仕組みについて、身近な例えを交えながら紐解いていきましょう。

—

1. 郵便物には「サイズ制限」がある？

まず、ネットワークの世界における「パケット」を「郵便物」に例えてみましょう。

インターネットという巨大な道路には、途中にいくつもの「トンネル」があります。このトンネルには高さ制限（MTU：最大転送単位）があって、それを超える大きさの郵便物は通り抜けることができません。

もし、制限を超えたサイズの郵便物を送ってしまうとどうなるでしょうか？

昔のやり方（TCP）： 途中で「大きすぎて通れません！」と門前払いされ、パケットが破棄されてしまいます。すると、また最初からやり直し。これでは時間がかかって仕方ありませんよね。
QUICのやり方： 「この道はどこまで大きな荷物を運べるんだろう？」と、最初から慎重にサイズを確認します。これがPMTUD（Path MTU Discovery）です。

—

2. QUICのPMTUD：まずは「小さく送って確認する」

QUICはUDPというプロトコルを使っています。UDPは「とにかく速く送る」のが得意ですが、その分、途中の道路状況には無頓着です。だからこそ、QUIC自身が賢く振る舞う必要があります。

QUICは、通信を開始する際、いきなり大きな荷物を送りません。まずは「これくらいのサイズなら通れるはず」という安全なサイズで荷物を送り始め、徐々にサイズを大きくしながら「どこまでなら引っかからずに届くか？」をテストしていきます。

これを専門用語で「PMTUプローブ（探索パケット）」と呼びます。

なぜ「0-RTT」と関係があるの？

HTTP/3の目玉機能である「0-RTT（ゼロアールティーティー）」は、接続の手続きをすっ飛ばして即座にデータを送り始める技術です。
もしPMTUDがうまく機能していないと、この0-RTTで送ったデータが「大きすぎて通れない！」というトラブルに遭い、せっかくの高速接続が台無しになってしまいます。だからこそ、QUICはこのサイズ管理にものすごく神経を使っているのです。

—

3. 現場で役立つ！パケットサイズを意識する視点

エンジニアとして、もし「特定の環境でだけHTTP/3の通信がタイムアウトする」という事態に遭遇したら、このPMTUDの失敗を疑ってみましょう。

特に、VPN環境や特殊なトンネルを通る通信では、通常の道路よりさらに高さ制限（MTU）が厳しくなっていることが多いです。そんな時に確認すべきポイントを整理しました。

設定のヒント（概念的なイメージ）

QUICの実装ライブラリ（例えば `quic-go` や `mvfst` など）では、パケットの最大サイズを指定する設定項目があります。もし環境が特殊なら、ここを微調整することが解決の鍵になります。

// Go言語のquic-goライブラリを例にした設定イメージ
config := &quic.Config{
// 初期パケットサイズをあえて少し小さめに設定することで、
// 厳しい制限があるネットワークでの破棄を防ぐ（トラブルシューティング用）
InitialPacketSize: 1200,

// 最大パケットサイズ（通常は1472バイト程度が一般的ですが、環境に合わせて調整）
MaxPacketSize: 1400,
}

※注意：1200バイトという数字は、多くのネットワークで「これなら確実に通る」とされる安全圏のサイズです。

—

4. まとめ：ネットワークは「思いやり」でできている

QUICのPMTUDについて、イメージは掴めましたか？

パケットは郵便物、MTUはトンネルの高さ制限。
QUICは、いきなり大物を送らず、慎重にサイズを測りながら通信する。
トラブル時は「経路のどこかでサイズ制限に引っかかっていないか？」を疑うのが第一歩。

ネットワークの技術は一見すると数式や英語の羅列で難しく見えますが、その本質は「いかに効率よく、かつ確実に荷物を届けるか」という人間味あふれる工夫の積み重ねです。

ぜひ、皆さんも自分の開発環境で「パケットは今、どんなサイズの荷物を運んでいるんだろう？」と想像してみてください。その視点を持つだけで、あなたはもう立派なインフラエンジニアの入り口に立っています！

また次回の記事でお会いしましょう！