为什么 TCP 的三向握手在确认时会改变序列号?

发布于 2024-11-25 22:31:58 字数 413 浏览 2 评论 0原文

为什么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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

寂寞笑我太脆弱 2024-12-02 22:31:58

这是因为当设置 ACK 标志时,ACK 字段意味着以下内容:

确认号(32 位)——如果设置了 ACK 标志,则该字段的值是接收方期望的下一个序列号。

如果未设置为(初始序列号+1),则表示同时确认SYNSYNACK)不一致> 标志必须在此数据包中设置)并表示它再次期待该序列号(即尚未收到它)。

That's because the ACK field means this when the ACK flag is set:

Acknowledgment number (32 bits) – if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting.

If it is not set to (inital sequence number+1), it would be inconsistently mean both ack'ing the SYN (both SYN and ACK flags must be set in this packet) and saying it is expecting that sequence number again (i.e. hasn't received it).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文