Networking ACKs和SEQs背后的基本原理？

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

在3路握手过程中，为什么ACK=SEQ+1，即为什么我要确认我期望从发送方得到的下一个字节

握手后，我的确认=SEQ+len。为什么这与握手不同？为什么不直接确认我期望的下一个字节（和握手时一样）

---

我知道我一定是在什么地方漏掉了一个基本点。有人能澄清一下吗？

在您正在同步的握手过程中。序列号是已知的数据。同步后，数据长度即为已知数据，也是一个有用的伪随机验证器。发件人知道他寄了多少，若你们回复，他会认为你们收到了。这比使用数据的校验和或散列进行回复更容易，通常就足够了。

这是因为序列号空间的第一个字节对应于SYN标志，而不是数据字节。（末尾的FIN标志本身也会占用一个字节的序列号空间。）

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

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

SYN（seq x）----->

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

---

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

我明白了。。。我想我理解你关于握手的观点。但是再一次，为什么不直接用ACK=SYN回答说“好的……我把你的SYN编号为这个”？第二，我的第二个问题涉及同样的事情。。。我不是真的建议我们添加校验和或散列。。。从你的回复来看，似乎在某个地方涉及到了安全性的概念，但我仍在试图找出哪里…不-这只是一个验证。一旦发送者/接收者进行了同步，他们需要一种方法来肯定地确认消息的接收。AOK是指接收方获得的字节数与发送方发送的字节数相同。双方都知道的事情。这不是安全问题。它更像是一个奇偶校验位，尽管这是一个不准确的类比。为什么要在协议上设置消息计数器？它没有增加任何价值，只是增加了开销。