为什么连接建立后第一个 TCP 请求中 ACK = 1 而不是 2？
我对 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 的数据包，为什么发送者还想要另一个？
有人可以向我解释一下吗？
I'm confused about the ACK and SEQ numbers in TCP packets right after the 3-way-handshake. I thought the ACK number is the next expected SEQ number.
So when I analyse a TCP connection in Wireshark it says
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
The last line is unclear. I would say the sender expects SEQ=2 next, so it should be ACK=2? There was already a packet with SEQ=1 from the server, why does the sender want another one?
Can someone explain this to me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，在握手过程中，客户端仅从服务器收到一个数据包：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
另一种编辑：
为了真正理解发生了什么，你可能需要选择一个具有不同开头 SEQ 的示例（我已经写过，服务器和客户端的 SEQ 是独立的）：
Well, in the handshake the client receives only one packet from the server: SEQ=0 and ACK=1. With this information, the server tells the client 'I am waiting for a packet with SEQ=1 now'. You got this right.
Now, in the last part of the handshake the client sends a SEQ=1 and ACK=1, what basically means the same thing as from the server: 'I am waiting for your packet with SEQ=1 now'
But: After a TCP handshake, the client will usually not wait for this packet to be acked, but rather send the first data packets already (in fact, data may already be contained within the last packet of the handshake - I assume this is the case in your example, because the HTTP request has the same SEQ as the last handshake packet). So any next packet again has ACK=1. But why? It again says 'I am waiting for a packet with SEQ=1 from you'. And this completely makes sense: The last packet the client received from the server had SEQ=0 (in the handshake). Also keep in mind, that both client and server have independent SEQs. That means, that the client could send 100 packets. As long as the server did not send one, the client would still be waiting for ACK=1, because the last packet he received from the server hat SEQ=0
Another Edit:
To really understand what is going on, you might want to choose an example with different beginning SEQs (I already wrote it, SEQs of server and client are independent):
所以他们只是承认他们应该从哪里开始。
维基百科上的 TCP
So they just acknowledge where they should start from.
TCP on Wikipedia
你的问题的答案其实很简单。我可以看到您对三向握手过程的理解没有问题，我假设您已经知道客户端和服务器分别独立地计算序列号，但请注意：纯 ACK 数据包不会对序列号产生影响：
因此，第二个数据包 [SYN, ACK] 确实增加了序列号1，但第三个数据包[ACK]不影响Sequence Number，这就是下一个数据包仍然Seq=1的原因。
我将向您展示 SMTP 中的 TCP 连接示例来进一步说明：
您可以看到，连接建立后，客户端实际上连续发送了三个 Seq=1 的数据包！这是因为纯 ACK 数据包不会增加序列号，这是有道理的，因为您没有传输真实数据。
总之，在发送数据包后，序列号并不总是增加。根据经验，您只需查看 len 并检查 SYN FIN 标志即可确定是否应该增加序列号。
The answer to your question is actually quite simple. I can see that you have no problem understanding the three-way handshake procedure I'll assume that you already know client and server count the Sequence Number separately and independently, but please notice: a pure ACK packet does not contribute to Sequence Number:
Therefore, the second packet [SYN, ACK] does increase the Sequence Number by 1, but the third packet [ACK] does not affect the Sequence Number, which is the reason why next packet still has Seq=1.
I'll show you a sample TCP connection in SMTP to further illustrate it:
You can see that after the connection was made, the Client actually sent three consecutive packets with Seq=1! This is because the pure ACK packet does not increase the Sequence Number, which kind of makes sense because you're not transferring real data.
In a summary, the Sequence Number does not always increase after you sent off packets. As a rule of thumb, you just need to look at the len and check SYN FIN flags to determine whether the Sequence Number should be increased.