TCP连接网线断开时的情况测试

01/20 15:25
阅读数 79

TCP send断开的一些测试

测试结论:

  1. 服务端循环接收,客户端每隔1s发送,使用默认缓冲区大小,短暂断开服务端网线后再接上(3s左右),现象是客户端继续发送无异常,服务端接收阻塞10s左右后,会一次性收到多条之前客户端缓存区的数据。
  2. 服务端循环接收,客户端每隔1s发送,不启用keepalive,短暂断开客户端网线后再接上(3s左右),现象是客户端send直接返回-1,服务端阻塞等待数据,会一直等待下去。
  3. 将客户端发送缓冲设置为0,其它同测试1,短暂断开服务端网线后再接上(3s左右),现象是客户端发送在服务端断开后会阻塞,过12s左右后继续正常发送。
  4. 其它同测试一,网线断开后不再接上,现象是在服务端网线断开后,客户端发送持续成功,直到过了20s左右,客户端发送才返回了-1。(测试过修改发送缓冲大小和增加发送超时,都无效,还是20s)
  5. 同测试2,服务端增加keepalive设置,设置为10s无法送开始发探测包,1s一个最多发3个,现象是客户端send直接返回-1,服务端接收过13s返回了-1。

 

测试4的msdn解释:If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in nonblocking mode.即只要协议栈缓冲区窗口没满,send就会成功,但是增大缓冲区,测试还是20s返回-1,这里没找到能增大这个超时时间的办法,缩短确实可以,测试3缓冲区发满后,发送就会阻塞。

以下是《effective TCP/IP programming》的说明。

 

1.测试条件:

服务端程序跑在树莓派上,连接后循环recv,如果有数据,打印数据,如果数据长度<=0,则打印长度。

客户端程序跑在windows下,每隔1s发送一次”hello world”。

服务端程序:

 

 

 

 

客户端程序:

 

 

 

 

操作:在9s时,断开服务端网线,等待3s后,将网线接回。

服务端结果:

 

 

 

 

客户端结果:

 

 

 

 

2.测试条件

其它同测试1,但是不断开服务端网线,断开客户端网线。

服务端结果:

 

 

 

客户端结果:

 

 

 

3.测试条件

将客户端发送缓冲设置为0,其它同测试1。

客户端代码:

 

 

 

 

客户端结果:

 

 

 

 

服务端结果:

 

 

 

 

4.测试条件

其它同测试1,但是服务端断开后不再接上网线。

客户端结果:

 

 

 

 

服务端结果:

 

 

 

 

5.测试条件

同测试2,服务端增加keepalive设置

 

 

 

 

客户端结果:

 

 

 

 

服务端结果:

 

 

 

第四条已经找到了原因
 
 
抓包发现,默认情况下,windows下的重发包是0.6s,1.2s,2.4s,4.8s, 9.6s,总计差不多就是20s。
 
 
 
这是客户端设置了0.5s没收到数据发送keepalive的抓包情况,每隔1s,共发10次,可以看到,可以在10s左右就可以检测到错误。
 
抱着这个问题,首先回顾了《TCP/IP详解卷1》,在178页 18.3连接建立的超时中看到,第一次重传时间是6秒,第二次是24秒,这显然和我实际看到的不一样。
另外在书中第21章《TCP的超时与重传》中可以看到关于RTO和RTT的概念。

RTT = Round Trip Time

指连接的往返时间,由三部分组成:链路的传播时间、末端系统的处理时间、路由器缓存中的排队和处理时间,反应了网络当前的状况。

RTO = Retransmission TimeOut

指连接的超时重传时间,根据RTT不断的进行调整,防止重传时间太短导致发出太多包,防止重传时间太长使得应用层反应缓慢。

稍微看了下感觉其中的计算可能过时了(后来发现确实是如此)。

去RFC查了下,重传超时相关最新的是RFC6298,他更新了RFC1122并且废弃了RFC2988。
文中提到,对于同一个包的多次重传,必须使用Karn算法,也就是刚才看到的双倍增长。
 
不同系统下这个时间次数都不相同,windows下
 
 
与抓包结果相符。
 
 

 

原文出处:https://www.cnblogs.com/gezi/p/12218174.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部