2011-04-05 30 views
4

在3路握手之後,我對TCP數據包中的ACK和SEQ號碼感到困惑。我認爲ACK編號是下一個預期的SEQ編號。 所以,當我分析Wireshark的TCP連接,它說連接建立後,爲什麼在第一個TCP請求中ACK = 1而不是2?

TCP SYN with SEQ=0 
TCP SYN ACK with SEQ 0, ACK=1 (clear, server expects SEQ 1 in next packet) 
TCP ACK with SEQ 1, ACK=1 (clear, sender expects SEQ 1 in next packet) 

HTTP Request: TCP PSH ACK with SEQ 1, ACK=1 

最後一行還不清楚。我會說發件人預計接下來的SEQ = 2,所以它應該是ACK = 2?已經有一個來自服務器的SEQ = 1的數據包,爲什麼發件人需要另一個?

有人可以解釋這樣對我?

回答

6

那麼,在握手,客戶端從服務器接收僅一個分組:SEQ = 0和ACK = 1。有了這些信息,服務器就會告訴客戶'我正在等待一個SEQ = 1的數據包'。你有這個權利。

現在,在握手的最後部分,客戶端發送SEQ = 1和ACK = 1,基本上與服務器意思相同:'我正在等待您的數據包與SEQ = 1現在'

但是:一個TCP握手之後,客戶通常不會等待這個包要被確認,而是已經發送第一個數據包(事實上,數據可能已經被包含在握手的最後一個包中 - 我猜想在你的例子中就是這種情況,因爲HTTP請求與最後的握手包具有相同的SEQ)。所以任何下一個數據包都有ACK = 1。但爲什麼?它再次說'我正在等待你的一個包含SEQ = 1的數據包'。這完全有意義:客戶端從服務器收到的最後一個數據包有SEQ = 0(在握手中)。同時請記住,客戶端和服務器都有獨立的SEQ。這意味着客戶端可以發送100個數據包。只要服務器沒有發送一個,客戶端仍然會等待ACK = 1,因爲他從服務器帽子收到的最後一個數據包SEQ = 0

另一個編輯: 要真正理解發生了什麼,你可能想選擇不同的開始SEQs爲例(我已經寫了,服務器和客戶端的SEQs是獨立的):

Client -> SYN, SEQ=100 
Client <- SYN, ACK, SEQ=700, ACK=101 <- Server 
Client -> ACK = 701, SEQ=101 [50 Bytes of data] 
Client -> ACK = 701 [Again, didn't receive sth from server yet], SEQ = 151 
+0

爲什麼4號線使用序列1再次? – 2011-04-05 13:48:35

+0

通常情況下,如果它是一個新數據包,它應該不再是1。但我認爲HTTP請求實際上是握手的最後一個數據包。這在我的答案中有點不清楚,我會編輯它 – Chris 2011-04-05 13:54:27

+1

第4行使用SEQ 1,因爲ACK數據包不增加SEQ計數器,第3行只是一個ACK。 – cronor 2011-04-05 14:11:25

1

確認號(32位) - 如果ACK標誌設置,則該字段的值是接收器預期的下一個序列號。這確認收到所有先前的字節(如果有的話)。 各端發送的第一個ACK確認對方本身的初始序列號,但沒有數據

所以他們只是承認,他們應該開始。

TCP on Wikipedia

相關問題