为什么 TCP 的三向握手在确认时会改变序列号？
为什么TCP 三向握手在初始确认期间会碰撞序列号握手？这比只让确认号等于序列号更好吗？
连接建立后，
Client sends SYN,A
Server responds with SYN-ACK,A+1,B
Client confirms with ACK,B+1
How is that better than
Client sends SYN,A
Server responds with SYN-ACK,A,B
Client confirms with ACK,B
Why does the TCP three-way handshake bump the sequence number when acking during the initial handshake? How is that better than just leaving the acknowledgement number equal to the sequence number?
The connection is established with
Client sends SYN,A
Server responds with SYN-ACK,A+1,B
Client confirms with ACK,B+1
How is that better than
Client sends SYN,A
Server responds with SYN-ACK,A,B
Client confirms with ACK,B
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是因为当设置
ACK标志时，ACK字段意味着以下内容：如果未设置为（初始序列号+1），则表示同时确认
SYN（SYN和ACK）不一致> 标志必须在此数据包中设置）并表示它再次期待该序列号（即尚未收到它）。That's because the
ACKfield means this when theACKflag is set:If it is not set to (inital sequence number+1), it would be inconsistently mean both ack'ing the
SYN(bothSYNandACKflags must be set in this packet) and saying it is expecting that sequence number again (i.e. hasn't received it).