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)）。