1）中间由于长时间没有进行交互，信道被路由器回收

        客户端没有检测到网络连接断线，服务器端异常捕获。日志输出如下：TSocket::read() recv() errno = 10060


错误查找10060

        由于连接方在一段时间后没有正确答复或连接的主机没有反应，连接尝试失败


知识扩展 

        TCP不提供及时连接丢失通知，对于实时保证TCP连接正常的应用程序，需要实现心跳。Thrift基于TCP连接，但不是真正的长连接，只能应用于系统内部稳定高速的网络环境。为了实现真正的长连接，必须要手动在应用程序中添加心跳包，目前采用的方式是客户端定时发送一个心跳包，然后服务器收到之后直接返回该心跳包，客户端在10秒内没有收到心跳包，说明连接断开，重新连接。


2）网络异常

服务器端的系统出现大量未释放的网络连接。用netstat -na查看，连接状态为CLOSE_WAIT

这个问题主要因为TCP的结束流程未走完，造成连接未释放。现设客户端主动断开连接，流程如下

       Client                            消息                                    Server
         close()
                                      ------ FIN ------->
        FIN_WAIT1                                                         CLOSE_WAIT
                                      <----- ACK -------
        FIN_WAIT2
                                                                                  close()
                                       <------ FIN ------                    
        TIME_WAIT                                                       LAST_ACK      
                                      ------ ACK -------> 
                                                                                   CLOSED
           CLOSED

如上图所示，由于Server的Socket在客户端已经关闭时而没有调用关闭，造成服务器端的连接处在“挂起”状态，而客户端则处在等待应答的状态上。此问题的典型特征是：一端处于FIN_WAIT2 ，而另一端处于CLOSE_WAIT. 

核心原因是Thrift在刷新数据的时候，抛出异常，传输层无法调用关闭函数，套接字无法关闭，因此出现CLOSE_WAIT状态