【入門編】QUICにおけるMTU探索(Path MTU Discovery) – HTTPプロトコル・通信規格実践ガイド

【HTTP/3超入門】なぜQUICは「荷物のサイズ」を自動調整できるのか？～パケットの限界に挑む「MTU探索」の仕組み～

みなさん、こんにちは！今日から一緒にネットワークの深い世界を探検していきましょう。

Webの世界は今、大きな変革の真ん中にあります。従来の「HTTP/1.1」や「HTTP/2」で使われていたTCPという通信プロトコルから、UDPをベースにした最新プロトコル「QUIC（クイック）」、そしてそれを利用する「HTTP/3」へと、急速にシフトが進んでいるのをご存じでしょうか？

QUICは、Webページの表示を圧倒的に速くし、スマホの回線が切れても通信を維持できるなど、夢のようなテクノロジーです。しかし、その裏側には「一度にどれくらいの大きさのデータを送れるか？」という、地味ながら非常に重要な課題が存在します。

今回は、ネットワークに初めて触れるエンジニアの方でもスムーズに理解できるように、現実世界の「配送トラックとトンネル」の例えを使いながら、QUICにおける「MTU探索（Path MTU Discovery）」の仕組みをわかりやすく紐解いていきます。

難しそうな用語が出てきても大丈夫。一歩ずつ理解していきましょう！

—

1. そもそも「MTU」ってなに？～トラックとトンネルの物語～

まずは基礎知識となる「MTU」という言葉から整理していきましょう。

MTUは「道路を通れる最大のトラックの高さ」

インターネット上でデータを送るとき、大きなデータは小さな固まり（パケット）に分割されて送られます。この「1回の送信で送ることができる最大のデータサイズ」のことを、ネットワーク用語で MTU（Maximum Transmission Unit：最大転送単位） と呼びます。

一般的に、ご家庭やオフィスのLAN（Ethernet）では、1回につき1500バイトまでのデータを送ることができるように設定されていることが多いです。

これを現実世界の「配送トラック」に例えてみましょう。

パケット ＝荷物を積んだ配送トラック
MTU ＝トンネルの高さ制限
ルーター（中継機器） ＝途中の検問所や道路

ある会社（送信元サーバー）が、大きなトラックに荷物を満載して出発させたとします。しかし、目的地に到着するまでの途中には、いろいろな道路やトンネルが存在します。

もし、途中の道に「高さ制限が1200バイト分しかない狭いトンネル」があったらどうなるでしょうか？

当然、大きなトラックはトンネルを通ることができませんよね。

パケットの断片化（フラグメンテーション）という悲劇

昔のネットワーク（TCPなど）では、トンネルの手前にいるルーターが「おっと、このトラックは大きすぎて通れないな。仕方ない、荷物を2台の小さな軽トラに積み直してあげよう！」と親切に荷物を小分けにしてくれていました。

これが「パケットの断片化（フラグメンテーション）」です。

一見親切に見えますが、実はこれ、ネットワークの世界では大問題なのです。

1. ルーターにものすごい負荷がかかる（荷物の積み替え作業で時間がかかる）
2. 途中で1台でも軽トラが事故に遭うと、全体の荷物が届かなくなる
3. セキュリティ上の理由で、積み替えられた荷物を捨てるルーターが増えた

そのため、現代のインターネットでは「荷物の積み替え（断片化）は禁止！最初からトンネルを通れるサイズのトラックで送ってください！」というルールが基本になっています。

では、送信元のサーバーは、どうやって「目的地までの道中で一番狭いトンネルの高さ（最小MTU）」を知ればよいのでしょうか？

ここで登場するのが「MTU探索（Path MTU Discovery）」という仕組みです。

—

2. 従来のやり方と「ブラックホール問題」

QUICの仕組みを見る前に、これまでの通信（TCPなど）がどうやってトンネルの限界を調べていたのかをサクッと知っておきましょう。

従来のPMTUD（Path MTU Discovery）

1. サーバー：「とりあえず大きめのトラック（1500バイト）で送ってみよう！」
2. 途中のルーター：「無理無理！このトンネルは1200バイトまでだよ！」
3. 途中のルーター：「送信元さんへ！大きすぎたから荷物を捨てました！次は1200バイト以下で送ってください！」という手紙（ICMPエラー通知）を送り返す。
4. サーバー：「なるほど！じゃあ次は1200バイトで送るね！」

とても理にかなった仕組みですよね。しかし、ここに大きな落とし穴がありました。

「手紙が届かない！」ブラックホール問題の発生

現代のインターネットでは、セキュリティ（ファイアウォール）が非常に厳しくなっています。多くのネットワーク管理者が、セキュリティ上の懸念から「このICMPエラー通知という手紙」を危険物とみなして途中で捨ててしまうようになったのです。

するとどうなるでしょう？

サーバー：「あれ？荷物が届いてないみたいだな。もう一回同じ1500バイトのトラックで送ろう」
ルーター：「やっぱり通れないや（捨てちゃう）」
サーバー：「返事がないな…もう一回送ろう…」

サーバーは「トラックが大きすぎて通れない」ことすら気づけず、データが闇の中に消えていきます。これがネットワーク業界で恐れられている「PMTUブラックホール（暗黒の落とし穴）」です。

通信がピタッと止まり、Webページがいつまでも読み込まれない原因の多くは、このブラックホールにありました。

—

3. QUICの革命！「DPLPMTUD」ってどんな仕組み？

そこで誕生したのが、QUICプロトコルです。

QUICは、ファイアウォールに捨てられやすいICMP手紙（エラー通知）に頼るのをやめました。代わりに、「自分たちの通信（UDP）だけで、安全にトンネルのサイズを測る仕組み」を開発したのです。

この画期的な仕組みを専門用語で DPLPMTUD（Datagram Packetization Layer Path MTU Discovery）と呼びます。名前は長くて難しそうですが、やっていることは「安全なサイズから、お試しで少しずつトラックを大きくしていくゲーム」のようなものです！

さっそく、そのステップを見てみましょう。

QUICのMTU探索 4つのステップ

[サーバー] [クライアント]
│ │
│ 1. 安全サイズ(1200B)で通信開始 │
├────────────────────────────────────────────────────►│ (届いた!)
│ │
│ 2. お試し(1350B)の「水増しパケット」を送る │
├────────────────────────────────────────────────────►│ (届いた!)
│ ◄───────────────────────────────────────────────────┤ (返事: OK!)
│ │
│ 3. さらに巨大(1500B)の「水増しパケット」を送る │
├─────────────────────────────── X (トンネルで失敗) │ (届かない…)
│ │
│ 4. 返事が来ないので「1350B」が限界だと確定！ │
├────────────────────────────────────────────────────►│ (1350Bで快適通信)

ステップ1：最初は絶対に通れる「ミニトラック（1200バイト）」からスタート

QUICのルールでは、通信の始まりは「1200バイト」という、インターネット上ならほぼ確実に通れる小さなサイズからスタートすることになっています。まずは安全第一です。

ステップ2：お試しの「ダミー荷物（PADDING）」を積んでサイズを調べる

「もっと大きなトラックで一度にたくさん送りたいな」と思ったら、サーバーはお試し用のパケットを送ります。

このとき、もし重要なデータを詰めたトラックがトンネルで潰れてしまったら困りますよね。そこでQUICは、中身のほとんどが空っぽの「PADDING（ダミーデータ）」で満たしたテスト用のパケットを作ります。

「1350バイトのお試しトラックを通してみよう！」
トラックの中身：本物のデータ＋ 残りは全部ダミー（PADDING）

ステップ3：相手からの「届いたよ！（ACK）」を待つ

もしこのお試しトラックが無事に相手（スマホやブラウザ）に届くと、相手は「1350バイトの荷物、ちゃんと届いたよ！」と返事をくれます（これがACKと呼ばれる確認応答です）。

返事が来たら、サーバーは「よし！この道は1350バイトまで通れるぞ！」と確信できます。

ステップ4：届かなかったら「1つ前のサイズ」に戻す

もし、さらに大きな1500バイトのお試しトラックを送って、一定時間返事が来なかったらどうするでしょうか？

QUICは「あ、どこかのトンネルでつかえて落ちたんだな」と判断し、通信を止めることなく、最後に成功したサイズ（1350バイト）を上限として採用します。

外部のエラー通知（ICMP）に頼らず、「届いたか、届かなかったか」という自分の目だけで判断するため、ブラックホールに落ちることが絶対にないのです！素晴らしい仕組みですね！

—

4. 実際にコードや設定で見てみよう！

ここからは、インフラエンジニアやWebエンジニアのみなさんが、実際の現場でどう設定やデバッグを行うのか、具体的な例を見ていきましょう。

NGINX（HTTP/3対応）での設定例

最近のNGINXは、標準でHTTP/3およびQUICに対応しています。OSやルーターのMTU設定と連携できるよう、適切なUDPソケット設定を行います。

server {
# UDPの443番ポートでQUIC(HTTP/3)を有効化します
listen 443 quic reuseport;

# TCPの443番ポート(HTTP/2やHTTP/1.1用)も念のため開けておきます
listen 443 ssl;

server_name example.com;

# SSL/TLS証明書の設定
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# クライアントに「このサイトはHTTP/3に対応していますよ」と教えるヘッダー
add_header Alt-Svc ‘h3=”:443″; ma=86400’;

location / {
root /usr/share/nginx/html;
index index.html;
}
}

※NGINXの内部にあるQUICスタックが、自動的に先ほど説明した「PADDINGパケットを使ったMTU探索（DPLPMTUD）」を実行してくれます。エンジニアが面倒な計算をして設定ファイルにMTUの数値を手書きする必要はありません！

—

プログラムで見る「パケットの穴埋め（PADDING）」のイメージ

QUICのライブラリ内部で、MTU探索用のパケットがどのように作られているのか、雰囲気を掴むための疑似的なPythonコードを用意しました。

「ダミーデータで長さを増やす」という感覚をコードで体感してみましょう！

QUICにおけるMTU探索パケット作成のイメージコード

DEFAULT_QUIC_MIN_MTU = 1200 # QUIC規格で定められた最小安心サイズ
TARGET_PROBE_MTU = 1472 # 探りたい目標の最大サイズ (例: 1472バイト)

def create_mtu_probe_packet(target_size: int) -> bytes:
“””
指定されたサイズ(target_size)にぴったり合わせるため
PADDING(ダミーデータ)を詰めたMTU探索用パケットを生成します。
“””
# 1. 本物の制御データ（PINGフレームなど「返事ちょうだい！」という命令）
# ※実際のQUICではPINGフレーム(0x01)などが使われます
payload = b’\x01′ # PINGフレームの代わり

# 2. 現在のパケットサイズを計算
current_length = len(payload)

# 3. 目標のサイズに達するまで、0x00 (PADDING) で埋め尽くす！
if current_length < target_size: padding_needed = target_size - current_length # 0x00 のバイト列を必要な長さだけ結合 payload += b'\x00' padding_needed print(f"[送信準備] パケットを {len(payload)} バイトに水増ししました。") return payload --- 実行してみる --- 1472バイトのお試しトラック（パケット）を作成！ probe_packet = create_mtu_probe_packet(TARGET_PROBE_MTU) これをUDPで相手に送信し、返事(ACK)が来るかタイマーを測って観察するこのように、本物のデータのうしろに `0x00` という無意味なデータをズラーッと並べてわざと巨大なパケットを作り、相手に送ってみるのがQUICの賢い工夫なのです。

—

Wireshark（パケット解析ツール）で観察するときのヒント

もし将来、ネットワークのトラブルシューティングでパケット解析ツール「Wireshark」を使う機会があれば、フィルタ機能で以下のように検索してみてください。

パケット検索フィルタ: `quic`
チェックするポイント:

1. 通信の最初に `1200 bytes` のパケットが飛んでいるか？
2. その後、 `1350 bytes` や `1400 bytes` といった、少しずつ大きなパケット（`QUIC PADDING` が含まれたもの）が送信されているか？

実際のパケットキャプチャ画面で、サイズが段階的に大きくなっていく様子を見つけられたときは、「あ！今QUICがトンネルのサイズを測ってるな！」と感動すること間違いなしです！

—

5. まとめ：パケットの大きさを制するものは、Webの速度を制す！

今回は、HTTP/3の要である「QUICプロトコルにおけるMTU探索（DPLPMTUD）」について解説しました。

最後に、重要ポイントを振り返っておきましょう！

1. MTUは「道路を通れるトラックの最大サイズ」のこと。
2. パケットの断片化（小分け）は悪！ 途中で荷物が崩れる原因になるため、現代では禁止が主流。
3. 昔のやり方（ICMP頼み）はブラックホールに落ちるリスクがあった。
4. QUICは「ダミーデータ（PADDING）」を詰めたお試しパケットを使い、自力で安全にトンネルの限界サイズを探索する！

QUICが「なぜこんなに速くて途切れないのか」という理由の裏には、こうした目立たないけれど非常に緻密で賢い仕組みが詰まっています。

ネットワークの知識は一見難しそうに思えますが、身の回りの配送や交通ルールに置き換えてみると、とても人間味あふれる面白い設計になっていることがわかりますよね。

インフラやネットワークに触れ始めたばかりのエンジニアのみなさんも、ぜひこの「パケットたちの小さな冒険」に思いを馳せながら、Webテクノロジーを楽しんで学んでいってくださいね！

一歩ずつ、一緒にマスターしていきましょう！