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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3482 天前的主题，其中的信息可能已经有所发展或是发生改变。

不知道为什么。。。。

19 条回复 2016-04-01 08:38:06 +08:00

aganlengzi

2016-03-31 21:18:13 +08:00

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

wittyfox

2016-03-31 21:50:08 +08:00 via Android

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

jimzhong

2016-03-31 21:53:22 +08:00

这是约定的

aganlengzi

2016-03-31 22:06:15 +08:00

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

aganlengzi

2016-03-31 22:06:53 +08:00

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

fantasticfears

2016-03-31 22:12:58 +08:00

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

cevincheung nbsp;

2016-03-31 22:13:02 +08:00

@aganlengzi

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

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

cevincheung

2016-03-31 22:13:40 +08:00

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

BOYPT

2016-03-31 22:25:54 +08:00

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

billlee

2016-03-31 22:27:00 +08:00

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

aganlengzi

2016-03-31 22:30:13 +08:00

@BOYPT 讨论一下嘛。。。。

wy315700

2016-03-31 22:33:32 +08:00 via Android

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

aganlengzi

2016-03-31 22:33:48 +08:00

@cevincheung 鹅鹅鹅

wind4

2016-04-01 00:14:56 +08:00

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

pubby

2016-04-01 00:38:11 +08:00

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

hooluupog

2016-04-01 01:10:47 +08:00

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

gamexg

2016-04-01 07:46:12 +08:00 via Android

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

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

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

jimzhong

2016-04-01 08:20:38 +08:00

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

caiyangjieto

2016-04-01 08:38:06 +08:00

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