ACKs和SEQs的原理是什么？

Question

我不确定人们是否认为这很明显，但我有两个问题：

1. 在3次握手期间，为什么ACK = SEQ + 1，即为什么我要确认我从发送方期望的下一个字节？
2. 握手后，我的ACK = SEQ + len。为什么这与握手不同？为什么不像握手期间一样只确认我期望的下一个字节？

我知道我肯定错过了某个基本点。能否有人澄清一下？

- Legend

Answer 1

这是因为序列号空间的第一个字节对应于SYN标志，而不是数据字节。（在结尾处的FIN标志也会消耗一个序列号空间字节。）

- Matthew Slattery

Answer 2

在握手期间，您正在进行同步。序列号是已知的数据。一旦同步，数据长度也是已知的数据，同时也是有用的伪随机验证器。发送方知道他发送了多少数据，如果您回复，他会假设您已经收到了数据。这比使用数据的校验和或哈希值回复更容易，通常已经足够。

- No Refunds No Returns

---

我明白了，你想表达握手方面的观点。但是，为什么不直接回复ACK = SYN来表示“好的，我已经收到了你的SYN序列号”呢？我的第二个问题也涉及到同样的事情......我并不是在建议我们添加校验和或哈希......从你的回复中，似乎存在某种安全性概念，但我仍在努力弄清楚它的具体位置...... - Legend

不，这只是一个验证。一旦发送者/接收者同步，他们需要一种积极确认消息接收的方法。 AOK 是接收者获得与发送者发送的字节数相同的方式。对双方都了解的某些内容。这不是安全性问题。它更像是奇偶校验位，尽管这是不准确的类比。为什么要在协议中加入消息计数器？它没有增加价值，只有开销。 - No Refunds No Returns

Answer 3

SYN和FIN标志都会使流的序列号增加一。因此。

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

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

理论上，TWHS中的任何数据包都可能有有效载荷，但如果设置了SYN标志的任一数据包具有有效载荷，则对面需要同时确认数据和标志。

- jdizzle