MTU / MRUの問題とは正確には何ですか、それは何によって引き起こされ、どのように修正しますか？
ハングしている、フリーズしている、遅い、応答しないインターネット接続の場合、iptablesまたはifconfig、その他の「クランプMTUからTSS」スペル。
私が知りたいのは、MTU/MRUの問題とは何か、それが接続速度と待ち時間に影響を与える理由、および問題の解決策を知識のある方法で解決したいため、解決方法（既知の最新の方法）です。魔法ではありません。
これは少し複雑な質問なので、基本から始めます。これをすべて知っていたら許してください。
MTUは最大転送単位であり、コンピュータインターフェイスが送信するデータの最大パケットです。イーサネットの場合、デフォルトは1500バイトです。イーサネットフレームは通常、最大1522-1542まで許可され（カウント対象によって異なります）、余分なスペースはヘッダー情報用に「予約」されます。
さまざまな接続で機能が異なる場合があります。 1500をわずかに下回るMTUを持つインターネット上のリンクを介して実行することはかなり一般的です。これは通常、リンクが追加のヘッダー情報を使用するか、「標準」イーサネット以外のメディアを使用しているためです（ほとんどのインターネットは実際に実行されます） ATM/SoNet接続）。通常、このようなリンクに遭遇したトラフィックは、単純に複数に分割されて送信されます。
これは一般的であり、IPが発明された当時のことなので、ICMPプロトコルの責任の一部は、MTUとの問題を通信することでした。何らかの理由でパケットを破損して転送できなかった場合は、ICMPを使用して問題を送信元のコンピューターに通知します。送信側のコンピュータは適切なアクションを実行し、情報を小さなチャンクに分割し、誰もが満足しています。このプロセス全体は、裏で処理されます。 適切に機能しているネットワークMTU設定を変更する必要はありません。
最後の文の修飾子はキッカーです。自動化プロセスが失敗する一般的な理由は3つあります。
- 実装の失敗-ある時点で、ソフトウェアが単純に機能しない。人々がインターネットの関連規格に従う必要があると言う法律はなく、通常は安くするために、規格を破る企業があります。
- 管理上無効な実装-善意のある人々は、実際に何をしているのか知らないためにソフトウェアを破壊することがあります。私は、ICMPがICMP.0.0パケットにのみ使用されると考えているため、人々がICMPをブロックするのを見てきました（エコー、ほとんどの人は
pingユーティリティでこれを知っています）。 - この「通常の」プロセスから完全に外れた他の理由。ほとんどの場合、これは接続が非常に損失が大きいため、短いパケットのみが確実に接続を通過することを意味します（または大量の再試行なしで）。初期のDSLおよびCableModemsには、このような問題がありました。その前に、非常に低品質の電話回線とアグレッシブなラインコーディングを使用すると、ダイヤルアップには通常このような問題がありました。
それで、なぜ一般的であるか：怠惰な技術者/会社。上記で概説した問題の1つを修正するよりも、小さなMTUとの接続をハンディキャップする方が、ほぼ普遍的に「簡単」です。上で述べたように、最近誰もがMTUをいじる必要はないはずです（ジャンボフレームを有効にすることを考えることができる1つの例外ですが、それについてはここでは説明しません）。いずれの場合も正しい解決策は、根本的な問題を解明して修正することです。症状ではなく病気を治療する古典的なケース。
MTUは接続にどのように影響しますか？データを細かく分割すると、特に信頼性の低い接続全体で、各部分が宛先に到達する可能性が高くなります。ただし、断片が小さいため、送信されるデータごとのオーバーヘッドが大きくなります。つまり、有効な接続速度が低下します。 MTUが本当に小さい場合は実質的に。ヘッダーとフラグメンテーション/再構成プロセスの余分な処理とオーバーヘッドのため、レイテンシは影響を受ける可能性がありますが、それはマイナーであると予想されます。
pdate：---clamp-mss-to-pmtuについて
個人的には、MTUについていじったことがありません。私は少し完璧主義者であることを認めます。このような醜いハックが提示されたとき、私は常に問題の根本を見つけ、それを修正することができました。そのため、iptablesオプション--clamp-mss-to-pmtuは私には不慣れです。どうやら、このハックを使用することは非常に一般的であり、ほとんどの場合非常に不当である可能性があります。それでも、上記の問題の1つを補うためのハックです。 Linuxのマンページでiptables（8）を引用します。
このターゲットは、「ICMP Fragmentation Needed」または「ICMPv6 Packet Too Big」パケットをブロックする犯罪的に頭の悪いISPまたはサーバーを克服するために使用されます。
マンページの比較的苛酷な言語は、RFCを順守しない（そして試みたり、補償したりしない）ISPやネットワークによってどれほどの侮辱がもたらされるかを示しているはずです。
VPNでのUDPの使用と言えば、これは、VPNのオーバーヘッドを最小限に抑え、既存のエンドポイントがセッション情報を管理できるようにするために最も一般的に使用されていました。 VPNがセッションの処理方法を知る方法はないので、そのタスクは本当に知っているアプリケーションに任せるのが最善です。
最新のVPNトンネリングプロトコルの多くは、GREやL2TPなどの低レベル（オーバーヘッドはさらに少ない）で構築されています。またはSSTPやSSHなど、より高いレベルでトンネルされる（通常、制限的なファイアウォールとの互換性やその他の理由により）。これらは、トランスポートメカニズムとしてUDPを徐々に置き換えます。
アップデート2：-MTU/ICMP問題の診断
それで、MTU/ICMPの問題があり、確認したいと考えています。このプロセスには2つの基本的な手順があります。指示はLinuxまたはBSDボックス用ですが、ほぼすべてのOSに適応できます。
- ICMP Pingターゲット（Google.com、Yahoo.com、Facebook.comなど）を選択します。次のコマンドでpingを実行してみてください：
ping -c 2 -s 1472 -D google.com。- これは成功するはずです。成功しない場合は、「パケットをフラグメント化する必要があります」を返します。これらのいずれかに該当する場合は、接続を停止してください。接続は正常に機能します。
- これが何も返さない場合、または「タイムアウト」メッセージが表示される場合は、問題があります。
- 切断された接続の場合のみ：
traceroute -F google.com 1472を実行します。これにより、壊れているホップがわかります。注：CPEがtraceroute要求に応答しないのはよくあることなので、最初のホップが応答しなくても心配しないでください。- 応答する最後のホップがどちらかが、正しく機能している最後のホップです。
- それらのいずれも応答しない場合は、CPEまたはDSL回線です（少し注意が必要かもしれませんが、最新の場合はほとんどCPEではありません）。注：接続が正常に機能する場合、tracerouteは正常に完了します。
余談ですが、ISPが最近使用しているものはPPTP？です！？これは時代遅れで役に立たない過去からの爆風です。少なくともPPPoEを使用しているはずですが、MACとセグメントでモデムを承認するだけで十分です。はるかに簡単になります（ISPと顧客の両方にとって簡単です）。