一次由于 MTU 设置不当导致的网络访问超时 现象 分析 解决 扩展

转自:http://weibo.com/ttarticle/p/show?id=2309404140904511340923

API 服务正常,但是调用总是超时。api端日志显示,响应速度很快。

​​​

Server A 调用本机的接口,能正常返回。调用Server B的接口,总是超时。被调用接口是能正常执行的,而且有执行日志记录。
Server C 调用Server B的接口也能正常返回

分析

根据以上,基本可以排除是Server B接口服务的问题导致超时。很有可能 Server A 与 Server B之间的网络有问题。抓包分析如下:

Server A 调用 Server B接口时,抓包情况如下:

一次由于 MTU 设置不当导致的网络访问超时
现象
分析
解决
扩展

可见,在调用Server B的接口时,重试很严重。见上图的黑色行。

当 MTU 值或者 MSS 值设置不合适时,会导致这样的问题出现。
首先,查看当前 MTU 的值是多少:
linux 下查看方式如下:

一次由于 MTU 设置不当导致的网络访问超时
现象
分析
解决
扩展

再看这个 MTU 值设置多少合适。使用 ping 命令检测。

一次由于 MTU 设置不当导致的网络访问超时
现象
分析
解决
扩展

​-s 参数说明包的大小。Specifies the number of data bytes to be sent.
后面的 IP 可以设置为 任何一个可以 ping 通的 IP。
当返回值如下时,表示包的大小设置的过大,可以调小:

一次由于 MTU 设置不当导致的网络访问超时
现象
分析
解决
扩展

当出现如下的结果时,说明包大小设置的正常了。

一次由于 MTU 设置不当导致的网络访问超时
现象
分析
解决
扩展

解决

经过上面的 ping 测试,我们可以知道 原先的 MTU 值为 9001,设置的过大。应该改成 2000.
有多种修改的方式,下面就介绍一种。

一次由于 MTU 设置不当导致的网络访问超时
现象
分析
解决
扩展

​设置完成后,再次抓包,情况如下:

一次由于 MTU 设置不当导致的网络访问超时
现象
分析
解决
扩展

可见重传消失了。

扩展

MTU && MSS

MTU: Maxitum Transmission Unit 最大传输单元
MSS: 就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值,这个值TCP协议在实现的时 候往往用MTU值代替(需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes)所以往往MSS为1460。通讯双方会根据双方 提供的MSS值得最小值确定为这次连接的最大MSS值。

wireshark 中的 CP segment of a reassembled PDU

数据超出了TCP的最大MSS时,主机会通过发送多个数据包来传送 这些数据(注意:这些包并未被分片)。对wireshark来说这些对相应同一个查询命令的数据包被标记了“TCP segment of a reassembled PDU”

问题,wireshark如何识别多个数据包是对同一个查询数据包的响应? wireshark是根据sequence number来识别,这些数据包ACK number是相同的,当然number的数值与查询数据包中的next sequence number也是一样的。