巨型帧(MTU高达9k)在开放的互联网上是否现实/通用?

我有一个应用程序,将受益于更大的以太网帧。 (理论上,我们可以将出站数据包的数量减less50%以上,甚至可以减less66%。)

我还正在为候选托pipe公司指定networking要求,以便安装我的应用程序服务器。 至less不会限制客户端连接受益于巨帧。

但这有多现实? 一些常见的问题,假设我们可以控制的networking段是Jumbo Frame友好的(交换机是大MTU能力,允许ICMP MTUpath发现等)

  • 通过公共互联网发送巨型帧是否现实?
  • 它是否引发了无休止的networking问题,试图通过公共互联网支持巨帧?
  • 还有没有其他的担心,我没有考虑?

这里的关键是你可以控制你的networking的一小段,并启用大的MTU,但你不能控制你的数据包通过互联网的path,当然不能控制你的数据包将通过的路由器的configuration。 大多数互联网路由器没有configuration在1500以上,所以你不会有这个解决scheme的运气。 更糟糕的是,有时更大的数据包实际上会被不支持巨型帧的路由器丢弃,所以我认为如果您尝试将巨型帧发送到互联网上,情况会更糟糕。

巨型帧在你的内部networking上非常棒 – 特别是对于stream媒体或iSCSI的networking。

  1. 除非你对互联网的看法是通过一个单一的实体来进行的,这个实体将允许你对这个问题非常具体,然后进行一些同样可控的终点,那么你的交通就有99.9%的机会不会被“完整地”并保持它的JF的。 原因是JF是一个以太网规范,并不是所有的因特网都是以太网,所以它们被拆卸,重组,转换,然后重新打包。
  2. 问题 – 可能不是,也许在第一天,你可能会遇到一两个问题,但一旦起来,工作应该没问题。
  3. 我会说,除非你完全控制从服务器到客户端的连锁的每个部分,否则我会试图devise我的系统考虑最低的,而不是最高的公分母,即让它工作然后调整,而不是反过来。

正如其他人所说的,目前的答案是否定的。

另外考虑你的提供商的上行链路的MTU,除非支持巨型帧,那么在你开始之前,你是不走运的。

许多高等教育networking(AARNET,JANET,Internet2)在其networking上具有端到端的巨型帧。 如果你在这些networking上服务的人,我会build议这是值得的。

我的经验是,巨型帧通常被限制在应用程序服务器与其数据库服务器之间的专用链接上。 在任何更复杂的事情上不兼容的可能性types的数量是令人难以置信的。