由上图可看：tcp连接的时候发生了三次握手的过程，分别对应有四个状态
client: SYN_SENT -> ESTABLISHED
server: LISTEN -> SYN_RECV -> ESTABLISHED
(6种状态)
当客户端主动关闭的时候，发送FIN 信号到服务端，此时服务端通知应用程序的接收数据由开始的recv([1024])变为recv(0) ，还通知阻塞的线程不用再接收数据了，此时服务端接收还没有完全关闭，代码还没有往下执行，当得到cpu之后，再往下执行的时候服务端的状态再变为LASK_ACK(最后一次通知结束)，直到最后两个都变为CLOSED。
笔者在做thrift遇到一个问题，当服务一直跑的时候客户端再也调取不到服务端了，服务端的多种状态一直是CLOSE_WAIT的状态，如图：
分析问题：
1. 客户端请求过多，导致服务器线程池无法及时处理，此时服务端在一个无响应的状态，即使发送再多的请求也无法响应，减少不必要的请求，降低timeout时间
2.服务器大量的CLOSE_WAIT说明系统CLOSE_WAIT设置时间过长
3. 检查客户端是否能够正常关闭
相关资料：
tcp详解