1- 正如分配给PAR中每条消息的消息 ID 一样，“序列号”是一种在字节流传输中提供可靠性的方法。所以序列号被分配给每一个字节。

2-但并非所有字节都被确认，因为那太慢了。所以（根据Kozierok 的书） seq# 和 ack# 计划分别只是发送段的第一个字节的编号和接收段的最后一个字节的编号。（忽略此处的所有细微差别，例如累积/选择性确认等，因为它们与此处的问题无关）。

3-通过前三个数据包的交换，每一方的ISN都被宣布给对方并得到确认（谢谢Eddie）。但是，在第三次数据包交换中，当客户端确认接收到服务器的 ISN 时，seq# 和 ack# 都是 1。

4-这是我的两个问题：

问题 1：ISN（如 seq#）是一个 32 位的数字，即 4 个字节。那么为什么服务器返回的 ack# 不是 3（从 0 开始计数）而不是 1 在交换的第二个数据包中？同样，为什么第三个数据包中的 seq# 和 ack#, 3 而不是 1 都没有交换？这是设计协议的人强迫的例外*还是有其他原因？

现在，如果答案是这些初始增量被异常计为仅 1 个字节，那么它给我们带来了第二个问题：

问题 2：为什么我们在 seq# 和 ack# 增量中进行 ISN 交换？有人可能会说，除了更改 ack# 之外，我们没有其他方式来宣布确认，但 IMO 并非如此。服务器和客户端都可以只检查 SYN 和 ACK 标志来实现一切。

那么我错在哪里？如果有什么我理解错了，请告诉我。先感谢您。

* 在我检查过这是一个“异常”的任何地方都没有明确说明，但我发现这篇文章说：“ SYN、FIN 或 ZeroWindow 段算作 SEQs/ACKs 的 1 个字节。 ”。所以我个人对这条线的解释是我们正在谈论一个“例外”。