パケットの「断頭」を回避せよ：Path MTU Discoveryの真実と現場の知見
データセンターのフロアで深夜3時にアラートが鳴り響くとき、その原因の8割は「見えない壁」に起因する。アプリケーションは正常に起動し、TCPの3ウェイ・ハンドシェイクも完了する。しかし、いざリクエストを投げると、何も返ってこないか、あるいは「謎のタイムアウト」で接続が断たれる。
この忌々しい事象の多くは、MTU（Maximum Transmission Unit）のミスマッチ、すなわちPath MTU Discovery (PMTUD) の失敗が引き金となっている。今日は、パケットにDF（Don’t Fragment）ビットを立ててネットワークの境界を探り、極限のパフォーマンスを追求する現場の技術について深掘りしよう。
—
なぜPMTUDが「死の罠」になるのか
TCPのハンドシェイクは小さなパケットで行われるため、通信開始時は何の問題も感じない。しかし、いざTLSのハンドシェイクや巨大なGETリクエストが始まると、パケットサイズが急増する。ここで途中のルータが「お前のパケットは大きすぎて通せない」と判断したとき、本来ならICMP Type 3 Code 4（Destination Unreachable, Fragmentation Needed）が返ってくるべきだ。
しかし、現代の堅牢なセキュリティポリシーの下では、セキュリティ上の理由からこのICMPを遮断しているケースが非常に多い。結果、送信側のOSはパケットがどこで捨てられたかを知る術を失い、ブラックホールと化したネットワーク上でパケットは虚空に消える。これが「接続はできるが通信できない」という悪夢の正体だ。
pingによる現物確認
まずは、現場で最も信頼できる「道具」である ping を使って、その経路の限界を見極める。-M do オプションはDFビットを強制的にセットし、断片化を禁止する。
# DFビットを立てて、ペイロードサイズ1472バイト（ヘッダー込みで1500バイト）でテスト
# Linux環境でのコマンド例
ping -M do -s 1472 192.168.1.1
# もし「Frag needed and DF set」が返ってきたら、パケットが大きすぎる証拠。
# サイズを徐々に下げて（例: 1464, 1450...）成功する地点を探すのが泥臭い現場の流儀だ。—
トランスポート層の最適化とチューニング
PMTUDの限界を知ることは、単なる障害回避ではない。TCPバッファチューニングやウィンドウ制御の前提条件だ。
TCP MSS クランプの戦略
クラウド間接続やVPNトンネリングを多用する現代のアーキテクチャでは、物理インターフェースが1500であっても、カプセル化（VXLANやIPsec）によって実質的なMTUは1400〜1450程度にまで削られる。このとき、ゲートウェイで mss-clamping を行うのが鉄則だ。
# iptablesを使用したMSSクランプの例（ルータ/ゲートウェイでの設定）
# TCPのハンドシェイク時にMSS値を書き換え、これ以上のサイズを送らせない
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360この 1360 という数値は、IPsecなどのオーバーヘッドを考慮した「安全圏」を狙ったものだ。
—
セキュリティとパフォーマンスのトレードオフ
TLS 1.3以降、ハンドシェイクの高速化は進んだが、証明書チェインの肥大化は依然として「最初の1パケット」を巨大化させる。MTU制限に抵触すると、TLSの暗号化されたハンドシェイクパケットがフラグメント（あるいは破棄）され、レイテンシが跳ね上がる。
極限のチューニング：TCPバッファとウィンドウサイズ
ネットワークの帯域を余すことなく使い切るためには、BDP（Bandwidth Delay Product）を意識したバッファ設定が不可欠だ。
# /etc/sysctl.conf でのTCPパラメータ調整
# 大規模なデータ転送を想定したバッファの拡大
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1しかし、いくらバッファを増やしても、MTUの不一致でパケットがロスすれば、TCPの輻輳制御アルゴリズム（CUBICやBBR）は即座に帯域を制限する。PMTUDを正しくハンドリングすることこそが、最速のネットワークを実現するための「最初の門」なのだ。
—
結論：パケットが見えるエンジニアになれ
教科書通りの設定を繰り返すだけであれば、それはオペレーターに過ぎない。真のエンジニアは、パケットがワイヤを通り、カーネルのバッファを抜け、NICのキューを経て、対向のルータでどう扱われるかを脳内でシミュレーションできる者だ。
MTUの問題は、現代のネットワークにおいて最も巧妙に隠された罠の一つである。もしあなたが「なぜかこの通信だけ遅い」「SSLハンドシェイクで止まる」という現象に遭遇したら、迷わず ping を手に取り、DFビットを立ててパケットの境界を探れ。
その先にこそ、最適化された高速な通信の世界が広がっている。さあ、次はどのパケットを追跡しようか。
コメント