パケットの「分断」を制する者は通信を制す：MTU/MSS最適化の深淵
ネットワークエンジニアとして現場を渡り歩いていると、往々にして「なぜか特定のサイトだけ表示が遅い」「TLSハンドシェイクの途中で接続がリセットされる」といった不可解な現象に遭遇する。ログを追い、パケットキャプチャを広げてみると、そこには決まって「フラグメンテーションの亡霊」が潜んでいる。
家庭用ルーターのMTU設定を「なんとなく1500で放置している」のであれば、君のネットワークは、現代の複雑なトンネリングプロトコルやカプセル化技術が支配する広域ネットワークにおいて、すでに最適化の恩恵を半分捨てているに等しい。
今日は、パケットレベルの挙動から、TCPスタックのチューニング、そしてセキュリティの要であるTLSハンドシェイクを極限まで加速させるための「MTU/MSS最適化」の真髄を紐解いていこう。
—
1. なぜ「1500」が罠になるのか：パケット断片化の物理学的現実
イーサネットの標準MTUは1500バイトだ。しかし、PPPoEやIPsec、あるいはVXLANのようなカプセル化技術を用いると、ヘッダー分だけペイロードの容量が削られる。
パケットが経路上のどこかで「送信可能な最大サイズ」を超えた瞬間、ルーターはそれをフラグメント（断片化）するか、あるいは DF (Don't Fragment) フラグが立っていればパケットを破棄し、ICMP Destination Unreachable (Fragmentation Needed) を返す。
この「ICMPの消失」こそが、いわゆるPMTUD (Path MTU Discovery) Black Hole問題の正体だ。パケットがブラックホールに飲み込まれ、TCPのシーケンス番号が永遠に同期できない。この状況下では、どんなに高性能なWi-Fi 7ルーターを導入しても、通信効率は泥沼化する。
—
2. MSSクランプによる「先回り」の最適化
解決策はシンプルだ。SYNパケットの段階で、相手に対して「これ以上のサイズは送るな」と強制的に通知する。これが MSS (Maximum Segment Size) Clamping である。
Linuxカーネルレベル、あるいはルーターのiptables/nftablesでこの制御を行うのが、インフラアーキテクトとしての定石だ。
実装例：iptablesによるMSSクランプ
多くのホームルーターやLinuxゲートウェイでは、PPPoEなどのオーバーヘッドを考慮し、以下のようにMSSを調整する。
# TCP SYNパケットを捕まえ、MSS値を1412に強制書き換えする（PPPoE環境の典型例）
# 1500(MTU) - 20(IP) - 20(TCP) - 8(PPPoE/その他オーバーヘッド) = 1452だが、
# 安全を見て1412〜1440程度に設定するのが運用上の勘所
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1412この設定を行うだけで、TLSの巨大なServer Helloや証明書チェーンがパケットロスすることなく、スムーズに流れるようになる。
—
3. トランスポート層の深化：TCPバッファとRTTの相関
MTUを最適化しても、TCPのウィンドウスケーリングが適切でなければ、現代の高速な光回線（10Gbps環境など）の帯域を使い切ることはできない。
高RTT（遅延）環境下では、tcp_rmem と tcp_wmem のチューニングが必須だ。特に、クライアント側のTCPスタックが小さいバッファで飽和していると、帯域に空きがあってもスループットは向上しない。
カーネルパラメーターの最適化例 (/etc/sysctl.conf)
# ネットワークの輻輳制御アルゴリズムをBBRに変更（Googleが開発した現代の最適解）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# TCP受信バッファの最小値、デフォルト値、最大値の調整
# 16MBまでバッファを確保させ、広帯域でのパイプライン化を促進
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# ウィンドウスケーリングを有効化（必須）
net.ipv4.tcp_window_scaling = 1BBR (Bottleneck Bandwidth and Round-trip propagation time) は、パケットロスを「輻輳」と誤認せず、帯域幅と遅延から通信速度を推測する。MTU最適化と併用することで、パケットのロス率を最小限に抑えつつ、物理回線の理論値に迫るスループットを引き出すことが可能だ。
—
4. セキュリティとパフォーマンスのトレードオフ：TLS 1.3の文脈
MTUが適切でないと、TLS 1.3のハンドシェイクにおいて致命的な遅延が発生する。特に証明書チェーンが長い場合、複数のパケットに分割されたデータが断片化・再送されるコストは、暗号化そのものの計算コストよりも遥かに大きい。
- TLS Record Sizeの最適化: 多くのモダンなWebサーバーは
Record Sizeを適宜調整しているが、インフラ側でMTUを制御することで、TLSの1レコードを1パケット（1 MTU）に収める設計が可能になる。 - Zero Round Trip Time (0-RTT): セキュリティリスクはあるものの、再接続時のハンドシェイクを省くこの機能は、MTUが最適化されていれば爆速で動作する。
まとめ：泥臭いパケット解析こそが最強の武器
最新のWi-Fi 7やマルチギガビットイーサネットといった華やかなスペックの裏側で、結局のところ通信品質を決定づけているのは、OSのカーネルパラメーターや、ルーターのiptablesに刻み込まれた一行のルールである。
「パケットがどこで、なぜ断片化されているのか？」という問いを常に持ち、バイナリレベルで挙動を追う。この泥臭い探求心こそが、真の意味で「高速で堅牢な家庭内インフラ」を構築するための唯一の道だ。
次にネットワークの遅延を感じたら、まずは ping -f -l 1472 （Windowsの場合）や ping -D -s 1472 （Linuxの場合）で、DFフラグを立てたまま経路上の最大値を叩いてみることから始めてほしい。数値がすべてを語ってくれるはずだ。
コメント