TCP连接网线断开时的情况测试
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设置
客户端结果：
服务端结果：
RTT = Round Trip Time
指连接的往返时间，由三部分组成：链路的传播时间、末端系统的处理时间、路由器缓存中的排队和处理时间，反应了网络当前的状况。
RTO = Retransmission TimeOut
指连接的超时重传时间，根据RTT不断的进行调整，防止重传时间太短导致发出太多包，防止重传时间太长使得应用层反应缓慢。
稍微看了下感觉其中的计算可能过时了（后来发现确实是如此）。