在选择重传协议中,如果发送接收窗口的尺寸都是 4 ,发送方发送的 0-3 号数据都被接收方正确接受,接收方也发送了 0-3 号确认分组,但是 2 号确认分组在传输过程中丢失了,只有 0 ,1 ,3 号确认分组正确被发送方收到,那后续的过程是怎样的?(不要 chatgpt 的答案,因为我试过,引申的疑问来自于 https://b23.tv/fRUMaRO 的 6 分钟左右,视频里说的是 2 号数据分组丢失,我的引申问题背景是 2 号确认分组丢失)
1
MarsCloud 2023-09-29 18:54:54 +08:00
个人理解:按照协议,当接收者已经接受到 3 之前的所有数据,才可以发送 3 的确认分组,所以当发送者接受到了 3 号的确认分组信号,那么发送者就可以确认接收方已经接受到了 3 号以及之前的数据了;(所以 2 号丢失无所谓)
这也是累积确认的工作方式,为了避免接收方发送太多确认数据,可以累计多个,然后发送最后一个确认数据的序号,这样子可以简化确认的流程。 以上是个人从 TCP 的重传协议来理解。 |
2
n2l OP @MarsCloud 但是视频里介绍的回退 N 帧才是累计确认的方式,选择重传是每收到一个数据分组就会发出一个确认分组。
|
3
ruimz 2023-09-29 21:48:32 +08:00 via iPhone
对于现代实际部署的 TCP 来说:
1. 如果后续收到了对于 4 的确认包,那么 2 号确认是否丢失不影响发送方的行为。即累计确认 2. 稍微影响一下 RTT 的估计 历史协议以及课本上的例子( SW 、SR 、GBN )的行为:由于他没说,也不知道具体实现,可以默认等同于 2 号丢失 |
4
shalingye 2023-09-30 00:35:19 +08:00 via Android 2
会导致发送端 2 号分组计时器超时,随后发送端以为 2 号分组丢失,尝试重传 2 号分组,接收端此时由于 2 号分组接收完毕,窗口下限大于 2 号,会丢弃第二次发来的 2 号分组并重传 2 号 ACK 。
|
6
julyclyde 2023-09-30 16:42:47 +08:00
为什么在 HTTP 里提问 retransmission 呢?
|