什麼時間防止TCP窗口更新數據包丟失

Question

當TCP數據流的接收方關閉其接收窗口（或者，更確切地說，窗口被髮送方填充的窗口關閉）時，會出現一連串的數據包Wireshark將識別爲TCP ZeroWindow和TCP Keep-Alive（具有相同序列號的重複ACK）。一段時間後，接收器將發送新的ACK重新打開窗口（TCP Window Update），數據將再次開始流動。

什麼TCP定時器機制可確保在數據未開始流動時重新發送窗口更新數據包？

這裏是我在連接的端部看到的分組的序列（多個數據被預期）：在21點24分43秒

 
No.  Time   Source    Destination   Protocol Length Info 
122160 21:24:37.421824 192.168.15.121  72.21.81.253   TCP  60  41200 > http [ACK] Seq=462 Ack=2984241 Win=5152 Len=0 
122162 21:24:37.445528 72.21.81.253   192.168.15.121  TCP  1514 [TCP segment of a reassembled PDU] 
122163 21:24:37.445796 72.21.81.253   192.168.15.121  TCP  1514 [TCP segment of a reassembled PDU] 
122164 21:24:37.446087 72.21.81.253   192.168.15.121  TCP  1514 [TCP segment of a reassembled PDU] 
122171 21:24:37.481802 192.168.15.121  72.21.81.253   TCP  60  41200 > http [ACK] Seq=462 Ack=2988621 Win=784 Len=0 
122184 21:24:37.744838 72.21.81.253   192.168.15.121  TCP  838 [TCP Window Full] [TCP segment of a reassembled PDU] 
122185 21:24:37.745048 192.168.15.121  72.21.81.253   TCP  60  [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0 
122190 21:24:38.014841 72.21.81.253   192.168.15.121  TCP  60  [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0 
122191 21:24:38.014993 192.168.15.121  72.21.81.253   TCP  60  [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0 
122232 21:24:38.534437 72.21.81.253   192.168.15.121  TCP  60  [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0 
122233 21:24:38.534599 192.168.15.121  72.21.81.253   TCP  60  [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0 
122314 21:24:39.564525 72.21.81.253   192.168.15.121  TCP  60  [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0 
122315 21:24:39.564680 192.168.15.121  72.21.81.253   TCP  60  [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0 
122361 21:24:43.403052 192.168.15.121  72.21.81.253   TCP  60  [TCP Window Update] 41200 > http [ACK] Seq=462 Ack=2989405 Win=119904 Len=0 
122892 21:25:45.161896 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
122902 21:25:45.373289 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
122927 21:25:45.813267 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
122936 21:25:46.693275 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
122956 21:25:48.453337 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
123009 21:25:51.983392 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
123061 21:25:59.033566 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
123262 21:26:13.153852 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 
123460 21:26:41.394469 192.168.15.121  72.21.81.253   TCP  60  41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0 

接收機重新打開的窗口和聽到沒有更多來自發件人。一分鐘後，接收器超時連接（關閉由應用程序啓動），併發送一系列未確認的FIN-ACK。

它看起來像與發件人的通信簡單地丟失了（捕獲是在接收者的網絡上進行的）。如果沒有，那麼即使經過足夠長的時間以致對方忘記了連接，人們是否應該始終期待FIN-ACK的確認？

儘管RFC1122可能就此事發表了看法，但對於大型互聯網服務器來說，在這方面做一些不同的事情（通常的做法），或許是作爲反DoS措施？

Answer 1

正如您所說的，一旦接收窗口中有空間可用，接收器會發送一個新的窗口大小的ACK。

爲了處理ACK丟失的情況，發送者保留一個「持續定時器」，它偶爾會重新發送一個數據包（一個「窗口探測器」），以測試水域並查看是否存在確實沒有報道的接收空間。

持久計時器的值沒有明確規定，而是計算的往返時間和一些指數退避的函數。詳細信息請參見RFC1122的4.2.2.14部分，這裏：http://tools.ietf.org/html/rfc1122#page-92

提供的跟蹤看起來像是中間的東西阻塞了來自服務器的返回流量。我的猜測是你的NAT網關（192.168。。不是Internet上的有效地址，因此它們之間的某些事情正在進行網絡地址轉換）已經決定連接已經結束，並拒絕從服務器轉發額外的數據包。