1
aganlengzi OP 额,是不是发错地方了,应该发到问与答去。。。。
|
2
wittyfox 2016-03-31 21:50:08 +08:00 via Android
什么叫协议,协议就是约定。
|
3
jimzhong 2016-03-31 21:53:22 +08:00
这是约定的
|
4
aganlengzi OP @wittyfox 这个约定在设计的时候是因为某种原因,我想知道这种原因
|
5
aganlengzi OP @jimzhong 为什么这么约定?感觉总归有原因的吧?
|
6
fantasticfears 2016-03-31 22:12:58 +08:00 1
@aganlengzi 另一端可以通过 stream 来确认状态,收到重复包就可以发现是丢包而重传;根据丢包的 ACK 号还可以知道是哪一段丢了。 SYN 和 FIN 跟 ACK 两码事
|
7
cevincheung 2016-03-31 22:13:02 +08:00
@aganlengzi
因为 XXXXX 中 YYY 的 BBB or 其他 balabala 。 你又要问,为什么 YYY 的 BBB 不能 XXXX 。 不必深究,鬼知道当时的什么小组或什么组织的是怎么想的。而且对外公布的只有结果,一般木有原因。 |
8
cevincheung 2016-03-31 22:13:40 +08:00
@aganlengzi 不懂协议的人路过……
|
9
BOYPT 2016-03-31 22:25:54 +08:00
行啊,你喜欢,只是你的就不叫 TCP 了,也没法和标准的 TCP 服务器客户端通信。
|
10
billlee 2016-03-31 22:27:00 +08:00
这个数字其实就是初始序列号 + 下一个 fragment 的地址偏移,根据对方就能确定流已经成功发送到哪里了
|
11
aganlengzi OP @BOYPT 讨论一下嘛。。。。
|
12
wy315700 2016-03-31 22:33:32 +08:00 via Android
@aganlengzi 十楼已经回答你了
ACK 不仅仅是 SYN 要用 中间传输也要用 |
13
aganlengzi OP @cevincheung 鹅鹅鹅
|
14
wind4 2016-04-01 00:14:56 +08:00
TCP 有重传机制,如果同时收到多个相同包,你能区分是重传还是确认吗?
|
15
pubby 2016-04-01 00:38:11 +08:00
不一定+1 ,丢包的话还会 ack 丢包前的位置
sack 参与的话又不一样了 |
16
hooluupog 2016-04-01 01:10:47 +08:00 2
SYN 和 FIN 是建立连接,握手阶段才使用。
ACK 为 1 表示这是一个确认帧。 ack 和 seq 是对应的帧序号,两者是对应的。 A 发送帧给 B , B 收到 A 发送的帧之后向 A 发送确认帧,编号为已正确收到的最后一帧的下一个帧(也就是期望收到的帧的编号)。所以 B 的 ack 等于 A 的 seq+1 。 |
17
gamexg 2016-04-01 07:46:12 +08:00 via Android 1
只是一个约定, ack 表示希望收到的下一个包数据的相对于流的位置。
主要是用来做超时重传用的,而且在超时重传时也比较符合逻辑,例如: 客户端发了 1 至 5 共 5 个包,但是 2 丢了。服务端在收到 3 时就会发现不符合预期,应该收到 2 的包结果收到了 3 ,这时就会发出 ack2 的包,表示希望收到 2 的数据。客户端在收到多次 ack2 的包就会启动快速重传重发服务端要求的 2 的数据。 而要是不加 1 ,那么就有些不符合逻辑了,明明收到了 3 ,却发出 1 的 ack 。 |
18
jimzhong 2016-04-01 08:20:38 +08:00
@aganlengzi 楼主如果去看计算机网络书籍里面的 GBN 和 SR 协议。可以发现他们的 ACK 是目前已经收到的 SeqNo 。而 TCP 的约定是 ACK 是下一个期待收到的 SeqNo.
|
19
caiyangjieto 2016-04-01 08:38:06 +08:00
因为 ACK 同时是对方下一次的序列号,所以得加一啊
|