MTUとパケット分割の仕組みをやさしく解説 — なぜ1GBのデータも送れるのか

ネットワーク

インターネットでファイルを送るとき、データは「パケット」という小さな単位に分割されています。では、その1個あたりのサイズはどう決まるのでしょうか。今回はネットワークの基礎中の基礎であるMTUとパケット分割の仕組みを、はじめての方にもわかるよう順を追って解説します。読み終えるころには「1GBの大きなファイルでも、なぜ問題なく送れるのか」がスッキリ理解できるはずです。


そもそもパケットとは何か

ネットワーク通信では、送りたいデータをそのまま一気に送ることはしません。データを「パケット」と呼ばれる小さな単位に分割し、それぞれを順番に送り出しています。

なぜわざわざ細かく分けるのでしょうか。理由はいくつかあります。

  • ネットワーク機器が一度に扱えるデータサイズには上限があるから
  • 途中で1つのパケットが失われても、その分だけ送り直せばよいから
  • 複数の通信が同じ回線を効率よく共有できるから

各パケットには、宛先や順序を示す「ヘッダー」（送り状のような情報）が付いています。これにより、受信側はバラバラに届いたパケットを正しい順序で組み立て直すことができます。


MTUとは「1パケットの最大サイズ」

ここで登場するのがMTU（Maximum Transmission Unit）です。日本語では「最大転送単位」と訳され、ネットワーク上で一度に送信できるパケットの最大サイズ（バイト単位）を表します。

MTUは「パケット1個の最大サイズ」を決めるルールです。これより大きなデータを送りたいときは、必ず分割が必要になります。

代表的なMTU値は以下の通りです。

ネットワーク種別MTU値（バイト）
イーサネット（一般的なLAN）1500
PPPoE（フレッツ光など）1454
IPv6の最小MTU1280
ジャンボフレーム（データセンター等）9000
ループバック（自分自身宛）65536

みなさんが普段ご家庭で使うインターネット回線では、MTUは1500バイトであることがほとんどです。


パケットの中身はどうなっている?

1500バイトのMTUのうち、すべてが「送りたいデータ」というわけではありません。ヘッダー情報が各パケットの先頭に必ず付いています。

アプリケーションが実際に送れるデータサイズをMSS（Maximum Segment Size）と呼び、TCP通信の場合は通常1460バイトになります。MTUからIPヘッダー（20B）とTCPヘッダー（20B）を引いた値です。


本題: 1GBのデータはどうやって送るのか

MTUが1500バイトだとすると、それより大きいファイル（例えば1GB）はどうやって送るのでしょうか。

どんなに大きなデータでも、MTUに収まるサイズに分割すれば問題なく送れます。実際、私たちが普段見ているWebページや動画、クラウドへのアップロードはすべてこの仕組みで動いています。

ステップ1: アプリケーションがデータを渡す

ブラウザやファイル転送ソフトなどが、OSのTCP/IP機能に「この1GBのデータを送ってほしい」と依頼します。アプリ側は分割を意識する必要はありません。

ステップ2: TCPがデータを「セグメント」に分割する

OSのTCP層が、データをMSS（1460バイト）ごとに区切ります。1GBの場合、おおよそこんな数になります。

1GB = 1,073,741,824バイト
÷ 1460バイト ≒ 約735,400個のセグメント

なんと、1GBのファイルは73万個以上に分割されることになります。膨大に思えますが、これがネットワーク通信の日常的な姿です。

ステップ3: 各セグメントにヘッダーを付ける

各セグメントにIPヘッダーとTCPヘッダーが付与され、ちょうどMTUに収まる1500バイトのパケットが完成します。

ステップ4: 送信と再構成

各パケットには「シーケンス番号」が付いているので、受信側はパケットがバラバラの順番で届いても元通りに並べ替えることができます。途中で失われたパケットがあれば、その部分だけ送り直しを要求します。


大事なのは「2種類の分割」を区別すること

ここまでで「データは分割されて送られる」という大枠は理解できたと思います。ですがもう一歩踏み込むと、実は分割には2つの種類があり、これを混同しないことが大切です。

① TCPセグメンテーション（送信前の分割）

送信側のTCP層が、データを送信する前にMSSサイズに区切る作業です。最初から適切なサイズに割っておくため、効率がよく、現代の通信の基本となる動作です。

② IPフラグメンテーション（経路途中での分割）

一方、もし送信したパケットが経路途中でMTUの小さいネットワークに差し掛かった場合、ルーターがパケットをその場で分割することがあります。これがIPフラグメンテーションです。

フラグメンテーションには以下のような問題があります。

  • ルーターのCPU負荷が増え、通信パフォーマンスが下がる
  • 分割されたパケットのうち1つでも失われると、元のデータ全体を送り直す必要がある
  • ファイアウォールによっては分割されたパケットを正しく扱えないことがある

そのため現代のネットワークでは、できるだけ送信前に正しいサイズに区切っておく（＝TCPセグメンテーション）ことが望ましいとされ、経路上の最小MTUを事前に検出するPath MTU Discovery（PMTUD）という仕組みも併用されています。


例え話: 宅配便で本を送る

大量の本を遠方に送ることを想像してみてください。

  • 本の山（1GBのデータ）をそのままトラックに詰むことはできません
  • 段ボール箱（パケット）には積載上限（MTU）があります
  • そこで本を箱詰めし、何百個もの荷物に分けて送ります
  • 各箱には送り状と通し番号（ヘッダーとシーケンス番号）が付いています
  • 受け取り側は番号順に並べて中身を取り出します（再構成）

荷物が多くても、箱に詰めて順番に送れば必ず届く。これがパケット通信の本質です。


応用編: VPNを使うとパケットはどう変わるのか

VPN（Virtual Private Network）を使うと、パケットには新たにヘッダーが追加されます。これはセキュアな通信を実現する仕組みでありながら、MTUとも深い関係があるため、ぜひ押さえておきたいポイントです。

カプセル化: パケットをパケットで包む

VPNの基本的な動作はカプセル化（Encapsulation）と呼ばれます。元のパケット全体を暗号化し、その外側に新しいヘッダーをかぶせて、別のパケットとしてインターネットを流す仕組みです。

ヘッダーが付与されるタイミング

ヘッダーはパケットをVPNトンネルに送り出すたびに付与され、受け取るたびに取り除かれます。リクエストとレスポンスのそれぞれで処理が走ります。

例えばあなたのPCからVPN経由でWebサイトを閲覧する場面を見てみましょう。

リクエスト時（あなた → Webサイト）

  1. あなたのPCが元のパケット（IPヘッダー＋TCPヘッダー＋データ）を作る
  2. VPNクライアントがそのパケット全体を暗号化し、新しいVPN用ヘッダーを外側にかぶせる
  3. 包まれたパケットがインターネットを通じてVPNサーバーまで流れる
  4. VPNサーバーが外側のヘッダーを剥がし、暗号を解いて、元のパケットをWebサイトに転送する

レスポンス時（Webサイト → あなた）

  1. Webサイトが通常のパケットをVPNサーバーに返す
  2. VPNサーバーがそのパケットを暗号化し、新しいVPN用ヘッダーをかぶせる
  3. 包まれたパケットがインターネットを通じてあなたのPCまで流れる
  4. あなたのPCのVPNクライアントが外側のヘッダーを剥がし、暗号を解いて、元のデータをブラウザに渡す

VPNヘッダーは「リクエスト時に1回、レスポンス時に1回」付くというより、パケットがVPNトンネルに入る瞬間に必ず付与され、出る瞬間に必ず外されると捉えると正確です。

VPNオーバーヘッドとMTUの関係

新しくヘッダーが追加されるということは、パケット全体のサイズが大きくなるということです。これをVPNオーバーヘッドと呼びます。代表的なVPNプロトコルのオーバーヘッドはおおよそ以下のとおりです。

VPNプロトコルオーバーヘッド（バイト）
IPsec（ESPトンネルモード）50〜80
WireGuard約60
OpenVPN40〜100
GRE24

例えば元のパケットがちょうどMTU上限の1500バイトだった場合、IPsecで50バイトのヘッダーが追加されると合計1550バイトになり、MTUを超えてしまいます。すると経路途中でフラグメンテーションが発生し、通信が遅くなったり、ファイアウォールによっては破棄されてしまうことがあります。

そのためVPNを使う場合は、元のパケットを最初から小さく（例えば1400バイト程度に）抑える設定が一般的です。具体的には以下のような対応がとられます。

  • VPNインターフェースのMTUを下げる（例: 1400バイトに設定）
  • TCPのMSSクランプ（MSS値を強制的に小さくする設定）を行う

「VPN接続後に特定のサイトだけ遅い」「pingは通るのにWebページが開かない」という現象の多くは、このVPNオーバーヘッドが見落とされた結果として発生します。


その他知っておきたい注意点

UDPはTCPと事情が違う

TCPは自動でセグメンテーション・再送・順序制御をしてくれますが、UDP（リアルタイム通信などで使われるプロトコル）にはそうした機能がありません。UDPで大きなデータを送る場合、アプリケーション側が分割と再構成を実装する必要があります。

送れる ≠ 速く送れる

どんなに大きなデータも理論的には送れますが、実際の転送速度は回線の帯域幅、パケットロス率、遅延、TCPウィンドウサイズなど多くの要因に左右されます。1Gbps回線でも1GBの転送には現実には10秒以上かかることが多いです。


まとめ

本記事のポイントを振り返ります。

  • パケットはデータを送るための小さな単位で、ヘッダーとデータ部分で構成されている
  • MTUはパケット1個あたりの最大サイズ（イーサネットでは1500バイト）
  • 大きなデータはMTUに収まるサイズに分割して送る → 1GBでも1TBでも送信可能
  • 分割には「送信前に行うTCPセグメンテーション」と「経路途中で行うIPフラグメンテーション」の2種類がある
  • IPフラグメンテーションはパフォーマンス低下やトラブルの原因になるため、現代ではTCPセグメンテーションでうまく送れるよう工夫されている
  • VPNを使うとパケットは暗号化＆カプセル化され、リクエスト・レスポンスのたびに新しいヘッダーが付与される
  • VPNオーバーヘッドの分だけ実効MTUが減るため、適切なMTU/MSS設定が必要

普段なにげなく使っているインターネットの裏側では、こうした緻密な仕組みが動いています。MTUとパケットの関係を理解しておくと、ネットワークが遅いときの原因切り分けや、VPN・クラウド設計の場面で役立つはずです。


参考リソース

コメント

タイトルとURLをコピーしました