TCP重传的次数

Question

在服务器崩溃的半打开连接（无FIN或RESET发送到客户端）的情况下，客户端尝试在此断开的连接上发送一些数据时，每个TCP段都将变为联合-ACKED。 TCP会在一些超时后尝试重传数据包。 TCP会在放弃之前尝试重传多少次以及在这种情况下会发生什么？它如何通知操作系统主机无法访问？ TCP RFC中规定了哪些内容？

Answer 1

如果服务器程序崩溃，内核将适当地清理所有打开的套接字。 （从TCP的角度来看是合适的;它可能会违反应用层协议，但应用程序应该为此事件做好准备。）

如果服务器内核崩溃并且不回来，重试的时间取决于如果套接字尚未进行或未连接：（从tcp(7)）

tcp_retries1 (integer; default: 3; since Linux 2.2) 
      The number of times TCP will attempt to 
      retransmit a packet on an established connection 
      normally, without the extra effort of getting 
      the network layers involved. Once we exceed 
      this number of retransmits, we first have the 
      network layer update the route if possible 
      before each new retransmit. The default is the 
      RFC specified minimum of 3. 

    tcp_retries2 (integer; default: 15; since Linux 2.2) 
      The maximum number of times a TCP packet is 
      retransmitted in established state before giving 
      up. The default value is 15, which corresponds 
      to a duration of approximately between 13 to 30 
      minutes, depending on the retransmission 
      timeout. The RFC 1122 specified minimum limit 
      of 100 seconds is typically deemed too short. 

如果服务器内核崩溃和不回来了，也不会知道任何的插座，并会那些后续数据包，使故障快得多。

如果任何一个单点故障路由器崩溃，如果他们足够快地恢复，连接可能会继续工作。这将要求防火墙和路由器是无状态的，或者如果它们是stateful，则具有允许预先存在的连接继续运行的规则集。 （可能不安全，不同的防火墙管理员对此有不同的策略。）

将故障返回到程序errno设置为ECONNRESET（至少对于send(2)）。