主页 > 网络知识 > 网卡overload引起的通信故障分析

网卡overload引起的通信故障分析

2014年12月11日 发表评论 查看评论

之前发现两部服务器(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插件自动生成


  1. 本文目前尚无任何评论.

SEO Powered by Platinum SEO from Techblissonline