TCP 状态转换与（close_wait,time_wait问题)

TCP 状态转换

TCP的状态转换主要分应用端状态转换以及服务端状态的转换

状态：

描述状态转换之前先需要了解有TCP相关状态

状态	描述
CLOSED	初始状态
LISTEN	服务端处于监听状态，可以接受连接
SYN_RCVD	握手状态：接受了SYN报文，等待客户端ACK报文
SYN_SENT	握手状态：客户端执行连接操作，发送SYN报文，等待服务端消息
ESTABLISHED	连接已经
FIN_WAIT_1	客户端发送了FIN报文，等待服务端回复
FIN_WAIT_2	客户端发送了FIN报文，服务端已经回复
TIME_WAIT	收到了对方的FIN报文，并发送出了ACK报文，等2MSL后返回CLOSED可用状态
CLOSE_WAIT	收到对方的FIN报文，此次返回ACK报文给对方，然后等待数据传输完毕后进行关闭之间的状态
LAST_ACK	发送确认关闭的FIN报文，等待对方返回ACK
CLOSING	如果双方尝试同时close一个Socket，同时发送FIN报文，会出现此状态

TCP的标志位

标志位	描述
ACK	置1时表示确认号，为0的时候表示数据段不包含确认信息，确认号被忽略
PSH	置1时请求的数据段在接收方得到后就可直接送到应用程序，而不必等到缓冲区满时才传送。
SYN	置1时用来发起一个连接
FIN	置1时表示发端完成发送任务。用来释放连接，表明发送方已经没有数据发送了
RST	置1时重建连接
URG	紧急指针，告诉接收TCP模块紧要指针域指着紧要数据

应用端状态转换

1. 初始状态CLOSE
2. 发送SVN后，状态变更为：SYN_SENT
3. 接收服务器返回信息后，状态变更为：ESTABLISHED
4. 发送FIN后此时服务端也在发送FIN，则状态变更为：CLOSING
5. 此时接收到ACK，但是没有接收到FIN，等待数据传输完成，则状态变更为：FIN_WAIT_2
6. 此时马上接收到接收:FIN ACK，则状态变更为：TIME_WAIT
7. 等待2MSL后返回CLOSED

 

服务端状态转换

1. 初始状态CLOSE
2. 服务端开打监听后，状态变更为：LISTEN
3. 接收:SYN消息，状态变更为：SYN_RCVD
4. 发送SYN,ACK并接收ACK，状态变更为：ESTABLISHED
5. 接收:FIN 发送:ACK，状态变更为：CLOSE_WAIT
6. 完成数据传输，发送FIN，状态变更为：LAST_ACK
7. 获得应用返回的ACK，状态变更为：CLOSE

 

 

Close_Wait引发的问题
Close_Wait会占用一个连接，网络可用连接小。数量过多，可能会引起网络性能下降，并占用系统非换页内存。 尤其是在有连接池的情况下(比如HttpRequest)
会耗尽连接池的网络连接数，导致无法建立网络连接。

解决方法

下面来讨论下这两种情况的处理方法，优化系统内核参数解决TIME_WAIT可能很容易，可以通过修改/etc/sysctl.conf文件解决；

但是应对CLOSE_WAIT的情况还是需要从程序本身出发。因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。从上面的图可以看出来，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出FIN信号，一般原因都是TCP连接没有调用关闭方法。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行，一定程度上，可以使用TCP的KeepAlive功能，让操作系统替我们自动清理掉CLOSE_WAIT连接。