「断片化」という名のパケットの迷宮：IPv4フラグメンテーションの深淵を覗く
ネットワークエンジニアとして現場に立っていると、たまに説明のつかない「通信の揺らぎ」に出くわすことがあります。特定のAPIエンドポイントだけがパケットサイズによって謎のタイムアウトを起こす、あるいは特定のルーターを通過するとパケットが消失する……。
その犯人の多くは、「IPフラグメンテーション」です。
今日は、教科書で見た記憶はあるけれど、実務ではあまり意識したくない（しかし避けては通れない）IPv4ヘッダーの Identification, Flags, Fragment Offset という3つのフィールドについて、現場の泥臭い視点から解説します。
—
1. なぜパケットは「バラバラ」にされるのか
ネットワークには、その回線が一度に運べるデータの最大サイズである MTU (Maximum Transmission Unit) という壁が存在します。一般的なEthernetのMTUは1500バイトです。
もし、あなたが設計したWeb APIのレスポンスがこのサイズを超えてしまったら？ 経路上のルーターは、親切心（あるいは義務感）でパケットを細切れにします。これがフラグメンテーションです。
再構築を司るのが、IPv4ヘッダー内の以下の3要素です。
Identification(16bit): 「これは同じパケットの断片ですよ」と証明するためのID。Flags(3bit): 分割の許可（DFビット）や、続きがあるか（MFビット）を示すフラグ。Fragment Offset(13bit): 先頭から数えて何番目のデータかを示すパズルピースの位置情報。
—
2. 現場を苦しめる「DFビット」のジレンマ
現代のネットワーク設計において、フラグメンテーションは「悪」と見なされることが多いです。なぜなら、分割されたパケットの一部でも欠ければ、受信側はパケット全体を破棄せざるを得ず、再送コストが跳ね上がるからです。
そこで使われるのが Flags フィールドの DF (Don't Fragment) ビットです。「分割禁止」を宣言することで、ルーターは分割する代わりに ICMP Destination Unreachable (Fragmentation Needed) を返し、通信元に「MTUサイズを下げろ」と要求します。
これが PMTUD (Path MTU Discovery) の仕組みです。
実務でのデバッグ：MTUを疑うべき瞬間
もし、curl で小さいデータは取れるのに、大きなJSONを取得するとハングアップするなら、間違いなくMTU問題です。以下のコマンドで確認してみましょう。
# DFビットを立てて、サイズを指定してpingを打つ（Linuxの場合）
# -M do は「フラグメント禁止」、-s はペイロードサイズ
ping -M do -s 1472 192.168.1.1もしここで Frag needed and DF set が返ってきたら、経路上のどこかでMTUが1500を下回っています。
—
3. 再構築のロジック：パズルを組み立てる
パケットが断片化されると、受信側のOSスタックは Identification が同じパケットをメモリ上で突き合わせ、Fragment Offset を見て順番に並べ替えます。
ここで重要なのは、「MF (More Fragments) フラグ」が 0 になるまで受信側は待ち続けるという点です。もし途中のパケットが1つでも落ちれば、受信側はタイムアウトまでリソースを占有し続け、最終的にパケットを破棄します。これがWeb APIの「謎の遅延」の正体です。
—
4. エンジニアがコードでケアすべきこと
現代のWeb開発では、OSやライブラリが自動的にフラグメンテーションを処理してくれます。しかし、クラウドネイティブな環境（VPNやトンネリング技術が絡む構成）では、オーバーヘッドによってMTUが実質的に減少することがあります。
PythonによるMTU制限の確認例
APIクライアントを作成する際、大きなリクエストを送る場合は、requests 等でタイムアウトだけでなく、経路のMTUを意識した設計が求められます。
import requests
# 巨大なペイロードを送信する際のトラブルシューティング用
# 経路のMTUが小さい環境では、意図的にセグメントサイズを小さくする設計が必要になる
def send_large_data(url, data):
try:
# ストリーミング送信を活用することで、一度に巨大なバッファを確保しない
response = requests.post(url, data=data, stream=True, timeout=10)
return response.status_code
except requests.exceptions.ConnectionError as e:
# ここでConnectionErrorが頻発する場合、MTU問題によるパケットドロップを疑う
print(f"通信経路のMTU問題の可能性: {e}")
# 実際の実務では、API Gateway側で設定されたMTU制限を確認するのが先決—
5. 凄腕エンジニアからのアドバイス
実務において、フラグメンテーションのトラブルに直面したら、まずは以下のステップで切り分けを行ってください。
1. パスの確認: traceroute で経由しているルーターやVPNゲートウェイを特定する。
2. パケットキャプチャ: tcpdump を使用し、ip[6] & 0x40 != 0 (DFビットが立っているパケット) をフィルタリングして、どこでパケットが止まっているかを確認する。
3. MSS調整: TCP通信であれば、ハンドシェイク時に MSS (Maximum Segment Size) を小さくネゴシエーションさせる設定（ルーター側の ip tcp adjust-mss 等）を検討する。
フラグメンテーションは「ネットワークの基礎」ですが、その挙動を理解しているだけで、トラブルシューティングの時間は劇的に短縮されます。「なぜ動かないのか？」と悩む前に、パケットがどんな姿で運ばれているのか、想像力を働かせてみてください。
パケットは嘘をつきません。正しく設定してやれば、必ず期待通りのパフォーマンスを見せてくれるはずです。
コメント