选择重传协议疑问

[n2l]

在选择重传协议中，如果发送接收窗口的尺寸都是 4 ，发送方发送的 0-3 号数据都被接收方正确接受，接收方也发送了 0-3 号确认分组，但是 2 号确认分组在传输过程中丢失了，只有 0 ，1 ，3 号确认分组正确被发送方收到，那后续的过程是怎样的？（不要 chatgpt 的答案，因为我试过，引申的疑问来自于 https://b23.tv/fRUMaRO 的 6 分钟左右，视频里说的是 2 号数据分组丢失，我的引申问题背景是 2 号确认分组丢失）

背景：采用 3 个比特给数据分组编号

[MarsCloud]

个人理解：按照协议，当接收者已经接受到 3 之前的所有数据，才可以发送 3 的确认分组，所以当发送者接受到了 3 号的确认分组信号，那么发送者就可以确认接收方已经接受到了 3 号以及之前的数据了；（所以 2 号丢失无所谓）
这也是累积确认的工作方式，为了避免接收方发送太多确认数据，可以累计多个，然后发送最后一个确认数据的序号，这样子可以简化确认的流程。
以上是个人从 TCP 的重传协议来理解。

[n2l]

@MarsCloud 但是视频里介绍的回退 N 帧才是累计确认的方式，选择重传是每收到一个数据分组就会发出一个确认分组。

[ruimz]

对于现代实际部署的 TCP 来说：
1. 如果后续收到了对于 4 的确认包，那么 2 号确认是否丢失不影响发送方的行为。即累计确认
2. 稍微影响一下 RTT 的估计

历史协议以及课本上的例子（ SW 、SR 、GBN ）的行为：由于他没说，也不知道具体实现，可以默认等同于 2 号丢失

[shalingye]

会导致发送端 2 号分组计时器超时，随后发送端以为 2 号分组丢失，尝试重传 2 号分组，接收端此时由于 2 号分组接收完毕，窗口下限大于 2 号，会丢弃第二次发来的 2 号分组并重传 2 号 ACK 。

[n2l]

@shalingye 靠谱，结帖。

[julyclyde]

为什么在 HTTP 里提问 retransmission 呢？

[n2l]

@julyclyde 好像系统自动改的，我记得我发帖的时候选的是问与答

[n2l]

@shalingye 以下是我的疑问，接收方正确接收 0-3 号数据分组后，接收窗口向后移动 4 个位置，接收窗口变为 4-7 ，当发送方计时器超时后，发送方重新发送 2 号数据分组，有没有可能是以下过程：接收方判断第二次收到的 2 号数据分组以前接收过，然后丢弃之，然后发送 2 号确认分组，发送方收到 2 号确认分组后，窗口向后滑动 4 个位置，变为 4-7 。

[shalingye]

@n2l 都是一个意思吧，只不过这次把编号写清楚了。

[shalingye]

@n2l xd 在考研吗，哈哈

[n2l]

@shalingye 非常感谢！

[n2l]

@shalingye 没，单纯想学

[shalingye]

@n2l 厉害👍