web-dev-qa-db-ja.com

MTUサイズの「標準」または「事実上の」デフォルトのようなものはありますか？

  1. ネットワークソフトウェアを作成する場合、MTUサイズのデフォルト、標準、またはデファクトスタンダードがありますか？もしそうなら、それは何ですか？

  2. 1500のMTUサイズ（ここで提案されているように： DSL標準でサポートされている最大MTUはいくつですか ）は大まかな目安ですか？

  3. また、私はこの問題を考えすぎていますか？これは、ネットワークソフトウェアを作成するときに人々が考える重要なことの1つですか？しかし、実際には、TCPはあなたのために詳細を世話しますか？

StackOverflowではなく、ここで質問します。MTUサイズに関連する実際のサポートの問題に関しては、sysadminの視点が欲しいからです。

UPDATE：いくつかのフィードバックと最初の回答に基づいて、焦点を少し狭めています：

  • 私が書いているアプリケーションは、WAN接続を介してデスクトップ/サーバー間で通信します
  • これは典型的なデスクトップ/サーバー（つまりモバイルではない）ソフトウェアであり、テザードラップトップがモバイルネットワーク経由でこのソフトウェアを使用する可能性はありますが、私はそれを心配していません
  • 最適化のために、アプリケーション層以外のTCP=スタックのどの層も処理しようとはしません
  • この質問の範囲では、VPNのオーバーヘッドを除外できます
networkingmtu
6
jefflunt

ネットワークスタックが必要な最適化を処理するため、MTUについては気にする必要はありません。 TCPを使用している場合、スタックは最大セグメントサイズ（MSS）の計算方法を使用する場合があります。これにより、理想的には、パス内の最小MTUよりも小さいパケットが生成されます。それらの1つは PMTUディスカバリー です。

一般に、スタックの裏をかくことを試みるべきではありません-TCP/IPの階層化アーキテクチャは、正当な理由で抽象化を採用しています。より良いものがない限り、セグメンテーションとフラグメンテーションの機能は設計された場所に残しておく必要があります。

他の人が書いているように、IPパケットの最小定義MTU以外に想定する「安全なMTU」はありません 68バイト したがって、膨大なオーバーヘッドのために実用的な値はかなり低くなります。

MTUの制限による一般的なサポートの問題は、主に2つあります。

  • 不必要な断片化、したがってピンポンプロトコルのプロトコルオーバーヘッドと待ち時間の増加
  • 無知なファイアウォール管理者がICMPをフィルタリングし、パスに沿ったPMTU検出を破壊することにより、送信が破壊される

どちらの要素も、アプリケーションで扱うべきものではありません。

4
the-wabbit

それはかなり広い質問です。

1500は一般的ですか？はい、絶対に、LAN上の従来のイーサネットの場合です。

1500と仮定しても、どの接続でもそれを期待しても安全ですか？いいえ。どこからでも接続するモバイルユーザーは、異なる時間に異なるMTUを使用する場合があります。

VPN接続を介してリモートオフィスにサービスを提供する可能性のあるデータセンターサーバーのMTUを削減することがあります。

一般に、VPN接続ではMTUが低下する可能性が高く、それらはいたるところにあります。 1410、1390、1362、またはその他の奇妙な数である可能性があります。

特定のtcp接続の最大ペイロードサイズに関心がある場合は、ネゴシエートされた最大セグメントサイズの方が意味があると思われます。標準の1500 MTU LAN接続の場合、通常は1460ですが、両方のホストが許容できるサイズを反映する必要があります。

多くのホップを通過する接続の場合、すべてのホップに「標準」MTUがあること、またはMTUを確実に決定できることを期待するのは非現実的です。このトピックに関するPathMTUDiscoveryの説明を参照してください。

パスMTUディスカバリー
http://en.wikipedia.org/wiki/Path_MTU_discovery#Problems_with_PMTUD

MSSクランプによるパスMTU検出の問題の回避
http://lartc.org/howto/lartc.cookbook.mtu-mss.html

7
Greg Askew

に答えて：

  1. ネットワークに触れるとソフトウェアのパフォーマンスに影響を与えるものの概要が常にあるため、これに答えることは困難です。スイッチポートからスイッチポートへの通信用に最適化されたMTUは、WANリンク、またはさらに悪いことに、オーバーヘッドと潜在的な断片化を追加するVPNではあまり効果がありません。
  2. はい、しかし、すべての状況でアップストリームを実際に制御することはできません！
  3. はい、あなたはそれを考えすぎています、あなたは本当に最適化のためにレイヤー2に戻るソフトウェアを書いていますか？もしあなたが言うなら... iSCSIドライバーならそうですあなたはおそらくこのようなことを考慮する必要があるでしょう。
4
SpacemanSpiff

プロトコルの要件に固執し、データを簡単に渡すことができると想定します。ただし、MTUのすぐ上またはその倍数の固定長ブロックの使用は避けてください。

  1. デフォルトのMTUは1500で、これはインターネットで使用可能な最大値です。トラフィックをトンネリングする場合は、より小さな値が必要になる場合があります。ほとんどのトラフィックは断片化されて再構成され、リンクで利用可能な最大MTUを超えます。 DNF（Do Not Fragment）オプションが設定されている場合にのみ、パケットはMTU以下である必要があります。ローカルMTUは、使用可能なMTUの上限を設定します。
  2. ほとんどのホストのMTUは1500であるため、これを使用するのが適切なデフォルト値です。一部のISPは、より小さなMTUを提供するPPPOEなどのトンネリングプロトコルを使用してリンクを提供します。同様に、多くのIPv6アーリーアダプターはトンネルを使用している可能性があり、MTUが小さい可能性があります。
  3. あなたはおそらく問題を考え過ぎているでしょう。現実の世界では、リンクのMTUを決定するためにローカルMTUに依存することはできません。また、それが静的な値であることを期待することもできません。必要な場合、パケットは断片化され、再構成されます。たとえば、NFSのブロックサイズは通常4096で、通常はフラグメントで送信されます。
2
BillThor