TCP 3次握手问题
因此，客户端通过向服务器发送带有 seq 的 SYN 数据包来启动 TCP 连接。 # X。然后服务器用 SYN+ACK 响应 X+1。当关闭连接协议生效时，FIN 数据包也是如此。
所以我的问题是为什么服务器会确认 X+1 而不仅仅是 X？我认为 SYN 和 FIN 数据包没有附带任何数据。难道还有其他原因吗？我很困惑为什么服务器会 ACK X+1 而不是 X。
So a client starts a TCP connection by sending a SYN packet to a server with seq. # X. The server then responds with a SYN+ACK for X+1. The same goes for a FIN packet when the close connection protocol is enacted.
So my question is why does the server ACK for X+1 instead of just X? I thought SYN and FIN packets didn't piggyback any data. Is there some other reason for this? I'm confused as to why the server will ACK X+1 instead of X.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正在发送的序列号是下一个预期的序列号。如果没有增加，则回复将表明数据包未被接受，请重新发送。这将以无限循环结束。
SYN 是一种特殊情况，它本身传输信息。 （它初始化目的地的接收计数。）ACK 将针对下一个预期字节 (SYN + 1)。
ACK 计数并不总是增加，并且可能增加超过 1。考虑此交换，其中数据包 2 被延迟并且乱序到达。
The sequence number being sent is the next expected sequence number. If it wasn't incremented, then the reply would indicate that the packet was not accepted, please resend. This would end in an infinite loop.
SYN is a special case that in and of itself transmits information. (It initializes the received count on the destination.) The ACK will be for the next expected byte (SYN + 1).
The ACK count does not always increase, and may increase by more than 1. Consider this exchange where packet 2 is delayed and arrives out of sequence.