1)中间由于长时间没有进行交互,信道被路由器回收
错误查找10060
由于连接方在一段时间后没有正确答复或连接的主机没有反应,连接尝试失败
知识扩展
TCP不提供及时连接丢失通知,对于实时保证TCP连接正常的应用程序,需要实现心跳.Thrift基于TCP连接,但不是真正的长连接,只能应用于系统内部稳定高速的网络环境。为了实现真正的长连接,必须要手动在应用程序中添加心跳包,目前采用的方式是客户端定时发送一个心跳包,然后服务器收到之后直接返回该心跳包,客户端在10秒内没有收到心跳包,说明连接断开,重新连接。
2)网络异常
服务器端的系统出现大量未释放的网络连接。用netstat na查看,连接状态为CLOSE_WAIT
这个问题主要因为TCP的结束流程未走完,造成连接未释放。现设客户端主动断开连接,流程如下
客户端消息服务器
关闭()
- - - - - - - - - - - -→鳍
FIN_WAIT1 CLOSE_WAIT
& lt; - - - - - - - - - - - - -
消FIN_WAIT2
关闭()
& lt; - - - - - - - - - - - -
鳍TIME_WAIT LAST_ACK
- - - - - - - - - - - -→消
关闭
关闭如上图所示,由于服务器的套接字在客户端已经关闭时而没有调用关闭,造成服务器端的连接处在“挂起”状态,而客户端则处在等待应答的状态上。此问题的典型特征是:一端处于FIN_WAIT2,而另一端处于CLOSE_WAIT。
核心原因是节俭在刷新数据的时候,抛出异常,传输层无法调用关闭函数,套接字无法关闭,因此出现CLOSE_WAIT状态
