写程序，经常碰见这种情况，主要是有一方关闭SOCKET，但是另外一方没有检测到，导致没有检测到的一方出现CLOSE_WAIT的情况.
eg:
[oracle10@RHEL3 cc]$ netstat | grep 6800
tcp 55 0 RHEL3:6800 192.168.1.35:34575 CLOSE_WAIT
tcp 1 0 RHEL3:6800 RHEL3:2176 CLOSE_WAIT
tcp 55 0 RHEL3:6800 RHEL3:2180 CLOSE_WAIT
tcp 1 0 RHEL3:6800 RHEL3:2174 CLOSE_WAIT
tcp 1 0 RHEL3:6800 RHEL3:2175 CLOSE_WAIT
tcp 55 0 RHEL3:6800 192.168.1.35:32998 CLOSE_WAIT
************************
socket在关闭时的几个主要状态
************************
*TIME_WAIT* (FAQ 1578)
当一个socket进程结束后，相应的socket仍会保持TIME_WAIT状态4分钟。这样的目的是为了保证那些因某些原因在网络上传送很慢的包在这个scoket完全关闭之前到达。
这样后来使用同样的socket的进程不会收到本应发给前一个使用该socket的进程的数据包。
相关参数:
tcp_keepalive_interval
tcp_ip_abort_interval
tcp_close_wait_interval
*FIN_WAIT_2* (FAQ 3285)
当server收到一个关闭TCP连接的请求时，它会发一个设置了FIN位的packet给client。client会回应一个设置了ACK位的 packet。然后，client会发送一个设置了FIN位的packet给server，server回应一个ACK，这个连接应关闭了。server 接收到client的ACK，然后开始等待client的FIN包的状态就是FIN_WAIT_2。
在FIN_WAIT_2状态，server不会往client发送数据和控制信息，它只是等待client的FIN包。
相关参数:
tcp_fin_wait_2_flush_interval 系统将会flush out处于FIN_WAIT_2状态的TCP连接的间隔，理论上最小值为6750ms。
*CLOSE_WAIT* (INFO 19137 )
TCP连接总处于CLOSE_WAIT状态是由于当TCP没有开始协议中的CLOSE阶段。
TCP连接中CLOSE_WAIT状态的发生是当server没有收到应用程序的CLOSE，但应用程序已经终止了。这可能是一个有问题的应用程序在关闭窗口并结束之后发出了FIN包。有时候是当Solaris系统缺少kernal，tcp，ip，libnsl 或 rpcbind等patch造成。
CLOSE_WAIT状态意味着连接的另一端已经关闭了，而本地端仍在等待应用程序关闭。一个不确定的TCP连接指示着存在应用一级的bug。
在收到一个从远端发来的FIN之后，收到应用程序发出的CLOSE之前，TCP连接将从ESTABLISHED状态变为CLOSE_WAIT状态， after
从CLOSE_WAIT-> LAST_ACK的转换是在应用程序发出CLOSE时发生的。在转换过程中，TCP会安排(schedule)发送一个FIN，这个FIN将在保留的数据之后发出，如果接收端已经关闭了窗口可能会被延迟。
from : http://www.goodba.net/unix/secure/2-3.htm
-----------------------------------------------
一个client和一个Server，两者之间建立了一个基于TCP的socket连接，在刚刚建立好连接后，尚未进行数据传输，Server端应用程序突然crush掉了，现在立刻重启Server端应用程序（假设间隔很短），一般情况下Server端应用程序是无法启动的。请问是什么原因？
因为绑定的socket还处于CLOSE_WAIT状态，如果用setsockopt，设置SO_REUSEADDR，则不会出现这种情况
from : http://community.csdn.net/Expert/TopicView3.asp?id=5171130