在三次握手之后，我对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的数据包，为什么发送者想要另一个？
有人可以向我解释一下吗？
答案 0 :(得分：6)
好吧，在握手中，客户端只从服务器收到一个数据包：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
另一个编辑： 要真正了解正在发生的事情，您可能想要选择一个具有不同起始序列的示例（我已经写过它，服务器和客户端的序列是独立的）：
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
答案 1 :(得分：1)
确认号码（32位） - 如果设置了ACK标志，则该字段的值是接收器所期望的下一个序列号。这确认收到所有先前的字节（如果有的话）。 每端发送的第一个ACK确认另一端的初始序列号本身，但没有数据。
所以他们只是承认他们应该从哪里开始。