こんにちは！ネットワークの裏側を覗き見するのが大好きな、技術メディアの主筆ライターです。
インフラの世界へ足を踏み入れたばかりの頃、「パケットが分割される（フラグメンテーション）」という現象に出会って、頭を抱えたことはありませんか？「大きな荷物を小さく分けるのは分かるけれど、どうやって元通りに組み立て直しているの？」「あの複雑な数字は何を意味しているの？」――そんな疑問を持ったあなたは大正解です。
今回は、ネットワークの基礎でありながら、トラブルシューティングの現場でも超重要なIPヘッダーの仲間である、「フラグメントオフセット」と「More Fragments（MF）フラグ」の挙動について、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. なぜパケットは分割されちゃうの？（身近な例えでイメージしよう）
ネットワークの世界には、一度に運べる荷物の最大サイズである MTU（Maximum Transmission Unit） という「ダンボール箱の大きさ制限」が存在します。例えば、一般的なイーサネットという規格では、このダンボール箱の大きさは通常 1500バイト までと決まっています。
もし、あなたが 3000バイト もある巨大な手紙（データ）を送ろうとしたらどうなるでしょうか？
そのままではダンボール箱に入りませんよね。そこでルーターなどの親切な中継地点が、「じゃあ、この手紙をちょうどいい大きさに破って、複数の小分けの箱に入れ直して送ろう！」と判断します。これがパケットの分割（フラグメンテーション）です。
ここで、現場のエンジニアが直面する大きな疑問が生まれます。
「バラバラになった複数の小包が、途中でバラバラのルートを通って届いたとき、どうやって元の『3000バイトの正しい順番の手紙』に復元するの？」
このパケットパズルを華麗に解き明かす鍵が、IPヘッダーの中に隠されている More Fragments（MF）フラグ と フラグメントオフセット なのです。
—
2. パケットの「しおり」：More Fragments (MF) と フラグメントオフセットの正体
分割されたパケット（フラグメント）たちは、それぞれが独立したIPパケットとして宛先に向かって旅立ちます。その時、すべての分割パケットのIPヘッダーには、元のパケットがどういう状態だったのかを伝える「共通のID（識別子）」と、以下の大切な目印が書き込まれます。
More Fragments (MF) フラグ：「続きはあるか？」のサイン
- 意味: 「まだこの後ろに、同じ元のパケットから分裂した仲間（続きの小包）が続くよ！」ということを表す1ビットのフラグです。
- 挙動:
- 途中の分割パケット：
MF = 1（まだ続くよ！） - 最後の分割パケット：
MF = 0（これで最後だよ！）
フラグメントオフセット：「私は元の手紙のどの位置にいたか？」の住所
- 意味: 分割された破片が、「元のデータの最初から数えて、何番目の場所にあったデータなのか」を示す位置情報（オフセット）です。
- ポイント: ネットワークの世界では、この位置は「バイト単位」ではなく、「8バイトを1つのマス目（単位）」として数えて指定するというルールがあります。ここが少しだけ頭を悩ませるポイントですが、一歩ずつ見ていけば怖くありません！
—
3. 具体例で計算してみよう！フラグメントオフセットの仕組み
百聞は一見に如かず。具体的な数字を使って、フラグメントオフセットがどのように計算されるのかを見てみましょう。
いま、アプリケーション層から 3000バイト のデータ（IPヘッダーの基本サイズ20バイトを除くと、実データが2960バイトと仮定します）を送るとします。しかし、途中の経路のMTU制限で、最大 1500バイト （IPヘッダー20バイト＋データ1480バイト）にしか分割できないとしましょう。
このとき、データは綺麗に 2 つのパケットに分割されます。
パケット 1 の場合（前半戦）
- 運ぶデータ量:
1480バイト - MFフラグ: まだ後ろに続きがあるので
MF = 1 - フラグメントオフセット: 元データの先頭なので
0
パケット 2 の場合（後半戦）
- 運ぶデータ量: 残りの
1480バイト - MFフラグ: これで最後なので
MF = 0 - フラグメントオフセットの計算:
- パケット1が、元のデータの先頭から
1480バイト分をすでに運びました。 - オフセットの単位は「8バイト」なので、
1480 ÷ 8 = 185という計算になります。 - つまり、パケット2のフラグメントオフセットの値は
185と書き込まれます！
受信側のコンピュータは、この「オフセット = 185」という数字を見て、「おっ、このパケットは先頭から 185 × 8 ＝ 1480バイト目以降のデータだな！」と正確に理解し、パケットが届く順番が前後してしまっても、正しい並び順にパズルを組み立て直すことができるのです。
—
4. 実務での視点：フラグメンテーションは「悪者」？
ここまで美しい仕組みを見てきましたが、実際のネットワーク運用・インフラ構築の現場では、「フラグメンテーション極力発生させないこと」がプロのエンジニアの鉄則とされています。
なぜなら、分割と再構築の処理はルーターや受信端末のCPUに余計な負荷をかけますし、もし分割されたパケットのうちの1つでも途中でロスト（消失）してしまった場合、IPの仕組みは「一部が欠けたから、もう一度最初の巨大なパケット丸ごと再送してね」という非情な挙動をとるため、ネットワーク全体のパフォーマンスがガクンと落ちてしまうからです。
現代のWebセキュリティやクラウドアーキテクチャ（AWSやAzureなどのVPC環境など）では、あらかじめ通信経路の最大サイズをピタリと合わせる 「Path MTU Discovery (PMTUD)」 という仕組みや、ルーターでそもそも分割を禁止する 「Don’t Fragment (DF) フラグ」 を立てた通信が主流になっています。
パラメータ確認の実用コマンド例
Linux環境などで、ネットワークインターフェースのMTUや、パケットの挙動を確認・調整するための実用的なコマンドをいくつかご紹介します。実務のトラブルシューティングの際にご活用ください。
# 1. 現在のネットワークインターフェース（例: eth0）のMTUサイズを確認する
ip link show eth0
# 出力結果の「mtu 1500」といった数値が、現在のダンボール箱の大きさです。
# 2. 意図的にMTUのサイズを変更する（※慎重に実行してください）
sudo ip link set dev eth0 mtu 1400
# 3. 特定の宛先に対して、DFフラグ（分割禁止）を立てた状態でパケットを飛ばし、
# 途中で「分割が必要だよ」と言われないかテストする（Linuxのpingコマンド例）
# -M do は「Don't Fragmentフラグを立てて、かつルーターで勝手に分割するな」という指定です。
ping -c 3 -M do -s 1472 8.8.8.8
# ※もし指定したサイズが大きすぎて途中のルーターのMTUを超過している場合、
# 「frag needed and DF set (MTU: 1400)」のようなエラーが返ってきて、
# 正しいPath MTUの大きさを特定するヒントになります。—
5. まとめ
今回は、IPヘッダーの奥深くに隠された フラグメントオフセット と More Fragmentsフラグ の世界を紐解きました。
- MTU という箱に入らない大きなデータは分割される。
- More Fragments (MF) は「まだ続きがあるよ」という仲間の存在を知らせるサイン。
- フラグメントオフセット は「元のデータのどこに位置していたか」を8バイト単位で示す住所。
- 受信側は、この2つの情報を使って、バラバラに届いたパケットを完璧にパズルように復元する。
一見すると難解なビットやフラグの仕組みも、裏側で動いている「データを無事に正確に届けるための工夫」というストーリーを知ると、ネットワークのロマンを感じずにはいられませんよね。
日々のインフラ構築やトラブルシューティングでパケットキャプチャツール（Wiresharkなど）を開く機会があれば、ぜひ今日の話を思い出して、実際のヘッダーの中身を覗いてみてください。きっとなんの変哲もない数字の羅列が、生き生きとしたメッセージに見えてくるはずです。
それでは、また次回のテクニカル・アドベンチャーでお会いしましょう！
コメント