tcp通道关闭时，发生了什么？

  前段时间，同事发现一个采用Thrift TheadPoolServer作为TCP的服务出现了大量的CLOSE_WAIT状态的socket。当第一次遇到这种问题的时候，你可能会有如下的问题：
什么是CLOSE_WAIT? 为什么会发生?
还有其他类似状态我不知道的么？
其实，你真正想问的是：
当tcp通道关闭时，发生了什么事情？
我该怎么办？
TCP通道是一个连接，连接的两端都可以向通道里写数据或者从通道里读数据，连接的两端都可以发起关闭操作。整个TCP通道的关闭流程如下：
A(socketfd:10) <——–TCP Connction ———->B(socketfd:20)
关闭A，则A向B发送FIN;
B接受到FIN后，返回一个ACK，表明收到了关闭通知， 当B返回ACK后，状态就转变为CLOSE_WAIT（！）了，它在等待什么呢？等待程序显式（手动）的关闭socket B。如果打开B的程序在发出ACK后，没有做任何处理，那么它就一直处于CLOSE_WAIT中了。
如果程序显式的关闭了B，那么B会向A发送一个FIN，然后B就处于LAST_ACK状态了；
A在接受到B的FIN后，发出最后一个ACK，此时A就处于知名的TIME_WAIT状态了。TIME_WAIT时间一般会比较长。
如何避免CLOSE_WAIT? 太多的CLOSE_WAIT通常意味着你程序中存在着严重的问题：没有正确处理socket的关闭事件，去查看代码吧。
如何避免TIME_WAIT? 通常，这是一个不应该问的问题，应该先问自己，TIME_WAIT真的给你带来麻烦了么? TIME_WAIT是可靠性的保证机制，没有必要去避免它。但或许，你可以尝试一下使用RFC1323。如果某一端实在是有太多的TIME_WAIT而造成问题，我建议的策略是：
尽量避免TIME_WAIT过多的一端主动关闭socket
使用SocketPool，避免频繁创建/关闭socket