By Zong

Contents

博客里面多次提到金山云，没错我们项目的服务器都在金山云上，有时也会踩到金山云的坑啊！
这次遇到的MTU值问题估计也是，因为我在其他机房一直没遇到过这种问题，导致MTU值是个什么鬼都基本一知半解。。

先来科普下MTU:

  1. 基础知识
    我们知道, 数据在网络上传输时, 要经过一段一段的链路。当数据从某一段链路的一端传到另一端的过程中, 需要考虑的是数据链路层协议, 在这一层, 我们观察到的数据包(PDU: Packet Data Unit)称为MAC帧(MAC Frame), 不同的数据链路层协议, MAC Frame的格式也不同, 但大致都会有目标MAC地址、源MAC地址、长度/类型、数据(有效载荷: Payload)这几个字段。 对以太网而言, 采用的是数据链路层协议是基于IEEE 802.2/802.3, 但与IEEE 802.2/802.3略有区别.
    查一下802.3协议中MAC帧格式部分, 就会发现上面提到的MAC帧中的数据(有效)字段的长度范围是46-1500个字节. 那么, 当链路层的上一层－IP层所要传输的IP数据包(包括IP Header)大小超过这个长度范围时, IP数据包就必须分成多片传输, 这个过程就是分片(Fragmentating), 其中分割出来的每一个片断就是一个Fragment.

  2. MTU与Fragment
    上述链路层这种对超过其协议定义的最大数据字段长度时就进行分片的特性, 就称为MTU(Maximum Transmission Unit). 不同链路层协议, MTU值也不同, 我们已经知道, 对以太网, MTU是1500字节, 而对令牌环(Token Ring)网, MTU是4482字节.

怎么判断是由MTU造成上传失败的呢？主要是抓包
之前小伙伴已经测试过在公司网络，其他地点用同一个程序上传都ok，在金山主机上就不行，所以主要怀疑点就在网络上。

看下失败时候的抓包，可以看到很多RTO重发，重发包的不分片长度是1500，就是MTU值

RTO

附上linux抓包命令，导出的文件用wireshark打开

1
sudo tcpdump -X -w qiyu2.pcap -i eth0  host 223.252.207.50

然后对比一下在本地电脑传输成功时候的抓包，不分片长度只有1426

success

这样对比就出来了，众所周知Linux和win的默认MTU值都是1500，以太网也是支持MTU值1500的，这个问题就比较坑了，也不知是不是路由链路上某个节点的MTU值特别坑。。

修改MTU值做一下测试

1
echo '1472' |sudo tee /sys/class/net/eth0/mtu

结果上传成功了！

中间还使用了ping测试MTU值的合适大小，结果得出一个很小的值214，咨询金山客服说是对icmp有MTU限制，对TCP和UDP没有限制。

linux上不分片ping，包长度214

1
ping -M do -s 214 223.252.207.50
Contents