TCP_USER_TIMEOUT 的值低於 RTT

Question

考慮到TCP_USER_TIMEOUT 的描述:

當該值大於0時，它指定在TCP強制關閉對應連線並將ETIMEDOUT傳回給應用程式之前，傳輸的資料可以保持未確認狀態的最長時間（以毫秒為單位）。

和來自 RFC 的評論:

非常短的 USER TIMEOUT 值會影響高延遲路徑上的 TCP 傳輸。如果在未完成段的確認到達之前發生使用者逾時（可能是由於資料包遺失），則連線將關閉。許多 TCP 實作預設將 USER TIMEOUT 值設定為幾分鐘。儘管 UTO 選項允許建議短超時，但宣傳它們的應用程式應該考慮這些影響。

我預期 2 毫秒的 TCP_USER_TIMEOUT 會產生災難性後果：在 RTT 小於 2 毫秒的網路中，發送的每個 TCP 封包都會逾時等待 ACK，並且連線將關閉。但是，在我的環境中，我並沒有遇到這種情況。可以建立連線並且可以正常發送和接收資料。然而，我確實注意到，如果我拉下電源線或拉下接收接口，TCP_USER_TIMEOUT 確實會有效地檢測到連接丟失，並及時關閉連接。所以，TCP_USER_TIMEOUT 正在工作，只是不是按照我期望的方式工作。

我對 TCP_USER_TIMEOUT 有什麼誤解？為什麼低於 RTT 的值不會導致連線中斷？

如果它有幫助的話，我的客戶是一個帶有 2.6.32 核心的 Scientific Linux 6.1 機器。

Answer 1

Linux 中的 UTO 實作不準確，最近已透過此補丁集修復：（以防萬一您不是此補丁集的作者）： https://lkml.org/lkml/2018/7/18/1090

然而，即使在 UTO 觸發後，主機也會停止重傳並進入 TCP_CLOSE 狀態，但不會重設連線。應用程式有責任發送 RST。