TCP send断开的一些测试

测试结论：

服务端循环接收，客户端每隔1s发送，使用默认缓冲区大小，短暂断开服务端网线后再接上(3s左右)，现象是客户端继续发送无异常，服务端接收阻塞10s左右后，会一次性收到多条之前客户端缓存区的数据。

服务端循环接收，客户端每隔1s发送，不启用keepalive，短暂断开客户端网线后再接上(3s左右)，现象是客户端send直接返回-1，服务端阻塞等待数据，会一直等待下去。

将客户端发送缓冲设置为0，其它同测试1，短暂断开服务端网线后再接上(3s左右)，现象是客户端发送在服务端断开后会阻塞，过12s左右后继续正常发送。

其它同测试一，网线断开后不再接上，现象是在服务端网线断开后，客户端发送持续成功，直到过了20s左右，客户端发送才返回了-1。(测试过修改发送缓冲大小和增加发送超时，都无效，还是20s)

同测试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