哈工大计算机网络传输层详解之：流水线机制与滑动窗口协议
哈工大计算机网络传输层详解之：流水线机制与滑动窗口协议
在上一节中我们逐步分析了可靠传输协议的设计过程，最后讲到rdt3.0的设计和实现机制。但是rdt3.0为了实现可靠性，牺牲了很大一部分性能，其中最主要的原因就在于停止等待协议，在发送完数据后，发送端需要等待至少RTT后才能收到ACK，期间什么都不能做。
因此，我们需要设计方案来解决这个问题，这就是本节所讲述的内容。
流水线机制：提高资源利用率
在之前的停止等待协议中，发送端每发送一个数据包，都会等待至少RTT的时间。现在采用流水线机制，每一次发送端多发送几个数据包，比如上图中的发送3个数据包。即每次发送端发完3个数据包后，再执行停止等待协议，此时的发送方利用率（发送方发送时间百分比）就相当于原先的3倍。
流水线协议
现在利用流水线机制，允许发送方在发送完数据包后，不用立即停止等待，而是可以在发送多个数据包后，再执行停止等待协议，等待每个数据包的ACK反馈。
允许发送方在收到ACK之前连续发送多个分组
- 需要更大的序列号范围，只有原先的0和1显然是不够了
- 发送方和/或接收方需要更大的存储空间以缓存分组。原来的接收方只需要一个分组的存储空间，但是现在需要多个分组的缓存空间。
左边就是只有一个数据包发送的过程。右图就是流水线机制下，多个数据包的发送和接收。
滑动窗口协议
窗口：用来管理那些发送端已经发出，但还未来得及确认的数据包。
- 允许使用的序列号范围（每个数据包都对于一个序列号，因此滑动窗口中是已发送的数据包，也就表示使用的序列号范围）
- 窗口尺寸为N：最多有N个等待确认的消息。N也表示发送端一次允许发送的最大数据包个数。
滑动窗口：随着协议的运行，窗口在序列号空间内向前滑动
滑动窗口协议：GBN、SR
如上图所示，窗口左边表示的是已经发送，且已经得到ACK确认的数据分组。 黄色部分表示已经发送，带还没确认的数据分组。蓝色则表示还可以使用的序列号范围（最大为N，蓝色表示接下来发送可以使用的序列号范围）。当蓝色部分用完后，就必须等待窗口内的数据包得到ACK确认后，窗口继续右移，来发送加下来的序列号数据包。
接下来，我们分别对GBN和SR两种滑动窗口协议进行介绍，介绍其实现原理和区别，便于我们理解滑动窗口协议的改进。
滑动窗口协议：Go-Back-N协议（GBN）
发送方
- 分组头部包含k-bit序列号
- 窗口尺寸为N，最多允许N个分组未确认。
如上所述，窗口左边的绿色部分表示已经获得ACK确认的数据分组。黄色的表示已经发送，但未ACK确认的分组，蓝色部分表示继续发送分组可使用的序列号范围，比如此时如果需要再发送一个数据分组，使用的序列号就是图中nextseqnum对于的序列号值。最右边的白色是还不能使用的序列号，需要等待窗口滑动右移才能到达。
累计确认机制
对于GBN协议来说，发送端对于ACK的确认采用的是累计确认的方式。
- ACK（n）：表示确认到序列号n（包含n）的分组均已被正确接收。即n-1、n-2,…往前的分组都已经被正确接收了。
- 为传输中的分组设置计数器（timer）
- 超时(timeout)时间：重传序列号大于等于n，还未收到ACK的所有分组。
GBN发送方的有限状态机示例如下图所示：
if(nextseqnum < base+N)表示如果下一个序列号小于窗口的最大范围，说明还可以继续发送数据包，则取nextseqnum的序列号来构造数据包并发送。同时，如果在窗口的最左侧时，启动当前窗口内流水线发送数据包的定时器。可以看到，整个窗口内发送数据包时，只会有一个定时器。refuse_data：如果窗口内的序列号已经用光了，也就是发送的数据包序列号达到了窗口的最大值。此时，发送方再需要发送数据包时，会被拒绝refuse。timeout：如果触发了timeout超时，则会从窗口最左侧的数据包开始，逐个重发，知道窗口最右端。rdt_rcg && notcorrupt：由于是累计确认，在收到ACK（n）后，表示认到序列号n（包含n）的分组均已被正确接收，此时起始偏移base会更新为所收到的确认号ACK(n)的值+1（n+1）。这里，也就是窗口滑动的原理过程了。
GBN接收方的有限状态机示例如下图所示：
ACK机制：发送拥有最高序列号的、已被正确接收的分组的ACK（累计重传机制）
- 可能产生重复ACK
- 只需要记住唯一的expectedseqnum。因为流水线机制可能会使到达接收方的数据包序列号乱序，此时接收方只需记住期待接收的最大序列号即可，比如期待序列号为5，此时收到了一个序列号为7的数据包，此时GBN会直接丢弃掉这些已经收到的但不是当前期望的分组序号。丢弃完后，还是需要做ACK的，所以重新确认序列号最大的按序到达的分组。比如上述例子的，收到序列号7，期望5，应该确认的是序列号4，因为5之前的都已经收到了。
乱序到达的分组：
- 直接丢弃—>接收方没有缓存
- 重新确认序列号最大的、按序到达的分组
GBN示例
假定窗口的大小是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协议中发送方和接收方的窗口如下所示：
图（b）表示的是接收方的窗口。接收方的窗口大小也是N，窗口前面是那些已经按序到达成功交付的数据分组。窗口里的灰色部分表示接收方期望收到的，但是还没收到的分组序号。红色的则表示那些乱序到达的分组，这些乱序到达的分组，此时接收方会缓存起来，并返回ACK。蓝色的部分表示接收方可以接收的序列号范围。
从上两个图可以发现，在SR协议中，发送方和接收方的窗口不是同步的，发送方的窗口可能是滞后于接收端的（因为可能某些已发送的分组还没收到ACK）。
SR协议的整体逻辑如下所示：
- 对于发送方来说，如果窗口内收到了序列号为N的ACK，且该序列号是窗口中最小序列号的还没被ACK确认的序列号，则此时该分组确认后，窗口会向右滑动到下一个还没确认ACK的序列号最小的分组位置。
- 对于接收方来说，如果接收到的分组序列号是在接收窗口序列号范围内的，会对该分组返回ACK，如果这个分组是乱序到达的，则缓存起来。如果是按序到达的，则跟其它按序到达的分组拼接起来，并且如果这个分组序号是接收端窗口中的未接收的最小序号，则窗口向右移动到下一个还未接收的最小序号位置。
- 如果接收端接收到的分组序号不在接收端窗口范围内，同样要发送ACK。因为这种情况可能是之前返回的ACK丢失了，发送端触发了超时操作重传了分组，因此这种情况仍然要重新发ACK。
SR协议示例
- 上图中，发送方连续发送pkt0~pkt3的数据分组，首先接收方接收接收到pkt0，向上层交付，并返回ACK0，同时窗口右移。pkt1同理。但是pkt2在发送过程中丢失了，接收方接收端乱序到达的pkt3。因此SR协议的独立确认机制，此时接收方会返回对pkt3的确认ACK。
- 当发送方收到pkt0、pkt1的确认ACK后，同样的，窗口会右移，继续发送数据pkt4、pkt5。由于pkt2的ACK一直没有返回，因此发送方的窗口最左侧移动到序号2的位置就不动了。
- 在这个过程中，接收方会接收到发送方窗口右移后的pkt4、pkt5的数据分组，由于SR协议有缓存机制，因此会对乱序到达的分组缓存起来，并返回对应序号的确认ACK。但此时，由于窗口中序列号最小的pkt2还未接收到，所以接收端窗口不会右移。
- 终于，发送端pkt2分组的定时器超时了，触发重传。
- 等到pkt2到达接收端后，由于这个序号是窗口内最小未到达的序号，并且其他序号的分组都已经收到了，此时接收方会将窗口内的分组一起交付给上层。同时窗口会右移到下一个未接收的最小序列号的位置，也就是pkt6的位置，如上右图最下边所示。
- 对于发送端来说，第二次对于pkt2分组的确认ACK被正确收到了，那么窗口也会右移到下一个最小未确认ACK的序号所在的位置，也就是pkt6的位置。
SR困境
上图给出了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表示接收方窗口尺寸。