CLOSE_WAIT1 CLOSE_WAIT状态的生成原因[转]

CLOSE_WAIT状态的生成原因
首先我们知道，如果我们的Client程序处于CLOSE_WAIT状态的话，说明套接字是被动关闭的！

因为如果是Server端主动断掉当前连接的话，那么双方关闭这个TCP连接共需要四个packet：

Server  —>  FIN  —>  Client

Server  <—  ACK  <—  Client

这时候Server端处于FIN_WAIT_2状态；而我们的程序处于CLOSE_WAIT状态。

Server  <—  FIN  <—  Client

这时Client发送FIN给Server，Client就置为LAST_ACK状态。

Server  —>  ACK  —>  Client

Server回应了ACK，那么Client的套接字才会真正置为CLOSED状态。

我们的程序处于CLOSE_WAIT状态，而不是LAST_ACK状态，说明还没有发FIN给Server，那么可能是在关闭连接之前还有许多数据要发送或者其他事要做，导致没有发这个FIN packet。

原因知道了，那么为什么不发FIN包呢，难道会在关闭己方连接前有那么多事情要做吗？

elssann举例说，当对方调用closesocket的时候，我的程序正在调用recv中，这时候有可能对方发送的FIN包我没有收到，而是由TCP代回了一个ACK包，所以我这边套接字进入CLOSE_WAIT状态。

所以他建议在这里判断recv函数的返回值是否已出错，是的话就主动closesocket，这样防止没有接收到FIN包。

因为前面我们已经设置了recv超时时间为30秒，那么如果真的是超时了，这里收到的错误应该是WSAETIMEDOUT，这种情况下也可以主动关闭连接的。

还有一个问题，为什么有数千个连接都处于这个状态呢？难道那段时间内，服务器端总是主动拆除我们的连接吗？

不管怎么样，我们必须防止类似情况再度发生！