VPNのMTUを小さくすると速くなる？実際の証拠を比較する
MTUを下げれば経路の制限を回避できる場合がありますが、それでもスループットを犠牲にします。変更を残す前に、実際の制約、ヘッダーのオーバーヘッド、ワークロードを比較してください。
トンネルは大きな転送を落とすのに ping は通すため、助言はすぐに届きます。MTU を下げる、というものです。その修正はときどき効きますが、やがてすべてのネットワークのすべてのプロファイルに適用されます。まさにそこで、的を絞った修理が恒久的な性能税に変わります。行うべき比較は、経路の本当の限界と、それを下回るようにパケットを小さくするコストの間の比較です。
MTU を下げると実際に何が小さくなるのか
すべてのパケットは、あなたのデータを運ぶ前にヘッダーを運びます。1500 バイトのイーサネット経路では、IPv4 と TCP が 40 バイトを消費し、ペイロードに 1460 を残します。カプセル化は外側の IP、UDP、トンネルのヘッダーをその上に加えるため、内側のペイロード予算はさらに減ります。インターフェースの MTU を下げることは、その予算を意図的に縮めることです。
コストはバイト数ではなく、パケット数に比例します。同じファイルをより多くのパケットに分割すると、経路上の各デバイスで、より多くの割り込み、より多くの経路判定、より多くのパケット単位の処理が必要になります。すでに毎秒パケット数の上限に近いルーターでは、それは丸め誤差ではなく実際の速度低下です。転送そのものが成功しても、コストは現れます。
だからこそ、小さい MTU は制約への回避策であり、一般的な最適化ではありません。大きいフレームを運べない経路に対して信頼性を買い、削減を必要としなかったパケットにまでオーバーヘッドを課します。
小さい MTU が正しい修正となるのはどんなときか
典型的な症状は具体的です。TCP のハンドシェイクが完了し、小さな応答は届くのに、大きなダウンロードが止まるかリセットされます。断片化禁止ビットを付けた 1472 バイトの ping は失敗し、1400 バイトの ping は成功します。これは、フルサイズのパケットを運べず、送信者に縮小を伝えるはずの ICMP メッセージを配送していない経路を示します。
経路 MTU の検出は、その ICMP の断片化要求メッセージに依存しています。ファイアウォールがそれを捨てると、送信者は大きなパケットを再試行し続け、接続は止まったように見えます。トンネル側で MTU を下げれば再試行を避けられ、それはそのネットワークにとって正当な修理です。
アクセス技術にも独自の限界があります。PPPoE は通常 1492 で頭打ちになり、モバイルや DSL の経路はもっと低く、入れ子のトンネルはオーバーヘッドを二重に引きます。ガイドの数値をコピーするのではなく実際の経路を測り、IPv6 が運ぶすべてのリンクで少なくとも 1280 バイトの MTU を要求することを忘れないでください。RFC 8200 が定めるとおりです。
一つを変える前に三つの制御を比較する
MTU、MSS、断片化は層の異なる別々の制御です。間違ったものを変えても症状はそのまま残ります。
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS の制限は多くの場合、最も侵襲の少ない修理です。TCP だけに作用し、インターフェースを他のトラフィックのために空けておけるからです。インターフェース MTU を下げる方法は範囲が広く考えやすいため家庭用ルーターでよく使われますが、一つのプロトコルの問題をすべてのプロトコルに課します。
断片化禁止の動作を無効にすると、断片化を許すことで症状を隠します。しかも、正しいサイズを見つけたはずのフィードバックを壊しながら、遅延を悪化させがちです。恒久的な修正としては避けてください。
一つの数値ではなくトレードオフを測る
断片化禁止のプローブで経路の限界を見つけます。高い値から始めて、応答が返るまで下げていきます。
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10次に、両方の設定で実際の作業を比較します。同じファイル転送、同じエンドポイント、同じネットワークです。完了時間と再送を記録し、たとえば nstat -az TcpRetransSegs を使い、トンネルが小さなルーターで終わるならデバイスの CPU も見ます。短い合成スループット試験では、数メガバイト後にしか現れない停止を見逃すことがあります。
削減後はパケットのカウンターが増えます。同じ転送がより多くのパケットを使うようになるからです。それは想定内で、より高いスループットの証拠ではありません。完了したアプリケーションデータ、再送回数、応答性を比較してください。パケットレートだけを見てはいけません。
変更は段階的に導入し、範囲を限定する
元の値を記録し、一つの制御を変え、恒久化する前に測定を繰り返します。証拠が利益を示さないなら、設定に使ったのと同じインターフェースコマンドで以前の値に戻します。
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500結果はそれを必要としたネットワークに限定します。ホテルの Wi-Fi、モバイル hotspot、オフィスの LAN で動く必要があるプロファイルは、クライアントが経路を検出できない場合を除き、どれか一つが要求する最も低い値を継承すべきではありません。
正しい値は経路を生き延びる最大の MTU であり、症状を消す最小の値ではありません。経路、プローブの結果、切り戻しを記録し、アクセスネットワークが変わったら設定を見直してください。