TCP 协议小研究

目录：

TCP重传机制

client: 192.168.128.1server:192.168.128.129

server 为一个简单监听程序，收到数据后打印，然后再读取流（阻塞)

1、启动服务程序: java -jar tcp-0.0.1-SNAPSHOT.jar -server -serverport 2222

2、监听服务器 2222端口:

tcpdump -n -S tcp port 2222

3、启动client 程序:

java -jar tcp-0.0.1-SNAPSHOT.jar -client -serveraddress 192.168.128.129 -serverport 2222

此时服务器会显示三次握手：

4、查看client 连接端口:

netstat --an查出端口号：53229

5、建立client 的端口监听：windump  -n -S tcp port 53229，然后 client向server 发送数据：查看监听数据如下：

server : 

表示server 已经收到了client 发来的数据

下面看看client 中的数据监听情况：

可以看到client 监听到的数据是一样

6、断开服务器网线，然后client 再向服务器发送数

client 监听到的数据：

从上图可以看出，client 在发送后并没有得到确认信息后，同时会在不同时间间隔内重新发送数据，这就是TCP协议中的重传机制！

TIME_WAIT　意义：

tcp 在关闭连接时，如下图：

 在 client 收到　server 的 ACK 后，client 是已经完成了自己的关闭，进入 FIN_WAIT_2　阶段，而server 在发送 FIN时，client 收到server 的FIN后进入 TIME_WAIT(此时收到server FIN,client就知道server也执行关闭操作，而此时整个连接就已经关闭了)，但 server并不知道client 已经收到了 FIN,因此，client还要给server 返回一个ack,

server 在收到最后一个ack 后，才能确认client 已经收到了FIN,但问题又来了，client 怎么知道自己把最后的 ack 发了过去，怎么知道server 确实收到了自己的ack,因此server 在收到最后一个ack后不会再向client 发送任何信息了，因此，此时就提出了让client 等候一段时间，这段时间就是为了最后一个ack而准备的，如果ack 真的没有发到，则

server 会重发 FIN,client 在 TIME_WAIT　阶段会处理FIN,然后再次发送 最后一个ACK,

因此，TIME_WAIT 就是为了确认　server 重发的 FIN ,注意：TIME_wait只会存在于进行主动关闭的那一端，如果你在一个client 主动关闭，而且你下次以同一个端口启动cilent时，此时会通知：can't bind local address: Address already in use，而我们在主动关闭client时却不报此异常是因此我们的client 每次启动都是由系统分配的不同端口

TCP 呼入队列

TCP 有一个等待连接固定长度人队列，当服务端CPU繁忙时无法处理连接时，系统TCP模块会将其进行确认，也就是进行三次握手，而后将请求放入呼入队列，一般队列长度默认为5，如果队列慢，对于client再次发过来的 请求，server 端的TCP模块就不再进行处理，也不会进行任何响应，client  经过几次重发后就进入了 超时而断开。

使用sock 以下试验：

sock -s -q 1 -O 10000000 2222  q1 指定队列长度 -O TCP在指定时间后再去处理请求

半打开