TCP packet length was much greater than MTU

背景：安卓检测程序模拟正常业务每隔5s向服务器发起请求，检测程序采用的协议为http1.1长连接。

问题描述:在客户端发起的请求中，出现tcp数据包大于MTU(最大传输单元)，而且出现了乱序，在这种情况出现时一次请求的时间明显变长，从原先一次请求只需要60ms突增到1s，这个时间相对还是很大的。

问题分析：

从tcp三次握手交互中可以看到客户端MSS=1440;服务器MSS=1460。

从截图中可以看到包的大小为2934，有以下及部分数据组成20bytes TCP header、20bytes IP header、14bytes以太头组成，2934=2880+20+20+14

正常情况下链路上的MTU为1500,1494=1440+20+20+14

从这里可以看到突增的数据正好是最大传输的2倍

为什么会出现以上现象，正常情况下最大传输的数据是由MTU进行控制，当时看到这个问题也觉得很奇怪，但看着也似乎存在某种联系。

这其中涉及到网卡的一个参数TSO

以下是对TSO做的解释：

tso（TCP Segment Offload）是一种利用网卡的少量处理能力，降低CPU发送数据包负载的技术，需要网卡硬件及驱动的支持。

TSO（TCP Segment Offload）

在不支持TSO的网卡上，TCP层向IP层发送数据会考虑mss，使得TCP向下发送的数据可以包含在一个IP分组中而不会造成分片，mss是在TCP初始建立连接时由网卡MTU确定并和对端协商的，所以在一个MTU=1500的网卡上，TCP向下发送的数据不会大于min(mss_local, mss_remote)-ip头－tcp头。

而当网卡支持TSO时，TCP层会逐渐增大mss（总是整数倍数增加），当TCP层向下发送大块数据时，仅仅计算TCP头，网卡接到到了IP层传下的大数 据包后自己重新分成若干个IP数据包，添加IP头，复制TCP头并且重新计算校验和等相关数据，这样就把一部分CPU相关的处理工作转移到由网卡来处理。 内核TCP/IP协议栈也必须考虑下发包数和实际包数不一致的情况，例如处理拥塞控制算法时必须做一些特殊的处理等等。

处理方式：

查看网卡是否开启TSO：ethtool -k eth0

 

关闭TSO：/sbin/ethtool -K eth0 tso off

开启TSO:/sbin/ethtool -K eth0 tso on