MTU / MRUの問題とは何ですか、その原因と修正方法は何ですか？

ハングの例では、ゆっくりと、応答しないインターネット接続凍結原因は通常、不当にいくつか急いで提案関わるコマンドなどの「魔法の治療法」（状況のため、通常は無効または適用できない）と「MTU / MRUの問題」として識別されるiptablesかifconfig、およびその他の" MTUをTSSに固定する」スペル。

私が知りたいのは、MTU / MRUの問題が正確に何であるか、それが接続速度と遅延に影響する理由、および問題の解決方法（既知および最新の方法）です。私は問題の解決に知識を持ってアプローチしたいので、魔法ではありません。

これは少し複雑な質問なので、基本から始めましょう。これらすべてをすでに知っているなら許してください。

MTUは、コンピューターインターフェイスが送信するデータの最大パケットである最大転送単位です。イーサネットの場合、デフォルトは1500バイトです。イーサネットフレームは通常、最大1522〜1542（カウントする内容によって異なります）まで許可されており、ヘッダー情報用に追加のスペースが「予約」されています。

さまざまな接続が異なる機能を持つ場合があります。1500をわずかに下回るMTUを持つインターネット上のリンクを介して実行することは非常に一般的です。これは通常、追加のヘッダー情報を使用するリンクまたは「標準」イーサネット以外のメディアを使用するためです（インターネットのほとんどは実際に実行されますATM / SoNet接続）。通常、このようなリンクに遭遇したトラフィックは、単に複数の部分に分割されて送信されます。

これは一般的であり、IPが発明された当時であったため、ICMPプロトコルの責任の一部は、MTUとの問題を通信することでした。何らかの理由でパケットを破壊して転送できなかった場合、ICMPを使用して送信側コンピューターに問題を通知します。送信側のコンピューターは適切なアクションを実行し、情報を小さなチャンクに分割し、誰もが満足しています。このプロセス全体がバックグラウンドで処理されます。では正常に機能してネットワーク には、MTUの設定でマックする必要になることはありません。

その最後の文の修飾子はキッカーです。自動化プロセスが故障する一般的な理由は3つあります。

1. 実装の破損-ある時点でのソフトウェアは、正常に機能しません。インターネットの関連する標準に従う必要があるという法律はありません。標準を破る企業があります。通常は安くなります。
2. 管理上無効な実装-善意を持った人々は実際に何をしているのか知らないためにソフトウェアを壊すことがあります。個人的にはICMPがICMP.0.0パケットにのみ使用されると考えているため、人々がICMPをブロックしているのを見てきました（エコー、ほとんどの人はpingユーティリティでこれを知っています）。
3. この「通常の」プロセスから完全に外れた他の理由。ほとんどの場合、これは接続の損失が大きいため、短いパケットのみが確実に接続を通過することを意味します（または、大量の再試行なしで）。初期のDSLおよびCableModemsには、このような問題がありました。それ以前は、非常に低品質の電話回線と積極的な回線コーディングを使用する場合、ダイヤルアップでは一般にこのような問題が発生していました。

だから、なぜ一般的です：怠け者の技術者/会社。上記で説明した問題の1つを修正するよりも、小さなMTUとの接続をハンディキャップする方が、ほぼ普遍的に「簡単」です。前述のように、誰もが最近MTUを台無しにする必要はありません（ジャンボフレームを有効にすることを考えることができる1つの例外が、実際にここで議論していることではありません）。いずれにせよ、正しい治療法は根本的な問題を見つけ出し、それを修正することです。症状ではなく病気を治療する古典的なケース。

MTUは接続にどのように影響しますか？データを小さな断片に切り刻むことは、特に非常に信頼性の低い接続で、各断片が宛先に到達する可能性が高くなることを意味します。ただし、小さい部分であるため、送信されるデータあたりのオーバーヘッドが大きくなります。これは、有効な接続速度が低下することを意味します。実質的に、MTUが本当に小さい場合。レイテンシーは影響を受ける可能性がありますが、ヘッダーとフラグメンテーション/リアセンブリプロセスの余分な処理とオーバーヘッドのため、マイナーであると予想されます。

更新： - --clamp-mss-to-pmtu
個人的には、MTUをいじったことはありません。私は少し完璧主義者であり、このようないハックを提示されたとき、私は常に問題の根本を見つけ、それを修正することができました。そのため、このiptablesオプション--clamp-mss-to-pmtuは私には馴染みがありません。どうやら、このハックを使用することは非常に一般的であり、ほとんどの状況で非常に不当であると思われます。上記の問題の1つを補うことは依然としてハックです。iptables（8）のLinuxマンページから引用します。

このターゲットは、「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に適応できます。

1. ICMP Pingターゲット（Google.com、Yahoo.com、Facebook.comなど）を選択します。次のコマンドでpingを実行してくださいping -c 2 -s 1472 -D google.com。
   • これは成功するはずです。成功しない場合は、「パケットの断片化が必要」を返します。これらのいずれかが当てはまる場合は、停止してください。接続は正常に機能します。
   • これが何も返さない場合、または「タイムアウト」メッセージが表示される場合は、問題があります。
2. 接続が切断された場合のみ：を実行しtraceroute -F google.com 1472ます。これにより、どのホップが壊れているかがわかります。注：CPEがtraceroute要求に応答しないことは非常に一般的であるため、最初のホップが応答しない場合でも心配しないでください。
   • 応答する最後のホップは、最後に正しく動作しているものです。
   • それらのいずれも応答しない場合、それはあなたのCPEまたはDSLラインです（少しトリッキーになる可能性がありますが、それが近代的であればほとんどCPEではありません）。注：接続が正常に機能する場合、tracerouteは正常に完了します。

補足：最近、どのISPがPPTPを使用していますか？！それは時代遅れで役に立たない過去からの爆発です。少なくともPPPoEを使用する必要があります。しかし、単にMACとセグメントによってモデムを承認する方がはるかに簡単です（ISPと顧客の両方にとって簡単です）。