ジャンボフレーム（MTUは最大9k）は、オープンインターネット上で現実的/一般的ですか
より大きなイーサネットフレームの恩恵を受けるアプリケーションがあります。 （理論的には、送信パケットの数を> 50％、おそらく66％まで減らすことができます。）
また、アプリケーションサーバーの新規インストールのために、ホスティング会社候補とのネットワーク要件を指定する作業を行っています。少なくとも、クライアント接続がジャンボフレームの恩恵を受けることを制限しないのは良いことです。
しかし、これはどれほど現実的ですか？制御できるネットワークのセグメントがジャンボフレームに対応していると仮定した場合の一般的な質問（スイッチは大きなMTUに対応している、ICMP MTUパスの検出が許可されているなど）：
- 公共のインターネットを介してジャンボフレームを送信することは現実的ですか？
- 公共のインターネットを介してジャンボフレームをサポートしようとすると、エンドレスネットワーキングの問題が発生しますか？
- 私が考慮していない他の懸念事項はありますか？
ここで重要なのは、ネットワークの小さなセグメントを制御して大きなMTUを有効にできるが、パケットがインターネットを通過するパスを制御できず、パケットが通過するルーターの構成を制御できないことです。ほとんどのインターネットルーターは1500を超えるように構成されていないため、このソリューションではあまり運がありません。さらに悪いことに、ジャンボフレームをサポートしていないルーターが実際に大きなパケットをドロップすることもあるので、ジャンボフレームをインターネットに送信しようとすると、状況がさらに悪化すると思います。
ジャンボフレームは、内部ネットワーク、特にストリーミングまたはiSCSIを実行するネットワークに最適です。
- あなたのインターネットに対する見方が、この問題について非常に具体的に説明できる単一のエンティティを介してあなたからのものであり、次に同等に制御可能なエンドポイントに到達しない限り、99.9％以上の確率でトラフィックが「そのまま」転送されることはありません。 JFを維持します。その理由は、JFがethernet仕様であり、すべてのインターネットがイーサネットではないため、分解、再構成、転送、再パケット化されるためです。
- 問題-おそらくそうではありません。おそらく1日目に問題が1つまたは2つ発生する可能性がありますが、問題が解決して問題なく動作するはずです。
- 私はあなたがサーバーからクライアントへのチェーンのすべての部分を完全に制御できない限り、私はシステムを設計して、最低ではなく最高の一般的な分母を考慮して、つまりそれを機能させるように誘惑しますthen逆ではありません。
多くの高等教育ネットワーク（AARNET、JANET、Internet2）は、ネットワーク上でエンドツーエンドの有効なジャンボフレームを備えています。あなたがそれらのネットワークで人々にサービスを提供しているなら、私はそれが価値があることを提案します。
他の人が上で言ったように、答えは現在ノーです。
プロバイダーのアップリンクのMTUも考慮してください。ジャンボフレームがサポートされていない場合は、開始する前に運が悪かったことになります。
私の経験では、ジャンボフレームは通常、アプリケーションサーバーとそのデータベースサーバーの間の専用リンクに制限されています。より複雑なタイプの非互換性の可能性のタイプの数は、驚異的です。