四次挥手的中间状态错误问题

今天模拟了四次挥手中的一些错误，开门见山，先来TCP状态转移图 

当然四次挥手的主动方不一定是客户端，正常情况下是客户端，但是如果客户端长时间未响应，服务器也可以主动断开（防止恶意占用系统资源和网络不好情况）

 

四次挥手图和状态图来自百度，连接图来自我的服务器

• 在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
• 在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。

 

连接中出现大量FIN_WAIT2和CLOSE_WAIT问题

CLOSE_WAIT问题

我运行服务器时，并发连接，结合代码和四次挥手图片，发现

CLOSE_WAIT状态被动关闭的状态,此时自己还没有发送最后一次FIN包，处于忙处理阶段，一般是几分钟的过程，比如服务器需要繁琐的处理和交流，依然需要发包，此时就会有一定量的CLOSE_WAIT。

服务器端处于CLOSE_WAIT状态，说明应用程序没有关闭相应的socket，也就不会发送最后的FIN,所以客户端处于FIN_WAIT_2状态。

 

FIN_WAIT2问题

这个就比较严重了，作为主动关闭方，当主动方发送FIN包时，良性的被动方自然立刻回复ACK。主动方就跳过FIN_WAIT1状态进入FIN_WAIT2状态，如果被动方不发送ACK，主动方则会一直处于FIN_WAIT2。

表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。 

比如服务器发现客户端有问题，断开连接，但是客户端迟迟不发FIN包，一直进行数据传输，那么TCP规则下，服务器一直要保持FIN_WAIT2状态

SERVER由于某种原因关闭连接，如KEEPALIVE的超时，这样，作为主动关闭的SERVER一方就会进入 FIN_WAIT2状态，但TCP/IP协议栈有个问题，FIN_WAIT2状态是没有超时的（不象TIME_WAIT状态），所以如果CLIENT不关闭，这个FIN_WAIT_2状态将保持到系统重新启动，越来越多的FIN_WAIT_2状态会致使内核crash。

根据网上的一些博客设置一些参数，可以让长时间的FINWAIT2进入TIME_WAIT
现实终究是打败了标准

FIN_WAIT2 状态的 TCP 连接会进入 TIME_WAIT 状态