通信速度が速くても、大きいパケットが通るとは限らない
道路の制限速度と、トンネルを通れる車の大きさを分けるように、通信速度とMTUを区別します。回線が高速であっても、一つのIPパケットを運べる最大サイズが大きいとは限りません。逆にMTUを大きくすれば、すべての通信が速くなるわけでもありません。相手までの経路、機器、上位プロトコルの条件が関わります。
ここではMTUをIP層のパケット全体の上限として読みます。アプリの本文だけでなく、IPヘッダも含みます。Ethernetのフレーム長、ファイルの大きさ、TCPが扱うデータ部分の上限を、そのまま同じ数値として比較しないでください。資料の図で、どこからどこまでを測るかを囲むと混同を防げます。
通信速度
- 単位はbit/sなど
- 一定時間に運べる量
- 転送時間を考える材料
MTU
- 単位はバイト
- 一つのIPパケットの上限
- 経路を通る大きさの制約
回線速度からMTUを計算することはできません。
経路MTUは、最も小さいリンクで決まる
自作例として、端末からサーバーまでのリンクMTUが順に1500、1400、1500バイトだとします。分割せずその経路を通れるIPパケットの上限は1400バイトです。最初のリンクが1500だからといって、途中も1500を通せるとは限りません。三つの平均1466.7を取るのではなく、最小値を探します。
RFC 8201は、経路MTUを経路上のリンクMTUの最小値として定義しています。送信側が最初から全経路を知っているわけではないため、その制約を発見する仕組みがPMTUDです。経路が変われば値も変わる可能性があり、一度調べた値をどの通信でも永久に使えるとは考えません。
- 1
端末側リンク
MTU 1500バイト
- 2
途中のリンク
MTU 1400バイトが制約
- 3
サーバー側リンク
MTU 1500バイト
- 4
経路全体
分割なしの上限は1400バイト
帯域や実際のインターネット経路を再現した図ではなく、最小値を読むための自作例です。
MSSはヘッダを除いたTCPデータの上限
MSSはTCPのデータ部分の最大サイズを表す情報で、MTUとは測る範囲が異なります。単純化して、IPv6の基本ヘッダ40バイト、TCPの基本ヘッダ20バイトだけを使う場合を考えます。IPパケット上限1400バイトに収めるTCPデータは1400−40−20=1340バイトです。上限が1500なら同じ条件で1440バイトになります。
この引き算は、ヘッダの条件を固定した学習例です。拡張ヘッダ、TCPオプション、トンネルの外側のヘッダなどがあれば、実際に送るデータ量の調整が必要です。MSS通知値の扱いと、オプションを含む実パケットの構成も区別します。RFC 6691を確認し、どのヘッダを引いた式かを明示しましょう。
MSSはTCPの用語です。UDPのデータグラムに同じ仕組みがそのままあると置き換えないでください。またMSSの値が分かっただけで、相手までの全リンクのMTUを確認したことにはなりません。通信の開始時に得る情報と、通信途中に得る経路情報を分けて読みます。
| 条件を固定した計算 | IP全体の上限 | TCPデータ部分 |
|---|---|---|
| IPv6基本40+TCP基本20 | 1500バイト | 1440バイト |
| IPv6基本40+TCP基本20 | 1400バイト | 1340バイト |
| 追加ヘッダあり | 経路・設定に依存 | 追加分も考慮する |
MSSの通知値と、実際に送るTCPデータ長を分ける
MSSオプションは、自分が受信できるTCPデータの最大サイズを相手へ知らせる情報です。相手から受けたMSSは自分の送信側の制約になり、自分が通知したMSSは相手の送信側の制約になります。送受信の両方向で常に同じ値になるとは限らず、この通知だけで途中のリンクMTUを測定したことにもなりません。
RFC 9293 §3.7.1は、相手のMSSとIP層の送信可能な大きさを考慮して、実際に送るデータ長を決めると説明しています。MSSオプションの値を計算するときは固定のIP・TCPヘッダを差し引き、実際の送信時には追加するオプション等の分もデータ長を調整します。RFC 6691の説明はRFC 9293へ統合されています。
| この例の条件 | パケットへ収めるデータの上限 | 確認点 |
|---|---|---|
| 経路MTU1400、IPv6基本40、TCP基本20 | 1340バイト | IP全体とデータ部分を分ける |
| 上と同じ経路、TCPオプション12を追加 | 1328バイト | 追加ヘッダも同じ1400の中へ入る |
| さらに相手のMSS通知1200、TCPオプション12 | 1188バイト | 1200の枠からもオプション12を差し引く |
相手から受けたMSSが1200で、同じTCPオプション12バイトを付ける例では、固定ヘッダだけを前提とする1340と1200の小さい方から12を引き、1188バイトとします。相手のMSSにも追加オプションの枠が含まれるため、経路の上限だけから引いて終わりにしません。上限が1328や1188でも、アプリから渡されたデータが小さい場合など、実際のパケットはそれより小さくなります。MSS・MTUは、転送量や通信速度の実測値そのものではありません。通信開始時の通知、経路の制約、各パケットのヘッダとデータという三つを分けると、表の条件が変わっても計算できます。
TCPとUDPの役割で通信方式を確認し、IPv4とIPv6で途中のルーターができる処理を整理してください。運用の設定値は実機・方式に依存するため、この計算例の値を一律の設定値にはしません。
IPv6の途中のルーターは、その場で断片化しない
IPv6では、経路上のルーターが大きすぎるパケットをその場で断片化して転送する方式ではありません。必要な断片化は送信元が行います。RFC 8201のPMTUDでは、転送できないルーターがパケットを破棄し、ICMPv6のPacket Too Bigで制約を知らせ、送信側が送る大きさを調整する流れを扱います。
送信元が断片化できることと、必ず断片化することは同じではありません。上位層が小さいパケットになるよう分けて送る方法もあります。IPv4とIPv6の一般的な比較はIPv4・IPv6の違いに譲り、本記事では途中の制約をどう知るかに焦点を当てています。
小さい要求だけ成功するときも、原因を一つに決めない
名前解決や小さい要求は通るのに、大きいデータの送受信が進まない場合は、経路のサイズ制約や必要な制御メッセージが届くかを調べる余地があります。ただし同じ症状は、アプリ側の制限、時間切れ、認証、負荷などでも起こり得ます。「小さい通信は成功した」だけでMTU障害と診断しないでください。
運用では管理者の手順に従い、問題が起きる宛先・時刻・通信方式・データの大きさを記録し、正常時との差を比較します。ファイアウォールを一括で無効にすることを解決策にしないでください。ICMPv6の必要な処理と不要な通信の制御は、セキュリティ方針に沿って設計・検証する対象です。
VPNで外側のヘッダが加わると、内側のパケットに使える大きさが変わることがあります。しかし差し引く値は方式や構成によります。「VPNなら必ず何バイト」と決めつけず、どの層のMTUを見ているかと、カプセル化の範囲を確認します。
問題演習では、三つの条件を言い直す
リンクが1500・1300・1400バイトになったら経路MTUは1300です。先ほどと同じ基本ヘッダだけならTCPデータの計算値は1240バイトになります。経路の最小値を選ぶ段階と、ヘッダを引く段階を分けて説明してください。片方だけ正しくても、最終的なデータ量を間違えることがあります。
モバイル2級の問題集ガイドでは、用語・構成図・単位計算を分けて教材を選ぶ確認点を扱っています。通信の到達と処理完了の違いは再送と冪等性へ進めます。MTUの知識だけでシステム全体の信頼性を説明せず、層ごとの責任を整理して復習しましょう。