【计算计网络】可靠数据传输原理2（流水线可靠数据传输协议）
流水线可靠数据传输协议
如上篇文章所述所述的rdt3.0协议是一个功能正确的协议，但是因为它是停止等待协议，所以它的的性能并不高。它对信道的利用率十分低，为解决这个问题的简单方法便是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。
采用流水线技术对可靠数据传输也产生了一些影响：
- 必须增加序号范围，因为每个输送中的分组（不计重传的）必须有一个唯一的序号，而且也许有多个在输送中未被确认的报文。
- 协议的发送方和接收方两端也许必须缓存多个分组。
- 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线差错恢复的两种基本办法是：回退N步（Go-Back-N,GBN）和 选择重传（Selective Repeat,SR）。
回退N步（GBN）
在GBN协议中，允许发送发发送多个分组（当有多个分组可用时）而不需要等待确认，但是它受限于流水线中为确认分组数不能超过某个最大允许数N。可操作此处的GBN Java小程序查看GBN运作过程。
下图（来自《计算机网络 自定向下方法》）显示了发送方看到的GBN协议的序号范围。
base代表最早的未确认的分组，nextseqnum代表最小的未使用的序号（即下一个待发分组序号）。
序号范围可以分成四段，[0,base-1]段内的序号对应于已经发送并被确认的分组，[base,nextseqnum-1]代表已被发送但未被确认的分组，[nextseqnum,base+N-1]段内的序号能用于那些即将要被发送的分组，最后大于等于base+N的序号是不能被使用的
那些已被发送但还未被确认的分组的许可序号范围可以被看成是一个在序号范围长度为N的窗口。
随着协议的进行，搞窗口序号空间向前滑动。因此，N常被称为窗口长度（window size）,GBN协议也被称为滑动窗口协议（sliding-window protocol）。
在此我们限定的窗口长度N，而不是让分组数为无限大是有两个原因①流量控制②TCP拥塞控制
如果分组序号字段的比特数为k,那么序号范围就是[0,2k-1],在一个有限的序号范围内，所有涉及序号的运算必须使用模2k运算。
GBN发送方必须响应三种类型的事件：
-
上层的调用
当上层调用分组发送时，发送方首先检查发送窗口是否已满，即是否含有N个已发送但是未被确认的分组。如果窗口未满，则产生一个分组并将其发送，并更新相应变量。如果窗口已满，发送方只需将数据返回给上层，隐式指示上层该窗口已满。然后上层可能过一会儿在试试。在实际实现中，发送方可能会缓存这些数据，或者使用同步机制允许上层在仅当窗口不满是才调用分组发送。 -
收到一个ACK
在GBN协议中，对序号为n的分组采用累积确认(cumulative acknowledgment)方式，表明接收方已正确接收到序号为n的以前且包括n在内的所有分组。 -
超时事件
协议的名字“回退N步”源于出现丢失和时延过长的分组时发送方的行为。
发送方采用一个定时器，可作为最早发送但未被确认的分组的定时器。如果收到一个ACK，但是仍有已发送但是未被确认的分组，定时器被重新启动。如果没有已发送但是未被确认的分组，该定时器被终止。
GBN的接收方
如果一个序号为n的分组被正确接收并且是按序的，接收方为分组n发送一个ACK，并将该分组的数据部分交给上层。其他情况，发送方丢弃该分组，并未最近按序接收的分组重新发送ACK。
接收方丢弃所有失序分组。分组n丢失，发送发会重传分组n以及分组n后面的分组，接收方不必缓存失序分组后面的分组。接收方需要维护下一个按序接收的分组序号。
下图为窗口长度为4的GBN协议运行情况。
在GBN协议综合了TCP可靠数据传输构件时遇到的所有技术，包括使用序号、累积确认、检验和以及超时重传操作。
选择重传
GBN也存在着一些性能问题，单个的分组出现差错就会引起GBN重传大量不必要重传的分组。在信道差错率很高时，流水线可能会被不必要重传的分组所充斥。可操作此处SR Java小程序查看SR运作流程。
SR协议通过让发送方仅重传那些它怀疑在接受方出错（丢失或受损）的分组而避免不必要的重传。
下图（来自《计算机网络 自定向下方法》）显示了SR协议中发送方和接收方的序号范围。
在SR协议中发送方和接收方所采取得动作可见下文描述。
SR发送方的事件与动作
-
从上层接收到数据
从上层接收到数据后，SR发送方检查下一个可用于该分组的序号。如果该序号位于发送方的窗口内，则将数据打包并发送；否则就像再GBN中一样，要么将数据换粗，要么返回给上层以便以后传输。 -
超时
定时器在此用来防止丢失分组。但是，SR中每个分组都要有自己的逻辑定时器。 -
收到ACK
如果收到ACK,倘若该分组序号在窗口内，SR发送方就将那个被确认的分组标记为已接收。
如果该分组的序号等于send_base，则窗口基序号向前移动到具有最小序号的未被确认分组处。
如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组。
SR接收方的事件与动作
SR接收方将确认一个正确接收的分组而不管其是否按序。失序的分组将被缓存，知道所有丢失分组皆被收到为止，这时才将一批分组按序交付给上层。
-
序号在[rcv_base,rcv_base+N-1]内的分组被正确接收
在此情况下，收到的分组落在接收方的窗口内，一个选择ACK被回送给发送方。
如果该分组以前没有被接收到过在，则缓存该分组。
如果该分组的序号等于基序号，则该分组以及以前缓存的序号连续的分组交付给上层。
然后，接收窗口按向前移动分组的编号向上交付这些分组。 -
序号在[rcv_base-N,rcv_base-1]内的分组被正确收到
在此情况下，必须产生一个ACK,即使该分组时接收方以前已确认的分组。
要意识到这是非常重要的，假设接收方以前就接收了send_base分组，现在接收到重传的不回送ACK，那么发送方窗口就永远也不会向前滑动！ -
其他情况，忽略该分组
SR协议中发送方窗口和接收方窗口并不总是一致的。这会引出关于序号范围的一个问题。
在有限的序号范围的实现里，如果SR接收方窗口太大并且发送方和接收方窗口间的不同步，便会造成发送方这边新分组序号与旧分组序号重复使用。导致无法辨析该序号代表的是一个新分组还是旧分组。
SR的窗口长度应限制在小于等于序号空间大小的一半。
小结一下可靠数据传输机制中使用到的技术:
检验和、定时器、序号、确认、否定确认、窗口/流水线
此文为《计算机网络 自顶向下方法》学习笔记2
