之前发现两部服务器(233和41)之间数据传输有时候会出现问题。
233这边给每个段都回应了dup ack
但是41"我行我素",一直发送包,不理会233的dup ack
233 dup ack发送很多之后,就停止响应了
看现象应该是sack引起的问题,关闭sack后,通信恢复正常。
但问题原因是什么,没有头绪。后来向tcpburn的作者@wangbin求助。
在wangbin的帮助下,解决了这个问题。
我们先列出两个服务器捉包的记录做对比。
41(62897)服务器捉包如下:
seq ack length
62897>22326 syn 0
22326>62897 syn,ack 0 1
62897>22326 ack 1 1
22326>62897 1 1 14
62897>22326 1 15 0
62897>22326 1 15 73 8762->5866->2970 =2896
22326>62897 15 74 26
62897>22326 74 41 7240
62897>22326 7341 41 7240
22326>62897 41 2970 0
22326>62897 41 5866 0
62897>22326 14554 41 5792
22326>62897 41 8762 0
62897>22326 20346 41 1448
22326>62897 41 8762 0 dup ack #1 sack 10210-11658
62897>22326 21794 41 2896
22326>62897 41 8762 0 dup ack #2 sack 10210-13106
62897>22326 24690 41 1448
22326>62897 41 8762 0 dup ack #3 sack 10210-14554
62897>22326 26138 41 1448
22326>62897 41 8762 0 dup ack #4 sack 10210-16002
62897>22326 27586 41 1448
22326>62897 41 8762 0 tcp dup ack #5 10210-17450
62897>22326 29034 41 1448
22326>62897 41 8762 0 tcp dup ack #6 10210-18898
62897>22326 30482 41 1448
22326>62897 41 8762 0 tcp dup ack #7 10210-20346
62897>22326 31930 41 1448
22326>62897 41 8762 0 tcp dup ack #8 10210-21794
62897>22326 33378 41 1448
22326>62897 41 8762 0 tcp dup ack #9 10210-23242
62897>22326 34826 41 1448
22326>62897 41 8762 0 tcp dup ack #10 10210-24690
62897>22326 36724 41 1448
22326>62897 41 8762 0 tcp dup ack #11 10210-26138
62897>22326 37722 41 1448
22326>62897 41 8762 0 tcp dup ack #12 10210-27586
62897>22326 39170 41 817
22326>62897 41 8762 0 tcp dup ack #13 sack 10210-29034
22326>62897 41 8762 0 tcp dup ack #14 sack 10210-30482
22326>62897 41 8762 0 tcp dup ack #15 sack 10210-31930
22326>62897 41 8762 0 tcp dup ack #16 sack 10210-33378
22326>62897 41 8762 0 tcp dup ack #17 sack 10210-34826
22326>62897 41 8762 0 tcp dup ack #18 sack 10210-36274
22326>62897 41 8762 0 tcp dup ack #19 sack 10210-37722
62897>22326 8762 41 1448 TCP Fast Retransmission
22326>62897 41 8762 0 tcp dup ack #20 sack 10210-39170
22326>62897 41 8762 0 tcp dup ack #21 sack 10210-39987
62897>22326 8762 41 1448 TCP Retransmission
62897>22326 8762 41 1448 TCP Retransmission
62897>22326 8762 41 1448 TCP Retransmission
62897>22326 8762 41 1448 TCP Retransmission
62897>22326 8762 41 1448 TCP Retransmission
62897>22326 FIN,ack 39987 41 0
22326>62897 41 8762 0 tcp dup ack #22 sack 10210-39988
62897>22326 8762 41 1448 TCP Retransmission
62897>22326 8762 41 1448 TCP Retransmission
62897>22326 8762 41 1448 TCP Retransmission
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
22326>62897 41 8762 0 tcp fin,ack sack 10210-39988
233(22326)服务器捉包如下:
seq ack length
62897>22326 SYN 0
22326>62897 SYN ACK 0 1
62897>22326 ACK 1 1
22326>62897 1 1 14
62897>22326 ACK 1 15 0
62897>22326 1 15 73
22326>62897 15 74 0
22326>62897 15 74 26
62897>22326 74 41 1448
62897>22326 1552 41 1448
22326>62897 41 2970 0
62897>22326 2970 41 1448
62897>22326 4418 41 1448
22326>62897 41 5866 0
62897>22326 5866 41 1448
62897>22326 7314 41 1448
22326>62897 41 8762 0
62897>22326 10210 41 1448
22326>62897 41 8762 0 tcp dup ack #1 10210-11658
62897>22326 11658 41 1448
22326>62897 41 8762 0 tcp dup ack #2 10210-13106
62897>22326 13106 41 1448
22326>62897 41 8762 0 tcp dup ack #3 10210-14554
62897>22326 14554 41 1448
22326>62897 41 8762 0 tcp dup ack #4 10210-16002
62897>22326 16002 41 1448
22326>62897 41 8762 0 tcp dup ack #5 10210-17450
62897>22326 17450 41 1448
22326>62897 41 8762 0 tcp dup ack #6 10210-18898
62897>22326 18898 41 1448
22326>62897 41 8762 0 tcp dup ack #7 10210-20346
62897>22326 20346 41 1448
22326>62897 41 8762 0 tcp dup ack #8 10210-21794
62897>22326 21794 41 1448
22326>62897 41 8762 0 tcp dup ack #9 10210-23242
62897>22326 23242 41 1448
22326>62897 41 8762 0 tcp dup ack #10 10210-24690
62897>22326 24690 41 1448
22326>62897 41 8762 0 tcp dup ack #11 10210-26138
62897>22326 26138 41 1448
22326>62897 41 8762 0 tcp dup ack #12 10210-27586
62897>22326 27586 41 1448
22326>62897 41 8762 0 tcp dup ack #13 10210-29034
62897>22326 29034 41 1448
22326>62897 41 8762 0 tcp dup ack #14 10210-30482
62897>22326 30482 41 1448
22326>62897 41 8762 0 tcp dup ack #15 10210-31930
62897>22326 31930 41 1448
22326>62897 41 8762 0 tcp dup ack #16 10210-33378
62897>22326 33378 41 1448
22326>62897 41 8762 0 tcp dup ack #17 10210-34826
62897>22326 34826 41 1448
22326>62897 41 8762 0 tcp dup ack #18 10210-36274
62897>22326 36274 41 1448
22326>62897 41 8762 0 tcp dup ack #19 10210-37722
62897>22326 37722 41 1448
22326>62897 41 8762 0 tcp dup ack #20 10210-39170
62897>22326 39170 41 817
22326>62897 41 8762 0 tcp dup ack #21 10210-39987
62897>22326 fin,ack 39987 41 0
22326>62897 41 8762 0 tcp dup ack #22 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
22326>62897 fin,ack 41 8762 0 sack 10210-39988
先看233的捉包记录,看起来是正常的。
一开始没丢包的时候。两个TCP包ACK一次。后来在8762这个点丢包后,启用了sack机制,一个包ack一次。
但一直没有收到来自41的补传报。先收到fin,ack包,数据到这里传输失败。
这样分析的话,问题就出现在41上面。
分析下41的包,前面都是传了几个大包(7240,7240,5792,1448)。
到这一行
22326>62897 41 8762 0 dup ack #1 sack 10210-11658
出现tcp dup ack #1 后,传了一个2896的包之后,就开始都传递1448的包。
传完所有数据后,启动补传机制补传
62897>22326 8762 41 1448 TCP Fast Retransmission
但这几个数据包,从233服务器的捉包情况来看,233服务器没有收到。最后的fin,ack确实收到了。
所以这个传输过程就失败了。
根据分析是因为前面打包用了offload分包,但后面的sack出现后,协议层就把包分好(1448是数据长度,不包含头部)
这里就怀疑是网卡offload和sack不兼容导致这种问题。
把sack启用,把网卡offload禁用。服务器通信也恢复正常。包大小都是1448.
原创文章,转载请注明: 转载自肚腩照明月'blog
本文链接地址: 网卡overload引起的通信故障分析
文章的脚注信息由WordPress的wp-posturl插件自动生成
网卡overload引起的通信故障分析