MTU导致通信不正常问题

其实这个问题一看到题目就知道了,但是分析起来还是有点绕弯弯,虽然是一个貌似很常见的问题,但是职业生涯还是第一次遇到,记录一下。

下午业务跟网络的同学反馈,某云主机访问自建IDC个别服务不正常,拿过一份抓包文件看了下,看到有重传,但是并没有特别的明显标示,于是建议两端转包,然后拿到了如下两份抓包结果:

服务端:

客户端:

从图上看出,服务器收到客户端的get请求之后,回应了两个个2962+140的包,当然,因为打开了网卡拆分tcp选项,所以2962的包到网络必然会被拆成两个包,但是从对方来看,并没有收到2962的包内容,然后客户端回了一个dup ack,表示中间丢包了,服务器端连续发了7个包,客户端都未收到,然后客户端在1分钟后发送keep alive信息,服务端发送rst,会话终止,注意其中服务端发送的多个包,客户端未收到,总结下来,看起来较大的包,客户端都没收到,怀疑是MTU问题,拿到云上环境其他主机看了下,确实MTU是1400,比我方的1500小,但是注意截图中红框的部分,客户端TCP通告的MTU是1460,那么说明对方服务器配置的MTU可能仍然是1500,因为MSS通常是 网卡MTU-ip包头20-tcp包头20算出来的,登录上对方的服务器检查,发现MTU确实跟其他机器不一致,是1500。

那么,对方正常云主机MTU配置都是1400,应当是有依据的,因为linux默认是1500,应该是对方基础网络设备上的限制,必须要1400,大一些的可能通不过部分网络设备,所以,即使对方服务器配置1500,通告到我方之后,我方按较大的报文发送,到了对方网络环境当中某些节点,可能还是会被丢弃,这就是问题的原因。跟对方运维负责人沟通后,也验证了这一问题。

此条目发表在好玩的linux, 网络分类目录。将固定链接加入收藏夹。