TCP　SOCKET CLOSE_WAIT状态暂时心得

这一段和前一年在定位故障时，接触到TCP SOCKET CLOSE_WAIT状态相关的概念，但那时不是很明白就离，也没有太多时间让自己去弄懂这件事情，呵呵。正好这段由于一个故障，不得不关注CLOSE_WAIT状态，就顺着一直花费精力研究这个东西。

在研究CLOSE_WAIT状态时，查看了TCP/IP详解第一卷和自己的测试程序运行，以及和一些同仁探讨。虽然现在自己也是一知半解，凭着自己对可理解性的把握，觉得自己已经抓住一些真谛，得出来的一些可以用来说说、晒晒的心得。TCP　SOCKET CLOSE_WAIT这个状态没有什么特殊的，属于程序自身的Bug或刻意为之造成的。因为TCP有半连接的说法，被动被关闭一方Socket状态从EStablished状态到CLOSE_WAIT状态，如果其愿意保持半连接状态，则可以只发送ACK不发送FIN TCP控制信令达到这样的目的。

TCP是双工的，其关闭过程需要双方都关闭。假设在通讯的双方一方，为了讨论的方便，命名为甲方，已经通过FIN TCP控制信令关闭了甲方部分SOCKET资源，而另外一方，为了讨论的方便，命名为乙方，可以通过仅发送ACK 但不发送FIN TCP控制信令的方法，保持乙方处于半连接状态。在这个状态下，乙方可以继续写入数据，而甲方如果也同意保持半连接状态的话，可以继续在这个SOCKET上读取数据。但乙方不可以读取，读取时固定会获得EOF的数据标志，读取的数据长度也是为-1；而且甲方也不可以因写入，因为他的该部分的Socket资源已经关闭。

由于半连接状态是TCP/IP协议允许的状态，如果是程序有意为之或者程序的Bug，就会使得一方的Socket资源长期处于CLOSE_WAIT状态。解决SOCKET close_wait问题采取策略将系统CLOSE_WAIT的最大时长限制的比较小的办法，是不可以取的，因为有些应用如果确实在使用半连接的工作协议，如果太暴力将会出现误判和复杂性。

不过，一般来说，这种现象应该是程序的错误造成的资源挂，可以仔细检查检查，是否正确处理了己方的write和read接口的异常和返回值。