调用closesocket()背后发生的事

应用层代码想要关闭一个TCP连接可以直接调用closesocket()，但是这个函数的行为并不“单纯”，只有了解closesocket()背后的故事，才能对关闭TCP连接有正确的认识。

首先明确一点：任何情况下，调用closesocket之后，socket句柄立即失效(一种情况除外，见下文)，再对该socket进行操作的API都会失败。但是socket句柄对应的系统资源不一定立即释放，由内核控制。

假定A端调用closesocket()，进行主动关闭。以下是几种情况：

1、默认的行为：尽可能的尝试完成4次握手（互相的FIN与ACK），此时，A端发送缓冲区的数据会发送到B端，并等待B端的确认，B端发送FIN后，A端进入TIME_WAIT状态。

2、l_onoff值为0：相当于默认行为。

3、l_onoff值非0，l_linger为0：A端调用closesocket()将发送RST复位连接，所有发送、接收缓冲区的数据都被丢弃，socket资源被释放，A端不进入TIME_WAIT状态。B端的recv会得到WSAECONNRESET错误。

4、l_onoff值非0，l_linger非0，socket是阻塞的：则closesocket()不会立即返回，而是等待l_linger长的时间，在l_linger时间内如果发送缓冲区里的数据发送并被B端确认，则closesocket()返回，之后任然是“优雅”的关闭，A端进入TIME_WAIT状态；如果发送缓冲区的数据没有发送完毕或者没有收到B端确认，则closesocket返回，同时内核放弃没有发送的数据或是不再等待B端的确认，直接发送RST复位连接，A端不进入TIME_WAIT状态。

5、l_onoff值非0，l_linger非0，socket是非阻塞的：调用closesocket()立即返回，如果从调用到返回的时间内，不能完成发送缓冲区数据的发送和对端的确认，则closesocket返回WSAEWOULDBLOCK；要注意的是，返回WSAEWOULDBLOCK不意味着socket句柄失效，仅意味着这次尝试closesocket不成功，应用层需要稍后继续调用closesocket()来尝试关闭连接（是不是觉得和非阻塞下的connect()、send()、recv()很像？：），直到closesocket()不返回WSAEWOULDBLOCK。

 

由以上各种情况也可以看出：应用层简单的closesocket()不能保证对端的应用层正确的收到数据（对端的接收缓冲区收到不代表应用层收到）。