MTU导致的网络问题分析

问题2：MTU导致的网络问题分析

MTU是什么

MTU是Maximum Transmission Unit的缩写，以太网和802.3对数据帧的长度都有一个限制，其最大值分别是1500字节和1492字节。链路层的这个特性称为MTU，即最大传输单元。不同类型网络的数帧长度大多数都有一个上限。如果IP层有一个数据包要传，而且数据帧的长度比链路层的MTU还大，那么IP层就需要进行分片( fragmentation)，即把数据包分成干片，这样每一片就都小于MTU。

当同一个网络上的两台主机互相进行通信时，该网络的MTU是非常重要。但是如果两台主机之间的通信要通过多个网络，每个网络的链路层可能有不同的MTU，那么这时重要的不是两台主机所在网络的MTU的值，而是两台主机通信路径中的最小MTU，称为路径MTU( Path mtu，PMTU)。

两台主机之间的PMTU不一定是个常数，它取决于当时所选择的路径，而且路由选择也不一定是对称的(从A到B的路由可能与从B到A的路由不同)，因此，PMTU在两个方向上不一定是一致的。 [3]

一个典型的MTU问题发生在类似图1的环境中，即两个子网的MTU大小不一样。

当客户端发给服务器的巨帧经过路由器时，或者被丢包，或者被分片。这取决于该巨帧是否在网络层携带了DF（Don’t fragment）标志。如果带了就被丢弃，如果没带就被分片。从Wireshark上很容易看到DF标志，如图2中的方框内所示。分片的情况往往被忽略，因为它只影响一点点性能，大多数时候甚至察觉不出。丢包的情况就无法忽略了，因为丢包之后再重传多少遍都没用，会一直丢

MSS是什么

MSS是Maximum Segment Size的缩写，最大报文段长度（MSS）是TCP协议的一个选项，用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度（不包括文段头）。

区分MSS与MTU

最大报文段长度（MSS）与最大传输单元（Maximum Transmission Unit, MTU）均是协议用来定义最大长度的。不同的是，MTU应用于OSI模型的第二层数据链接层，并无具体针对的协议。MTU限制了数据链接层上可以传输的数据包的大小，也因此限制了上层（网络层）的数据包大小。例如，如果已知某局域网的MTU为1500字节，则在网络层的因特网协议（Internet Protocol, IP）里，最大的数据包大小为1500字节（包含IP协议头）。MSS针对的是OSI模型里第四层传输层的TCP协议。因为MSS应用的协议在数据链接层的上层，MSS会受到MTU的限制。 [4]

案例1 用户浏览某些共享目录时客户端会死机，浏览其他目录则不会。

碰到这种症状，恐怕没有人会想到是MTU导致的，所以经过长时间徒劳无功的排错之后，工程师不得不抓了个包。这个包是在服务器上抓的（因为客户端死机，根本没法抓），如图5所示，服务器回复的包“Seq=193, Len=1460”在持续重传，但客户端一直没有确认，似乎是发生丢包了。从图5底部还可以看到这个包携带的信息是该目录的子文件（夹）列表。

导致丢包的可能性有很多，怎么认定是MTU导致的呢？

排查思路：

1．如果端口被防火墙阻止了也可能丢包，但是会从三次握手时就开始丢，而不是等到浏览目录的时候。

2．如果网络拥塞也可能丢包，但一段时间后能恢复，而不是这样持续地丢。

3．丢的那个包携带了1460字节（相当于占满了整个1500字节的MTU），算是比较大的。而没被丢弃的2号包和4号包都携带了很少的字节数，只丢大包的症状说明很可能就是MTU导致的。

4．用“ping -l 1472-f”测试，果然失败了。逐渐减小每次ping的长度，到了1400字节左右才成功，这说明网络上有个设备的MTU比较小。

5．于是把服务器上网卡的MTU相应改小，问题果然就消失了。

6．之所以浏览其他目录没有死机，可能是因为这些目录中的子文件（夹）比较少，凑不满一个大包。

案例2 客户端的MTU为1500字节，服务器端的MTU为9000字节，平时连接正常。运维人员听说两端的MTU最好一致，所以把客户端的MTU提高到9000字节，没想到连接反而出问题了。

虽然该案例听上去不太科学，但如果网络路径上有个设备的MTU是1500字节，这个问题就真会发生。原先客户端和服务器在三次握手时，双方会“协商”使用一个1460字节（MTU-TCP头-IP头）的MSS，所以可以顺利通过那个MTU为1500的网络设备。如果两端都是9000字节了，那三次握手时就会得到8960字节的MSS，因此通不过那个网络设备。

其实利用“ping -f -l <字节数>”试探出路径上的最小MTU也可以，前提是网络中没有禁用ICMP。

案例3两地使用两台深信服做IPSEC隧道，连接异常断开问题

问题描述：IPSEC隧道一直是正常运行的，某一天隧道链接断开后，在也不能建立连接，IPSEC是流量触发模式

排查思路：

1、排查配置

2、排查互联网出口设备，以及其他业务流量是否正常

3、设备的日志显示，不能建立隧道链接，抓包分析判断可能是MTU的问题，所以假设运营商的网络中使用是MPLS协议1500=tcp头20字节+IP头20字节+MPLS头4字节+1466字节（数据），首先将设备的mtu修改为1466观察，IPSEC隧道建立失败，然后是不断地改小，改到1440后IPSEC隧道恢复连接，判断为运营商调整过网络，网络中有一台设备的MTU比较小，导致数据报文需要需要分片，而设备DF（Don’t fragment）标志设置为1（不允许分片）导致的网络异常