即使復位後RST標誌出現，TCP重傳仍然繼續

根據我對TCP重置（RST）標誌的理解，只要收到的段不適用於當前連接，就會導致當前TCP會話中止。但下面粘貼的wirehark捕獲似乎不遵循這個理論。基本上，啓動RESET的幀A（幀＃466）本身試圖通過相同的TCP會話重新傳輸TCP幀，並且還使用[RST，ACK]持續響應來自結尾B的任何後續新連接請求[SYN]行爲重複5次，3次握手只在第6次嘗試中成功（幀＃486）。即使復位後RST標誌出現，TCP重傳仍然繼續

464 04:35.1 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105    
465 04:35.2 enpc > 50000 [ACK] Seq=7454 Ack=31999 Win=32127 Len=0    
466 04:35.2 50000 > enpc [RST] Seq=31999 Win=0 Len=0     
467 04:35.4 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
468 04:36.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
469 04:37.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
470 04:40.3 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
471 04:45.9 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
472 04:57.1 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
473 05:17.1 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
474 05:17.1 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
475 05:17.5 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
476 05:17.5 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
477 05:18.0 fg-fps > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
478 05:18.0 50000 > fg-fps [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
479 05:19.5 [TCP Retransmission] 50000 > enpc [PSH, ACK] Seq=31894 Ack=7454 Win=5345 Len=105     
480 05:23.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
481 05:23.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
482 05:23.7 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
483 05:23.7 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
484 05:24.2 fg-gip > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1     
485 05:24.2 50000 > fg-gip [RST, ACK] Seq=1 Ack=1 Win=0 Len=0    
486 05:29.7 dyniplookup > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_PERM=1    
487 05:29.7 50000 > dyniplookup [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=2    
488 05:29.7 dyniplookup > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0    
489 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=105     
490 05:29.7 50000 > dyniplookup [ACK] Seq=1 Ack=106 Win=5840 Len=0    
491 05:29.7 dyniplookup > 50000 [PSH, ACK] Seq=106 Ack=1 Win=65536 Len=105

我的問題：

爲什麼A端不停地重發過，其中RST從它自身的結尾產生連接的包？

來源

2012-02-13 amit

也許最初發送ACK的發起者並不希望對另一個數據包（不同的序列號）進行ACK，所以它發送RST，然後以增長的時間間隔重新發送數據包，直到接收者發回正確的消息不，所以發起者一次又一次地發送RST）。看起來像通道中的問題，可能是電纜故障或接口模式不同（半雙工與全雙工等） – Alfabravo 2012-02-13 21:43:12

@Alfabravo：當連接移到CLOSED狀態時，爲什麼會嘗試重新傳輸數據包RST被髮送？ – amit 2012-02-14 09:33:13

RST並不意味着關閉。 RST的意思是「讓我們再試一次」。對於關閉連接，序列爲FIN->，<-ACK，<-FIN, ACK->。通常，RST的意思是「讓我們等待每一次新嘗試的隨機（增加）時間，這樣我們就可以避免碰撞和東西了」。 – Alfabravo 2012-02-14 14:17:44

可能發送RST的原因很多。 TCP段到達時使用復位標誌，該標誌不適用於當前打開的連接或偵聽端口。例如，如果TCP端口已關閉，系統上的TCP堆棧將以RST響應。

通常，當一個系統發送一個TCP重置時，它也會設置確認標誌，因爲它確認連接嘗試。在你的情況下，沒有ack標誌，根據RFC的（從內存）只有當沒有建立連接時纔會執行，在你的情況下，這對我來說意味着它是防火牆或似乎是中介設備（不是部分的TCP連接）發送重置。因此，服務器A將合法地認爲連接還活着。

幀467-472是標準TCP重傳行爲（來自系統A），連接嘗試之間的時間與服務器在幀472中的最後一次嘗試後最終看起來放棄的時間加倍。這些幀是幀464的重傳，其似乎表明幀465沒有被系統B接收到。我猜你在系統B上捕獲了數據？

我相信系統中的唯一轉移到封閉的框架473發出後，這將解釋爲什麼我們再看看從系統B.

開始從您的跟蹤的三次握手，這是很難說更不更多的網絡知識。

HTH！

來源

2012-05-10 13:59:49

即使復位後RST標誌出現，TCP重傳仍然繼續

回答

相關問題