哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议

在上一节中我们逐步分析了可靠传输协议的设计过程,最后讲到rdt3.0的设计和实现机制。但是rdt3.0为了实现可靠性,牺牲了很大一部分性能,其中最主要的原因就在于停止等待协议,在发送完数据后,发送端需要等待至少RTT后才能收到ACK,期间什么都不能做。

因此,我们需要设计方案来解决这个问题,这就是本节所讲述的内容。

流水线机制:提高资源利用率

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第1张图片

在之前的停止等待协议中,发送端每发送一个数据包,都会等待至少RTT的时间。现在采用流水线机制,每一次发送端多发送几个数据包,比如上图中的发送3个数据包。即每次发送端发完3个数据包后,再执行停止等待协议,此时的发送方利用率(发送方发送时间百分比)就相当于原先的3倍。

流水线协议

现在利用流水线机制,允许发送方在发送完数据包后,不用立即停止等待,而是可以在发送多个数据包后,再执行停止等待协议,等待每个数据包的ACK反馈。

允许发送方在收到ACK之前连续发送多个分组

  • 需要更大的序列号范围,只有原先的0和1显然是不够了
  • 发送方和/或接收方需要更大的存储空间以缓存分组。原来的接收方只需要一个分组的存储空间,但是现在需要多个分组的缓存空间。

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第2张图片

左边就是只有一个数据包发送的过程。右图就是流水线机制下,多个数据包的发送和接收。

滑动窗口协议

窗口:用来管理那些发送端已经发出,但还未来得及确认的数据包。

  • 允许使用的序列号范围(每个数据包都对于一个序列号,因此滑动窗口中是已发送的数据包,也就表示使用的序列号范围)
  • 窗口尺寸为N:最多有N个等待确认的消息。N也表示发送端一次允许发送的最大数据包个数。

滑动窗口:随着协议的运行,窗口在序列号空间内向前滑动

滑动窗口协议:GBN、SR

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第3张图片

如上图所示,窗口左边表示的是已经发送,且已经得到ACK确认的数据分组。 黄色部分表示已经发送,带还没确认的数据分组。蓝色则表示还可以使用的序列号范围(最大为N,蓝色表示接下来发送可以使用的序列号范围)。当蓝色部分用完后,就必须等待窗口内的数据包得到ACK确认后,窗口继续右移,来发送加下来的序列号数据包。

接下来,我们分别对GBN和SR两种滑动窗口协议进行介绍,介绍其实现原理和区别,便于我们理解滑动窗口协议的改进。

滑动窗口协议:Go-Back-N协议(GBN)

发送方

  • 分组头部包含k-bit序列号
  • 窗口尺寸为N,最多允许N个分组未确认。

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第4张图片

如上所述,窗口左边的绿色部分表示已经获得ACK确认的数据分组。黄色的表示已经发送,但未ACK确认的分组,蓝色部分表示继续发送分组可使用的序列号范围,比如此时如果需要再发送一个数据分组,使用的序列号就是图中nextseqnum对于的序列号值。最右边的白色是还不能使用的序列号,需要等待窗口滑动右移才能到达。

累计确认机制

对于GBN协议来说,发送端对于ACK的确认采用的是累计确认的方式。

  • ACK(n):表示确认到序列号n(包含n)的分组均已被正确接收。即n-1、n-2,…往前的分组都已经被正确接收了。
  • 为传输中的分组设置计数器(timer)
  • 超时(timeout)时间:重传序列号大于等于n,还未收到ACK的所有分组。

GBN发送方的有限状态机示例如下图所示:

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第5张图片

  • if(nextseqnum < base+N)表示如果下一个序列号小于窗口的最大范围,说明还可以继续发送数据包,则取nextseqnum的序列号来构造数据包并发送。同时,如果在窗口的最左侧时,启动当前窗口内流水线发送数据包的定时器。可以看到,整个窗口内发送数据包时,只会有一个定时器。
  • refuse_data:如果窗口内的序列号已经用光了,也就是发送的数据包序列号达到了窗口的最大值。此时,发送方再需要发送数据包时,会被拒绝refuse。
  • timeout如果触发了timeout超时,则会从窗口最左侧的数据包开始,逐个重发,知道窗口最右端。
  • rdt_rcg && notcorrupt由于是累计确认,在收到ACK(n)后,表示认到序列号n(包含n)的分组均已被正确接收,此时起始偏移base会更新为所收到的确认号ACK(n)的值+1(n+1)。这里,也就是窗口滑动的原理过程了。

GBN接收方的有限状态机示例如下图所示:

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第6张图片

ACK机制:发送拥有最高序列号的、已被正确接收的分组的ACK(累计重传机制)

  • 可能产生重复ACK
  • 只需要记住唯一的expectedseqnum。因为流水线机制可能会使到达接收方的数据包序列号乱序,此时接收方只需记住期待接收的最大序列号即可,比如期待序列号为5,此时收到了一个序列号为7的数据包,此时GBN会直接丢弃掉这些已经收到的但不是当前期望的分组序号。丢弃完后,还是需要做ACK的,所以重新确认序列号最大的按序到达的分组。比如上述例子的,收到序列号7,期望5,应该确认的是序列号4,因为5之前的都已经收到了。

乱序到达的分组:

  • 直接丢弃—>接收方没有缓存
  • 重新确认序列号最大的、按序到达的分组

GBN示例

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第7张图片

假定窗口的大小是4,所以在发送方可以发送pkt0、pkt1、pkt2、pkt3,发送完pkt3后达到了窗口的最大序列号,因此发送端开始停止等待ACK反馈。

前两个pkt0、pkt1都正确到达了分组,pkt2在发送过程中丢失了,而pkt3也正确到达了接收端。在接收端接收到pkt0、pkt1之后,接收端期望的序列号expectedseqnum应该为2,而此时pkt3分组到达了接收端,但不是接收端期望的序列号。按照上面的分析我们知道,此时接收端会丢弃序列号3对应的分组,然后发送一个ACK1的返回(因为期望序列号是2,所以发送ACK1表示序列号2前面的数据分组都收到了)。

但是这个ACK1在返回时也不幸丢失了。由于pkt1的分组和该分组的ACK1的反馈被成功接收到了,此时发送端的窗口就可以向右移动两位,有了序列号来发送pkt4、pkt5。

在发送完pkt4、pkt5之后,由于pkt2的ACK一直没有收到,所以发送端触发了timeout超时,又由于上一次接收到的最大ACK确认序列号为1,即序列号为1和1之前的都已经确认了,所以发送方会重发序列号为1之后的分组,即上图中的pkt2、pkt3、pkt4、pkt5。对于接收方收到的重复分组,会根据序列号进行去重,所以不怕分组重复。

练习题: 数据链路层采用后退N帧(GBN)协议,发送方已经发送了编号为0~7的帧。当计时器超时时,若发送方只收到0,2,3号帧的确认,则发送方下需要重发的帧数是多少?分别是哪几个帧?

解: 根据GBN协议工作原理,GBN协议的确认是累计确认,由于发送端已经得到的最大ACK确认序列号为3,表示序列号3和之前的分组都已经确认(即使ACK1的确认序列号可能在反馈途中丢失了)。因此,发送方需要重新下发的帧数是4个,依次分别是4、5、6、7号帧。

滑动窗口协议:Selective Repeat协议(SR)

GBN有什么缺陷?

通过上面的介绍也能发现,GBN一个比较明显的缺陷就是,当需要重传时,可能一次会重传很多个分组,比如当某个序列号n的分组丢失时,发送端会重传序列号n和n之后到窗口右侧最大序列号之间的数据分组。 这会导致网络中充斥着很多这些不必要的重复分组,造成网络拥塞,性能变差。所以一个显然的改进就是,我们不使用累计确认机制,而是对每个分组单个确认,同时不丢弃那些乱序的分组,接收端缓存起来。

SR协议

接收方

  • 接收方对每个分组单独进行确认。只要这个分组到达,就会返回一个ACK确认。这点跟GBN的不同在于,GBN的确认是累计确认,在确认时会有一个期望序列号expectedseqnum,对于接收端接收到的分组序号不是期望序号的,是直接丢弃不返回ACK的。只有在是期望序号时,才返回对应序号的ACK,并便是这个序号之前的分组都正确收到了,这是上面GBN采用的ACK累计确认机制。
  • 接收方设置缓存机制,缓存乱序到达的分组。 因为现在分组是乱序到达的,还不是一个完整的数据报文,所以不能直接向上交付,需要先缓存起来。
  • 接收方也有一个窗口

发送方

  • 发送方只重传那些没收到ACK的分组。
  • 发送方为每个分组设置单独的定时器。
  • 发送窗口:包含N个连续的序列号,限制已发送且未确认的分组。

SR协议中发送方和接收方的窗口如下所示:

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第8张图片

图(b)表示的是接收方的窗口。接收方的窗口大小也是N,窗口前面是那些已经按序到达成功交付的数据分组。窗口里的灰色部分表示接收方期望收到的,但是还没收到的分组序号。红色的则表示那些乱序到达的分组,这些乱序到达的分组,此时接收方会缓存起来,并返回ACK。蓝色的部分表示接收方可以接收的序列号范围。

从上两个图可以发现,在SR协议中,发送方和接收方的窗口不是同步的,发送方的窗口可能是滞后于接收端的(因为可能某些已发送的分组还没收到ACK)。

SR协议的整体逻辑如下所示:
哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第9张图片

  • 对于发送方来说,如果窗口内收到了序列号为N的ACK,且该序列号是窗口中最小序列号的还没被ACK确认的序列号,则此时该分组确认后,窗口会向右滑动到下一个还没确认ACK的序列号最小的分组位置。
  • 对于接收方来说,如果接收到的分组序列号是在接收窗口序列号范围内的,会对该分组返回ACK,如果这个分组是乱序到达的,则缓存起来。如果是按序到达的,则跟其它按序到达的分组拼接起来,并且如果这个分组序号是接收端窗口中的未接收的最小序号,则窗口向右移动到下一个还未接收的最小序号位置。
  • 如果接收端接收到的分组序号不在接收端窗口范围内,同样要发送ACK。因为这种情况可能是之前返回的ACK丢失了,发送端触发了超时操作重传了分组,因此这种情况仍然要重新发ACK。

SR协议示例

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第10张图片

  1. 上图中,发送方连续发送pkt0~pkt3的数据分组,首先接收方接收接收到pkt0,向上层交付,并返回ACK0,同时窗口右移。pkt1同理。但是pkt2在发送过程中丢失了,接收方接收端乱序到达的pkt3。因此SR协议的独立确认机制,此时接收方会返回对pkt3的确认ACK。
  2. 当发送方收到pkt0、pkt1的确认ACK后,同样的,窗口会右移,继续发送数据pkt4、pkt5。由于pkt2的ACK一直没有返回,因此发送方的窗口最左侧移动到序号2的位置就不动了。
  3. 在这个过程中,接收方会接收到发送方窗口右移后的pkt4、pkt5的数据分组,由于SR协议有缓存机制,因此会对乱序到达的分组缓存起来,并返回对应序号的确认ACK。但此时,由于窗口中序列号最小的pkt2还未接收到,所以接收端窗口不会右移。
  4. 终于,发送端pkt2分组的定时器超时了,触发重传。
  5. 等到pkt2到达接收端后,由于这个序号是窗口内最小未到达的序号,并且其他序号的分组都已经收到了,此时接收方会将窗口内的分组一起交付给上层。同时窗口会右移到下一个未接收的最小序列号的位置,也就是pkt6的位置,如上右图最下边所示。
  6. 对于发送端来说,第二次对于pkt2分组的确认ACK被正确收到了,那么窗口也会右移到下一个最小未确认ACK的序号所在的位置,也就是pkt6的位置。

SR困境

哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议_第11张图片

上图给出了a、b两种场景,图中窗口大小是3,序列号只包括0、1、2、3四个序列号,循环使用。思考接收方能区分开上面两种不同的场景吗?

  • 在(a)场景中,接收方对pkt0、1、2的ACK都丢失了,在超时后,发送端会重发pkt0
  • 在(b)场景中,接收方在收到ack0、1确认后,窗口右移,并继续发送后面的pkt3、pkt0,而这时pkt3的分组丢失了。
  • 两种场景的共性在于,接收端的窗口位置一样,而且在某一时刻,接收端都接收到了一个pkt0的分组。

那么,在(a)场景中发送方重发分组0,接收方收到后会如何处理?

从上帝视角我们直到,这两种场景是不一样的,(a)场景中的pkt0是重传,而(b)场景下的分组是正常的数据分组。但是接收端并不能区分这两种场景,就有可能导致错误。比如在(a)场景下,接收端可能以为这次收到的pkt0是正常的数据分组进行了接收,并按序向上交付。但此时,这个分组并不是正确按序到达的分组,就会导致上层数据解析错误。

之所以会导致上述的问题,显而易见,是由于我们的序号太少,而窗口尺寸相对序号又比较大。因此在SR协议中,需要考虑序号个数与窗口大小之间的关系。

序列号个数与窗口尺寸需满足什么关系?

Ns+Nr <= 2k

上式中k表示序列号的位数,Ns表示发送方窗口尺寸,Nr表示接收方窗口尺寸。

你可能感兴趣的:(计算机网络,计算机网络,网络,服务器)