可靠数据传输 滑动窗口协议和选择重传协议

Posted 2022-12-14 milaiko

可靠数据传输（二） 滑动窗口协议和选择重传协议

GBN 回退N步协议（滑动窗口协议）

在回退N步协议中，允许发送方发送多个分组但也受限于在流水线中未确认的分组不能超过某个最大允许数N。

• send_base之前的是已发送并确认的分组
• send_base到nextseqnum是已发送但未确认的分组
• N是窗口的长度，那么[nextseqnum,send_base+N]是可以立即发送的分组。

FSM描述

GBN发送方的FSM描述

GBN发送方必须相应三种类型的事件

• 上层的调用。当上层调用rdt_send(data)时，发送方首先检查发送窗口是否已满，如果有N个已发送但是未确认的分组，就是指窗口已满
• 收到一个ACK。在GBN协议中，对序号n的分组采用累计确认的方式，也就是说当第n个分组的ACK发送过来时，就代表n之前的分组已经被接收方收到了，没必要再去等待n之前的分组。
• 超时事件。“回退N步”来源于出现丢失和时延过长分组时，发送方的行为。发送方使用一个计时器，当出现超时，就把所有已发送但未确认的分组重传。如果收到一个ACK，但是仍有已发送为确认的分组，定时器会重新启动，如果没有已发送但未确认的分组，那么停止计时器。
  

GBN接收方FSM描述

在GBN协议中，如果收到了失序的分组，接受方会丢弃掉所有失序的分组，虽然看起来有点愚蠢和浪费。要实现运输层的可靠传输，就必须要给上层有序的分组，也就是说数据必须按序交付。

如果分组n丢失，分组n+1却收到了，则分组n+1最终将在发送方根据GBN重传规则而被重传，接收方只要丢弃n+1分组即可。这种方法的有点就是接受缓存简单，接受方不需要缓存任何失序分组。当然缺点就是丢弃一个正确接受的分组的缺点是随后对该分组的重传也许这会丢失或出错，因此甚至需要更多的重传。

选择重传（SR）

从GBN协议可以了解到，当窗口长度和带宽时延积都很大时，单个分组出错就能够引起GBN重传大量分组。随着信道差错率的增加， 流水线可能会被这些不必要重传的分组给充斥。

SR协议通过让发送方仅重传那些它怀疑接受方没有收到的分组而避免了不必要的重传。

SR接受方将确认一个正确接受的分组，不管它是否按序。失序的分组将被缓存直到所有丢失分组全都收到为止，这时才可以把一批分组按序交付。

SR发送方的事件和动作。

• 从上层收到数据。如果序号位于发送方的窗口内，则将数据打包发送
• 超时。定时器再次用来防止丢失分组，然而，现在每个分组必须拥有自己的定时器，因为超时发生后只能发送一个分组。
• 收到ACK。如果收到ACK，倘若该分组序号在窗口内，则SR发送方序号在窗口内，则SR发送方将那个被确认的分组标记为已接收。如果该分组的序号等于send_base,则窗口基序号向前移动到具有最小序号的未确认分组处。

SR接收方的事件和动作。

• 序号在[rcv_base, rcv_base + N -1]内的分组被正确接收。如果该分组以前没收到过，则缓存该分组。如果该分组的序号等于接收窗口的基序号（上图的rcv_base），则该分组以及以前的缓存的序号连续的（起始于rcv_base）的分组交付给上层。
• 序号在[rcv_base- N, rcv_base-1]内的分组被正确收到。 这种情况下， 必须重新在发ACK，即使该分组是接收方以前已经确认的分组。
• 其他情况。 忽略分组。

实例解析：
分组2丢失，
发送方继续发送分组3、4、5，直到计时器超时，重新发分组2。

接收方由于分组2丢失，然而接收到分组3、4、5,所以把这些失序的分组缓存起来，但并不向上交付，直到分组2从发送方重新传了过来，将分组2、3、4、5都交付上层。