2011-10-01 72 views
0

我已在服務器計算機上運行Wireshark的,我有這樣一個奇怪的傳輸:Wireshark的TCP Dup的ACK - 奇怪

客戶端(X:SRC端口65509)連接到我的服務器(Y:DST端口號爲9999)。

1)是正常的TCP握手

15:47:41.921228 XXX.XXX.XXX.XXX 65509 YYY.YYY.YYY.YYY 9999 65509 > distinct [SYN] Seq=0 Win=8688 Len=0 MSS=1460 WS=0 SACK_PERM=1 TSV=66344090 TSER=0 
15:47:41.921308 YYY.YYY.YYY.YYY 9999 XXX.XXX.XXX.XXX 65509 distinct > 65509 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1 TSV=69754693 TSER=66344090 
15:47:42.176823 XXX.XXX.XXX.XXX 65509 YYY.YYY.YYY.YYY 9999 65509 > distinct [ACK] Seq=1 Ack=1 Win=8688 Len=0 TSV=66344350 TSER=69754693 

2)服務器發送的加密密鑰到客戶端和客戶端的ACK接收它:

15:47:42.180755 YYY.YYY.YYY.YYY 9999 XXX.XXX.XXX.XXX 65509 distinct > 65509 [PSH, ACK] Seq=1 Ack=1 Win=65160 Len=24 TSV=69754719 TSER=66344350 
15:47:42.452606 XXX.XXX.XXX.XXX 65509 YYY.YYY.YYY.YYY 9999 65509 > distinct [ACK] Seq=1 Ack=25 Win=8664 Len=0 TSV=66344630 TSER=69754719 

3)突然面板重置爲一些連接原因

15:47:42.948618 XXX.XXX.XXX.XXX 65509 YYY.YYY.YYY.YYY 9999 65509 > distinct [RST] Seq=28 Win=0 Len=0 

4)但奇怪的是我去這裏。服務器發送TCP Dup ACK。這可能是什麼原因?我認爲這個消息只能在重新發送或者發送後才能發送。我從來沒有見過它會在RST後發送。

15:47:42.948654 YYY.YYY.YYY.YYY 9999 XXX.XXX.XXX.XXX 65509 [TCP Dup ACK 5856#1] distinct > 65509 [ACK] Seq=25 Ack=1 Win=65160 Len=0 TSV=69754796 TSER=66344630** 

5)客戶端再次發送RST。

15:47:43.227269 XXX.XXX.XXX.XXX 65509 YYY.YYY.YYY.YYY 9999 65509 > distinct [RST] Seq=1 Win=0 Len=0 

感謝您的任何建議。

+0

Stackoverflow用於與編程相關的問題(請參閱常見問題,http://stackoverflow.com/faq)。你的問題沒有給出任何有關編程的跡象。 –

+0

Sjoerd,你看過你正在鏈接的常見問題嗎? [cut] ...但如果你的問題一般涵蓋... *軟件工具常用的程序員 *事務是編程界專有的唯一的問題 ...那麼你是在正確的地方問你的問題! Wireshark是不是Wireshark是編程界所特有的一種工具或事物嗎? – kappa

+0

據我可以判斷你的問題不是關於Wireshark作爲程序員的工具,而是關於你使用Wireshark作爲診斷工具獲得的結果。從你的問題的句子看來,你的問題出現在客戶端和服務器之間的通信中。超級用戶或ServerFault站點似乎是這類問題更合適的站點。 –

回答

1

DUP-ACK從在步驟服務器(4)由SEQ 在步驟引起的(3):

 65509 > distinct [RST] Seq=28 Win=0 Len=0 

由於服務器期待SEQ#25,但接收到#28。在網絡中丟失seq 25〜27時會發生這種情況。 Dup-ACK通知客戶端在RST之前重新傳輸丟失的數據;然而,在步驟(5)中,我們看到客戶端響應服務器的重複確認,再次重置。因此,客戶端數據#25〜27永遠不會到達服務器,並且已經消失。

您可以通過在服務器和客戶端上執行數據包捕獲來驗證此情況。

有關詳細信息,請閱讀一些TCP重新傳輸文檔。

+0

非常感謝! – kappa