转自：https://www.2cto.com/net/201309/243585.html（相关链接）
深入浅出TCP之半关闭与CLOSE_WAIT
终止一个连接要经过4次握手。这由TCP的半关闭（half-close）造成的。既然一个TCP连接是全双工（即数据在两个方向上能同时传递，可理解为两个方向相反的独立通道），因此每个方向必须单独地进行关闭。
这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接。当一端收到一个FIN，内核让read返回0来通知应用层另一端已经终止了向本端的数据传送。发送FIN通常是应用层对socket进行关闭的结果。
例如：TCP客户端发送一个FIN，用来关闭从客户到服务器的数据传送。
半关闭对服务器究竟有什么影响呢？先看看下面的TCP状态转化图
tcp状态装换图
TCP状态说明
CLOSED：表示初始状态。对服务端和C客户端双方都一样。 LISTEN：表示监听状态。服务端调用了listen函数，可以开始accept连接了。 SYN_SENT：表示客户端已经发送了SYN报文。当客户端调用connect函数发起连接时，首先发SYN给服务端，然后自己进入SYN_SENT状态，并等待服务端发送ACK+SYN。 SYN_RCVD：表示服务端收到客户端发送SYN报文。服务端收到这个报文后，进入SYN_RCVD状态，然后发送ACK+SYN给客户端。 ESTABLISHED：表示连接已经建立成功了。服务端发送完ACK+SYN后进入该状态，客户端收到ACK后也进入该状态。 FIN_WAIT_1：表示主动关闭连接。无论哪方调用close函数发送FIN报文都会进入这个这个状态。 FIN_WAIT_2：表示被动关闭方同意关闭连接。主动关闭连接方收到被动关闭方返回的ACK后，会进入该状态。 TIME_WAIT：表示收到对方的FIN报文并发送了ACK报文，就等2MSL后即可回到CLOSED状态了。如果FIN_WAIT_1状态下，收到对方同时带FIN标志和ACK标志的报文时，可以直接进入TIME_WAIT状态，而无须经过FIN_WAIT_2状态。 CLOSING：表示双方同时关闭连接。如果双方几乎同时调用close函数，那么会出现双方同时发送FIN报文的情况，此时就会出现CLOSING状态，表示双方都在关闭连接。 CLOSE_WAIT：表示被动关闭方等待关闭。当收到对方调用close函数发送的FIN报文时，回应对方ACK报文，此时进入CLOSE_WAIT状态。 LAST_ACK：表示被动关闭方发送FIN报文后，等待对方的ACK报文状态，当收到ACK后进入CLOSED状态。 特别提示的是：为什么TIME_WAIT状态还需要等待2MSL才能回到CLOSED状态？或者为什么TCP要引入TIME_WAIT状态？ 《TCP/IP详解》中如此解释：当TCP执行一个主动关闭，并发回最后一个ACK后，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL，这样可以让TCP再次发送最后的ACK以防止这个ACK丢失（另一端超时重发最后的FIN）。 附注：MSL（Maximum Segment Lifetime）即最大生存时间，RFC 793中指出MSL为2分钟，但是实现中的常用值为30秒、1分钟或者2分钟。
客户端主动关闭时，发出FIN包，收到服务器的ACK，客户端停留在FIN_WAIT2状态。而服务端收到FIN，发出ACK后，停留在COLSE_WAIT状态。
这个CLOSE_WAIT状态非常讨厌，它持续的时间非常长，服务器端如果积攒大量的COLSE_WAIT状态的socket，有可能将服务器资源耗尽，进而无法提供服务。
那么，服务器上是怎么产生大量的失去控制的COLSE_WAIT状态的socket呢？我们来追踪一下。
一个很浅显的原因是，服务器没有继续发FIN包给客户端。
服务器为什么不发FIN，可能是业务实现上的需要，现在不是发送FIN的时机，因为服务器还有数据要发往客户端，发送完了自然就要通过系统调用发FIN了，这个场景并不是上面我们提到的持续的COLSE_WAIT状态，这个在受控范围之内。
那么究竟是什么原因呢，咱们引入两个系统调用close(sockfd)和shutdown(sockfd,how)接着往下分析。
在这儿，需要明确的一个概念---- 一个进程打开一个socket，然后此进程再派生子进程的时候，此socket的sockfd会被继承。socket是系统级的对象，现在的结果是，此socket被两个进程打开，此socket的引用计数会变成2。
继续说上述两个系统调用对socket的关闭情况。
调用close(sockfd)时，内核检查此fd对应的socket上的引用计数。如果引用计数大于1，那么将这个引用计数减1，然后返回。如果引用计数等于1，那么内核会真正通过发FIN来关闭TCP连接。
调用shutdown(sockfd，SHUT_RDWR)时,内核不会检查此fd对应的socket上的引用计数，直接通过发FIN来关闭TCP连接。
现在应该真相大白了，可能是服务器的实现有点问题，父进程打开了socket，然后用派生子进程来处理业务，父进程继续对网络请求进行监听，永远不会终止。客户端发FIN过来的时候，处理业务的子进程的read返回0，子进程发现对端已经关闭了，直接调用close()对本端进行关闭。实际上，仅仅使socket的引用计数减1，socket并没关闭。从而导致系统中又多了一个CLOSE_WAIT的socket。。。
如何避免这样的情况发生？
子进程的关闭处理应该是这样的：
shutdown(sockfd, SHUT_RDWR);
close(sockfd);
这样处理，服务器的FIN会被发出，socket进入LAST_ACK状态，等待最后的ACK到来，就能进入初始状态CLOSED。
补充一下shutdown()的函数说明
linux系统下使用shutdown系统调用来控制socket的关闭方式
int shutdown(int sockfd,int how);
参数 how允许为shutdown操作选择以下几种方式：
SHUT_RD：关闭连接的读端。也就是该套接字不再接受数据，任何当前在套接字接受缓冲区的数据将被丢弃。进程将不能对该套接字发出任何读操作。对TCP套接字该调用之后接受到的任何数据将被确认然后被丢弃。
SHUT_WR:关闭连接的写端。
SHUT_RDWR:相当于调用shutdown两次：首先是以SHUT_RD,然后以SHUT_WR
注意:
在多进程中如果一个进程中shutdown(sfd, SHUT_RDWR)后其它的进程将无法进行通信. 如果一个进程close(sfd)将不会影响到其它进程.