为什么 TCP 中 ACK 确认是加 1？不加用原来的 SYN 号或者 FIN 号不行吗？为什么？

[aganlengzi]

不知道为什么。。。。

[aganlengzi]

额，是不是发错地方了，应该发到问与答去。。。。

[wittyfox]

什么叫协议，协议就是约定。

[jimzhong]

这是约定的

[aganlengzi]

@wittyfox 这个约定在设计的时候是因为某种原因，我想知道这种原因

[aganlengzi]

@jimzhong 为什么这么约定？感觉总归有原因的吧？

[fantasticfears]

@aganlengzi 另一端可以通过 stream 来确认状态，收到重复包就可以发现是丢包而重传；根据丢包的 ACK 号还可以知道是哪一段丢了。 SYN 和 FIN 跟 ACK 两码事

[cevincheung]

@aganlengzi

因为 XXXXX 中 YYY 的 BBB or 其他 balabala 。
你又要问，为什么 YYY 的 BBB 不能 XXXX 。

不必深究，鬼知道当时的什么小组或什么组织的是怎么想的。而且对外公布的只有结果，一般木有原因。

[cevincheung]

@aganlengzi 不懂协议的人路过……

[BOYPT]

行啊，你喜欢，只是你的就不叫 TCP 了，也没法和标准的 TCP 服务器客户端通信。

[billlee]

这个数字其实就是初始序列号 + 下一个 fragment 的地址偏移，根据对方就能确定流已经成功发送到哪里了

[aganlengzi]

@BOYPT 讨论一下嘛。。。。

[wy315700]

@aganlengzi 十楼已经回答你了
ACK 不仅仅是 SYN 要用 中间传输也要用

[aganlengzi]

@cevincheung 鹅鹅鹅

[wind4]

TCP 有重传机制，如果同时收到多个相同包，你能区分是重传还是确认吗？

[pubby]

不一定+1 ,丢包的话还会 ack 丢包前的位置
sack 参与的话又不一样了

[hooluupog]

SYN 和 FIN 是建立连接，握手阶段才使用。
ACK 为 1 表示这是一个确认帧。 ack 和 seq 是对应的帧序号，两者是对应的。 A 发送帧给 B ， B 收到 A 发送的帧之后向 A 发送确认帧，编号为已正确收到的最后一帧的下一个帧(也就是期望收到的帧的编号)。所以 B 的 ack 等于 A 的 seq+1 。

[gamexg]

只是一个约定， ack 表示希望收到的下一个包数据的相对于流的位置。
主要是用来做超时重传用的，而且在超时重传时也比较符合逻辑，例如：

客户端发了 1 至 5 共 5 个包，但是 2 丢了。服务端在收到 3 时就会发现不符合预期，应该收到 2 的包结果收到了 3 ，这时就会发出 ack2 的包，表示希望收到 2 的数据。客户端在收到多次 ack2 的包就会启动快速重传重发服务端要求的 2 的数据。

而要是不加 1 ，那么就有些不符合逻辑了，明明收到了 3 ，却发出 1 的 ack 。

[jimzhong]

@aganlengzi 楼主如果去看计算机网络书籍里面的 GBN 和 SR 协议。可以发现他们的 ACK 是目前已经收到的 SeqNo 。而 TCP 的约定是 ACK 是下一个期待收到的 SeqNo.

[caiyangjieto]

因为 ACK 同时是对方下一次的序列号，所以得加一啊