ジャンボフレームの甘い罠：MTU不一致が引き起こす「パケットの断末魔」と最適化の深淵
ネットワークエンジニアとして現場に長く身を置いていると、「なぜか特定の通信だけが異様に遅い」「小さなパケットは通るのに、大きなファイル転送で必ずコネクションが切れる」という相談を幾度となく受ける。
その犯人の多くは、MTU（Maximum Transmission Unit）の不一致だ。特に、ストレージネットワークやバックボーンの高速化を狙って「ジャンボフレーム（9000 bytes）」を有効にした途端、環境全体が「見えない地雷」の巣窟と化すケースは後を絶たない。
今回は、パケットの断片化（フラグメンテーション）が引き起こす性能劣化のメカニズムを解剖し、現代の高速ネットワークにおける「あるべき姿」を語ろう。
1. 断片化という名の「死の行軍」
MTUが1500 bytesのリンクに、9000 bytesのジャンボフレームが飛び込んできたとき、ルーターは何をするか？ 答えは「IPフラグメンテーション」だ。
RFC 791で定義されたIPフラグメンテーションは、一見便利に見えるが、現代のインフラでは「性能殺し」以外の何物でもない。
- CPU負荷の増大: ルーターがパケットを分割する際、ヘッダーの複製や
Fragment Offsetの計算など、メモリとCPUの演算コストが跳ね上がる。 - パケットロス時の連鎖反応: 分割された断片（Fragment）のうち、たった一つがドロップしただけで、再送時には元の大きなパケット全体を再送せざるを得ない。これがTCPの再送タイマーを刺激し、スループットを劇的に低下させる。
- セキュリティの脆弱性: 悪意ある攻撃者が意図的にオーバーラップするフラグメントを送りつける「Teardrop攻撃」のように、再構築処理を悪用したIDS/IPSの回避やカーネルパニック誘発のリスクを抱えることになる。
2. Path MTU Discovery (PMTUD) の落とし穴
「それなら PMTUD が自動調整してくれるだろう？」という甘い考えは捨てた方がいい。PMTUDは、ICMP Destination Unreachable (Type 3, Code 4: Fragmentation Needed) に依存している。
しかし、セキュリティ対策としてICMPを全遮断しているネットワークは非常に多い。これがいわゆる「Black Hole Router」問題だ。TCPハンドシェイクは小さなパケットで行われるため成功するが、いざデータ転送を開始するとパケットが破棄され、コネクションがタイムアウトする。これが「通信が途中で止まる」現象の正体だ。
3. 現場で使える「TCPバッファとMSSの最適化」
MTU問題を根本から解決するには、エンドツーエンドのMTU統一が鉄則だが、どうしても統一できない環境では、MSS Clampingが生命線となる。
ルーター側でTCPのSYNパケットを監視し、その中のMSS (Maximum Segment Size)オプションを書き換える手法だ。
CiscoルーターでのMSS Clamping設定例
! インターフェースのMTUに合わせてMSSを調整する
interface GigabitEthernet0/1
ip mtu 1500
ip tcp adjust-mss 1460 ! 1500 - 20(IPヘッダー) - 20(TCPヘッダー)また、Linuxサーバー側でTCPウィンドウサイズやMTUを適切に制御することも重要だ。sysctlでのチューニング例を挙げる。
Linuxカーネルのチューニング例
# /etc/sysctl.conf に追記して反映
# TCPバッファの自動調整範囲を拡大
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# MTU変更（物理NIC設定）
# ip link set dev eth0 mtu 9000
# ただし、MTUはネットワーク機器と完全に一致させること！4. TLSハンドシェイクとRTTの削減
現代のHTTPS通信では、TLSのハンドシェイク中に証明書チェーンが送受信される。これがMTUを超えるとフラグメンテーションが発生し、RTT（Round Trip Time）が余計にかかる。
特にモバイルネットワークなどの不安定な回線では、この数ミリ秒の遅延が体感速度に直結する。
- TLS 1.3の採用: ハンドシェイクの往復回数が削減されているため、MTU問題による再送の影響を相対的に受けにくい。
- TCP Fast Open (TFO): 最初のSYNパケットでデータを送るTFOは、MTU不一致が起きると目も当てられない結果になる。TFOを有効にする際は、パス上の全機器のMTUが保証されていることが前提だ。
結論：ネットワークを「透明」にするために
ジャンボフレームは魅力的だが、端から端まで「正しく」設定されて初めて真価を発揮する。途中に一つでも「MTU 1500」の非力なスイッチが存在すれば、ネットワーク全体はフラグメンテーションの泥沼に足を取られる。
アーキテクトとしてのアドバイスはこうだ。
1. 可能な限り全パスのMTUを統一せよ。 できないならジャンボフレームを導入するな。
2. MSS Clampingを最後の一手として用意せよ。
3. パス上のMTUを確認する際は、pingのフラグメント禁止オプションを活用せよ。
# Linuxでのパケットサイズ確認（1472 + IP/ICMPヘッダー28 = 1500）
ping -M do -s 1472 192.168.1.1ネットワークは、正直だ。設定の甘さは必ず性能の劣化という形でフィードバックされる。パケットが物理層を突き抜け、カーネルのバッファを駆け抜けるその一瞬一瞬をイメージし、無駄のない設計を心がけてほしい。それが、プロトコルを愛する我々の責務なのだから。
コメント