关于MTU和JumboFrame对网络连通性的影响的一些测试近日报装了一条点对点专线,接口是以太网的,因为需要测量出这条链路的MTU,所以对此作了一番研究和实验.我们都知道在网络上传输数据时,大数据会被分解为一个个小数据包来传递.比较常见的说法是这个数据包的尺寸上限被称为MTU，默认为1500字节。其实在以太网+TCP/IP环境中，通俗地说数据包分为两种：以太网数据包，和IP数据包，他们默认的大小分别为1500字节和1472字节，这是因为以太网数据包要包含整个IP数据包，还要加上MAC地址等内容，所以两者之间有一个几十个字节的差异。稍微专业点的说法，以太网数据包应该称为以太网数据帧，或MAC帧。以太网帧在ISO/OSI模型中处于数据链路层的位置；而IP包处于ISO/OSI的网络层的位置。在另外的一些技术文章中，会提到数据包大小的两种应用方向：一是增大数据包以提高网络效率；二是减小数据包以提高网络兼容性，并提高效率。本人就根据第一种应用方向，曾经对局域网内NAS（网络存储）的传输效率做过一些测试，得到的结论是适宜地增大数据包尺寸，可以让NAS的传输速度提高20~40%，但错误地增大数据包尺寸，会导致NAS的传输速度降低95%以上，有兴趣者可以在网上搜索关键字“JumboFrame”和“NAS”参考。在很多Windows计算机中,对网络数据包的尺寸有设置作用的地方有两处，一是注册表中网卡的MTU值；二是网卡驱动程序配置中的JumboFrame（巨型帧）值，请参见下面的图示，关于如何找到修改这两处配置的方法，请在网上自行搜索答案。本文中的测试用计算机的网卡都是Intel主控芯片的，所以在其驱动程序中可以选择设定其JumboFrame。据我所知很多厂家的网卡芯片的驱动程序中都能设置JumboFrame，哪怕是Windows自带的网卡驱动程序。那么我们不禁要产生一个疑问，究竟哪处设置决定数据包的尺寸？它们有何区别？修改之后对网络的连通性（本文仅讨论连通性问题）有何影响？下面直接给出一系列实验的图解，并对实验的参数进行了说明。在下面的测试中，有几点测试环境需要说明：1，所有测试都是用ping加–f参数，强制其不将大数据包拆分；2，很多测试步骤中，用网线直连两台计算机，以摒除网络交换机在中间的影响；结论：1，在同一台Windows计算机中，网卡驱动程序中的JumboFrame值，与注册表中的网卡的MTU值，共同决定计算机的以太网数据包的尺寸，数值小者有效；2，JumboFrame值与MTU值似乎不是完全一回事，当JumboFrame值更小而生效时，最大IP包尺寸比JumboFrame值小42个字节；而MTU值更小而生效时，最大IP包尺寸比MTU值小28个字节。因此怀疑默认的JumboFrame值，在Disable状态下，是1514字节而非1500字节；3，在注册表中去除MTU键值，与设置其为1500，效果是一样的，因此其默认值应该就是1500；4，网络交换机也会成为大数据包通过的障碍，例如百兆的“傻”交换机就只能通过1500字节左右的数据包，而可管理的交换机经过配置，令其支持JumboFrame，就能通过巨大的数据包。有些不可管理的网络交换机（特别是千兆的）也可以支持巨大的数据包直接通过；5，如果本端的计算机的JumboFrame和MTU都足够大，当ping对端的计算机时，对端计算机的JumboFrame值（即便对端的MTU值更小）将决定能ping通的最大IP数据包尺寸；6，如果Ping大包的结果提示DFset，这个信号应该是源设备的IP协议栈自行计算出来的，而非目的设备或网络中间环节的交换机反馈给源计算机的；7，如果ping发送的数据包尺寸，大于目的端的JumboFrame值，或大于中途的网络交换机的允许值，导致数据包无法到达或返回，ping的结果是timeout；而如果对端计算机根本就不在网络中，则ping的结果是Destinationhostunreachable。这可能是因为有一个ARP广播寻址的过程。此结果只限于同网段内，不见得能适用于跨网段，请慎用；