ジャンボフレーム（9kまでのMTU）は、オープンインターネット上で現実的/一般的ですか？

より大きなイーサネットフレームの恩恵を受けるアプリケーションがあります。（理論的には、発信パケットの数を50％以上、おそらく66％減らすことができます。）

また、アプリケーションサーバーの新規インストールのために、ホスティング会社候補とのネットワーク要件を指定している最中です。少なくとも、クライアント接続がジャンボフレームの恩恵を受けることを制限しないのが良いでしょう。

しかし、これはどれほど現実的ですか？制御できるネットワークのセグメントがジャンボフレームに適していると仮定した場合の一般的な質問（スイッチは大規模なMTUに対応、ICMP MTUパス検出など）：

• ジャンボフレームをパブリックインターネット経由で送信するのは現実的ですか？
• 公共のインターネットを介してジャンボフレームをサポートしようとして、無限のネットワーク問題を招いていますか？
• 私が考慮していない他の懸念はありますか？

ここで重要なのは、ネットワークの小さなセグメントを制御し、大きなMTUを有効にできることですが、パケットがインターネットを経由するパスを制御することはできず、パケットが通過するルーターの構成を確実に制御することはできません。ほとんどのインターネットルーターは1500を超えるように構成されていないため、このソリューションではあまり運がありません。さらに悪いことに、ジャンボフレームをサポートしていないルーターによって実際には大きなパケットがドロップされる場合があるため、ジャンボフレームをインターネットに送信しようとすると、実際に事態が悪化することがあります。

ジャンボフレームは、内部ネットワーク、特にストリーミングまたはiSCSIを行うネットワークに最適です。

1. インターネットに関するあなたの見解が、この問題について非常に具体的になることを可能にする単一のエンティティを介して、そして次に等しく制御可能なエンドポイントに到達しない限り、トラフィックが「完全」に通過しない可能性は99.9％を超えますJFを維持します。理由は、JFはイーサネット仕様であり、インターネットのすべてがイーサネットではないため、分解、再構築、通過、再パケット化されるためです。
2. 問題-おそらくそうではないかもしれませんが、1日目には1つまたは2つの問題が発生する可能性がありますが、一度問題が発生して正常に動作するはずです。
3. 私は、ない最高の、共通分母、サーバーからクライアントへのチェーンのすべての部分を完全に制御を持っていない限り、私は最低を考慮し、私のシステムを設計するために誘惑されるだろうと言うでしょうすなわち、それは作業を取得、その後の曲ではなく、他の方法の周り。

他の人が上記したように、答えは現在ノーです。

また、ジャンボフレームをサポートしていない限り、プロバイダーアップリンクのMTUを考慮してください。そうしないと、開始する前に運が悪くなります。

多くの高等教育ネットワーク（AARNET、JANET、Internet2）は、ネットワーク上でエンドツーエンドのジャンボフレームを有効にしています。それらのネットワークで人々にサービスを提供しているなら、私はそれが価値があることを提案します。

私の経験では、ジャンボフレームは通常、アプリケーションサーバーとそのデータベースサーバー間の専用リンクに制限されています。より複雑なものに対する非互換性の可能性の種類の数は、気が遠くなるほどで​​す。