运输层(三)流水线可靠数据传输协议、回退N步、选择重传

前言：

来源于《计算机网络自顶向下方法》，承接上回可靠数据传输的原理，rdt3.0是一个功能正确的协议，但是无论如何他都是一个停等协议，需要等待接收方回应后，才能进行下一个分组的发送,所以它的性能不会特别的好。下面来介绍如何解决呢？

流水线可靠数据传输协议

这种特殊的性能问题的一个简单解决方法是：不以停等方式运行，允许发送方发送多个分组而无需等待确认。此技术成为流水线。

• 必须增加序号的范围，因为每个传输中的分组必须有一个唯一的序号，而且也许有多个在传输中的未确认报文。
• 协议的发送方和接收方双端也不得不缓存多个分组。发送方最低限度应当缓存哪些已经发送但没有确认的分组。接收方或许也需要缓存那些已正确接收的分组
• 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错恢复有两种基本的方法：回退 N 步（Go-Back-N, GBN） 和 选择重传（Selective Repeat, SR）。

回退N步

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

如图所示，那些已经被发送但还未被确认的分组的许可序号范围可以被看成是一个在序号范围内长度为N的窗口，随着协议的运行，该窗口在序号空间向前滑动。因此n常被成为窗口长度，gbn协议也常被成为滑动窗口协议
下图是 GBN 协议 FSM 描述：

发送方必须响应三种类型的事件：

• 上层的调用。当上层调用 rdt_send() 时，发送方首先检查发送窗口是否已满，即是否有 N 个已发送但未被确认的分组。如果窗口未满，则产生一个分组并将其发送，并相应地更新变量。如果窗口已满，发送方只需将数据返回给上层，隐式地指示上层该窗口已满。然后上层可能会过一会儿再试。在实际实现中，发送方更可能缓存这些数据，或者使用同步机制（如一个信号量或标志）允许上层在仅当窗口不满时才调用 rdt_send()。
• 收到一个ACK。在 GBN 协议中，对序号为 n 的分组的确认采取累积确认（cumulative acknowledgment）的方式，表明接收方已正确接收到序号为 n 的以前且包括 n 在内的所有分组。
• 超时事件。协议的名字“回退 N 步”来源于出现丢失和时延过长分组时发送方的行为。就像在停等协议中那样，定时器将再次用于恢复数据或确认分组的丢失。如果出现超时，发送方重传所有已发送但未被确认过的分组。 上图中发送方仅使用一个定时器，如果收到了一个 ACK，但仍有已发送但未被确认的分组，则定时器被重新启动。如果没有已发送但未被确认的分组，该定时器被终止。

接受方：

• 如果一个序号为 n 的分组被正确接收到，并且按序（即上次交付给上层的数据是序号为 n - 1 的分组），则接收方为分组 n 发送一个 ACK，并将该分组中的数据部分交付到上层。
• 在所有其他情况下，接收方将丢弃该分组，并为最近按序接收的分组重新发送 ACK。
• 注意到因为一次交付给上层一个分组，如果分组 k 为已接受并交付，则所有序号比 k 小的分组也已经交付。因此，使用累积确认是 GBN 的一个自然的选择。

虽然 GBN 协议看起来很浪费，因为它会丢弃一个正确接收（但失序）的分组。但这样做是有道理的。因为接收方必须将数据按序交付给上层，假设现在期望接收分组 n，而分组 n + 1 却到了，因为数据必须按序交付，所以接收方可能缓存分组 n + 1，然后，在它收到并交付分组 n 后，再将该分组交付到上层。但是，如果分组 n 丢失，则该分组及分组 n + 1 最终将在发送方根据 GBN 重传规则而被重传，所以，接收方只需要直接丢弃分组 n + 1 即可。
这种方法的优点是接收方不需要缓存任何失序分组，唯一需要维护的信息就是下一个按序接收的分组的序号。缺点就是随后对该分组的重传也许会丢失或出错，进而引发更多的重传。

选择重传

SR 协议在 GBN 协议的基础上进行了改进，它通过让发送方仅重传那些它怀疑在接收方出错（即丢失或受损）的分组而避免了不必要的重传。选择重传协议只重传真正丢失的分组.

序号空间图：

发送方的事件与动作：

• 从上层收到数据。当从上层接收到数据后，SR 发送方检查下一个可用于该分组的序号。如果序号位于发送方的窗口内，则将数据打包并发送；否则就像在 GBN 中一样，要么将数据缓存，要么将其返回给上层以便以后传输。
• 超时。定时器再次被用来防止丢失分组。然而，现在每个分组必须拥有其自己的逻辑定时器，因为超时发生后只能发送一个分组。
• 收到ACK。如果收到 ACK，倘若该分组序号在窗口内，则 SR 发送方将那个被确认的分组标记为已接收。若该分组的序号等于 send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组。
  接收方的事件与动作：

接收方方的事件与动作：

• 序号在 [rcv_base, rcv_base+N-1] 内的分组被正确接收。在此情况下，收到的分组落在接收方的窗口内，一个选择 ACK 被回送给发送方。如果该分组以前没收到过，则缓存该分组。如果该分组的序号等于接收端的基序号（rcv_base），则该分组以及以前缓存的序号连续的（起始于 rcv_base 的）分组交付给上层。然后，接收窗口按向前移动分组的编号向上交付这些分组。
• 序号在 [rcv_base-N, rcv_base-1] 内的分组被正确收到。在此情况下，必须产生一个 ACK，即使该分组是接收方以前确认过的分组。
• 其他情况。忽略该分组。

总结可靠数据运输机制：

• 验证和：用于检测在一个传输分组中的比特错误
• 定时器：用于超时/重传一个分组，可能因为这个分组在信道中丢失了，由于当一个分组延时但为丢失，或者当一个分组已经被接收方收到但从接收方到发送方的ack丢失时，可能产生超时事件，所以接收方可能会收到一个分组的多个冗余副本
• 序号：用于为从发送方流向接收方的数据分组按顺序编号，所接受分组的序号间的空袭可使接收方检测出丢失的分组，拥有相同序号的分组可使接收方检测出一个分组的多个冗余副本
• 确认：接收方用于告诉发送方一个分组或者一组分组已经被正确的几首，确认报文通常携带着被确认的分组或者多个分组序号，确认可以是逐个的或者积累的，这取决于协议。
• 否定确认：接收方用于告诉发送方某个分组未被正确的接受，否定报文通常携带着未被正常接受的分组序号
• 窗口、流水线：发送方也许被限制仅发送那些序号落在一个指定范围内的分组，通过允许一次发送多个分组但未被确认，发送方的利用率可在停等操作模式的基础上得到增加，窗口长度可以根据接收方接受和缓存报文的能力，网络中的拥塞成都来设置。ß