背景:安卓检测程序模拟正常业务每隔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