ACK 和 SEQ 背后的基本原理?

发布于 2024-08-23 22:43:12 字数 214 浏览 3 评论 0原文

我不确定人们是否认为这是显而易见的,但我有两个问题:

  1. 在3次握手期间,为什么ACK = SEQ + 1,即为什么我要确认我期望从发送方收到的下一个字节?
  2. 握手之后,我的ACK = SEQ + len。为什么这与握手不同?为什么不直接确认我期待的下一个字节(与握手期间相同)?

我知道我一定在某个地方错过了一个基本点。有人可以澄清这一点吗?

I am not sure if people find this obvious but I have two questions:

  1. During the 3-way handshake, why is ACK = SEQ + 1 i.e. why am I ACKing for the next byte that I am expecting from the sender?
  2. After the handshake, my ACK = SEQ + len. Why is this different from the handshake? Why not just ACK for the next byte I am expecting as well (the same as during the handshake)?

I know I must've missed out a basic point somewhere. Can someone clarify this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(3

只怪假的太真实 2024-08-30 22:43:12

这是因为序列号空间的第一个字节对应于 SYN 标志,而不是数据字节。 (末尾的 FIN 标志本身也消耗一个字节的序列号空间。)

This is because the first byte of sequence number space corresponds to the SYN flag, not to a data byte. (The FIN flag at the end also consumes a byte of sequence number space itself.)

故事与诗 2024-08-30 22:43:12

在握手期间,您正在同步。序列号是已知数据。同步后,数据长度就是已知数据,也是有用的伪随机验证器。发件人知道他发送了多少,如果您回复,他就认为您收到了。这比用数据的校验和或哈希值进行回复更容易,并且通常就足够了。

During the handshake you're synchronizing. The sequence number is the known data. Once you've synced, the data length is the known data as well as a useful pseudo-random verifier. Sender knows how much he sent and if you reply, he assumes you got it. This is easier than reply with, say a checksum or hash of the data, and is usually sufficient.

愿得七秒忆 2024-08-30 22:43:12

SYN 和 FIN 标志都会导致流的序列号加 1。这

SYN (seq x) -------------->
                           <--- SYNACK (ack x+1, seq y)
ACK (seq x+1, ack y+1) --->

就是你的三次握手。这样做是因为 SYN 和 FIN 需要确认接收。这样,每个人都可以在连接的生命周期内处于同一页面上。

理论上,TWHS 中的任何数据包都可以具有有效负载,但如果设置了 SYN 标志的任何一个数据包具有有效负载,则对方需要确认数据和标志。

Both the SYN and FIN flags cause the sequence number of the stream to increment by one. Thus

SYN (seq x) -------------->
                           <--- SYNACK (ack x+1, seq y)
ACK (seq x+1, ack y+1) --->

Is your three way handshake. It's done that way because SYNs and FINs require acknowledgement of receipt. That way everyone can be on the same page during the lifetime of the connection.

Theoretically any packet in part of the TWHS could have payload, but if either of the packets with the SYN flag set have payload, the opposite side needs to acknowledge both data AND the flag.

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