连接建立后,为什么在第一个TCP请求中ACK = 1而不是2？

Question

在3次握手之后,我对TCP数据包中的ACK和SEQ数字感到困惑.我认为ACK编号是下一个预期的SEQ编号.因此,当我在Wireshark中分析TCP连接时,它说

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的数据包,为什么发送者想要另一个呢？

谁可以给我解释一下这个？

Answer 1

好吧,在握手中,客户端只从服务器接收一个数据包:SEQ = 0和ACK = 1.有了这些信息,服务器告诉客户端'我正在等待一个SEQ = 1 now的数据包'.你做对了.

现在,在握手的最后部分,客户端发送一个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