在write或send过程中——网络断了

(iptables封端口，拔网线，对端宕机)—此时应用程序和操作系统都认为连接还是存在的。  

Client端在没有收到Server端的ACK的情况下，会连续重传。

      Linux2.6内核下测试结果为重传16次，总时常为15分钟左右， write或send将返回ETIMEOUT错误，同时发送RST包给Server端 。

      连续重传之间的时间差，分别是0.2、0.4、0.8、1.6、。。。。、120秒，这种倍乘关系称为“指数退避” 。

 

 

     当连接后，send或write过程中， iptables封端口，拔网线，对端宕机， TCP协议感知不到（所以在应用中才使用心跳机制，心跳超时后，服务器可认为连接已断开，主动断开连接）， 操作系统和应用程序认为连接还存在。 从而应用程序会进行“重传操作”。

          

     如果应用程序没有做处理，那么在重传结束前，一直会有问题。

         

     因此在开发能够快速容灾的网络组建时，应该记录每个连接上一秒钟发过去请求的数量，收到请求的数量，当该值低于一个设定的值时，就应该关闭连接，重新建立连接。

     如果连接可以建立，重新使用，不过不能建立，那么可以认为对端已经出问题。