第三章

3.4 可靠传输的原理

• 可靠传输的实现问题不仅在运输层出现，也在链路层以及应用层出现。
• 实现这种服务抽象是可靠数据传输协议（reliable data transfer protocol rdt)的责任由于事实上可靠数据传输协议的下层协议也许是不可靠的，因此这项任务是比较困难的
• 单向数据传输（unidirectional data transfer )
• 双向数据传输（bidirectional data transfer )

---

3.4.1 结构可靠数据传输协议

1.完全可靠信道上的可靠数据传输： rdt1.0

• FSM:finite-state machine 有限状态机
• 发送方和接收方有各自的FSM
• rdt的发送方只通过rdt_send（data)从较高层接收的数据，产生一个包含该数据的分组（经由make_pkt(data)动作），并将分组发送到信道中。实际上，rdt_send(data)事件是由较高层应用的过程调用产生的
• 在接收方，rdt通过rdt_rcv(packet)事件从底层信道接收一个分组，从分组中取出数据（经由extract(packet,data)动作），并将数据上传给较高层（deliver_data)动作）。实际上，rdt_rcv（packet）事件是由较低层协议的过程调用产生的

2.具有比特差错信道上的可靠数据传输： rdt2.

• 肯定确认（positive acknowledgment ACK)
• 否定确认（negative acknowledgment NAK)
• 在计算机网络环境中，基于这种重传机制的可靠数据传输协议称为自动重传请求（Automatic Repeat reQuest ARQ）

ARQ协议处理存在的比特差错需要的另外三种协议

• 差错检测
• 接收方检测
• 重传

rdt2.0 的发送方有两种状态。

在最左边的状态中，发送方协议正等待来自上层的数据。
当rdt_send（data)时间发生时，发送方将产生一个包含带发送数据的分组（sndpkt）计算出分组检验和，然后经由udt_send（pkt)操作发送该分组. 在最右边的状态中，发送方协议等待接收方的ACK或NAK分组。如果收到一个ACK分组，则发送方直到最近传输的分组已被正确接收，因此协议返回到等待来自上层数据的状态。如果收到一个NAK分组，该协议重传最后一个分组并等待接收方返回的响应重传分组的ACK或NAK

停等协议（stop-and-wait）：每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

rdt2.1

rdt2.1的发送方和接收方FSM的状态数都是以前的两倍。这是因为协议状态此时必须反映出目前正在发送的分组或希望接收的分组的序号是0还是1

协议rdt2.1使用了从接收方到发送方的肯定确认和否定确认。当接收到失序的分组时，接收方对所接收的分组发送了一个肯定确认，如果收到受损的分组，接收方将发送一个否定确认。如果不发送NAK，而是发送一个对上次正确接收的分组ACK，我们也能实现与NAK一样的效果。发送方接收到对同一个分组的两个ACK（即接受冗余ACK duplicate ACK)后，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。rdt2.2实在具有比特差错信道上实现的一个无nak的可靠传输协议

3.具有比特差错的丢包信道上的可靠数据传输：rdt3.0

从发送方的观点来看，重传是一种万能灵药。发送方不知道是一个数据分组丢失、一个ACK丢失，还是该分组或ACK只是过度延时。
重传是为了实现基于时间的重传机制，需要一个倒计数定时器（countdown timer）在一个给定的时间过期后，可中断发送方。发送方需要能做到：①每次发送一个分组时，便启动一个定时器；②响应定时器中断；③终止定时器

rdt3.0有时被称为比特交替协议（alternating-bit protocol)

---

3.4.2流水线可靠数据传输协议

• 定义发送方的利用率（utilization）为：发送方实际忙着将发送比特送进信道的那部分时间与发送时间之比
• 因为从发送方向接收方传输的众多分组可以被看成是填充到一条流水线中，故这种技术被称为流水线。流水线可对可靠数据传输协议带来如下影响：

必须增加序号范围

协议的发送方和接收方也许必须缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有确认的分组。

所需序号范围和对缓冲的要求取决于数据传输协议处理丢失、损坏及过度延时分组的方式。解决流水线的差错恢复有两种基本方法：回退N步和选择重传

---

3.4.3回退N步

• 在回退N步协议中，允许发送方发送多个分组而不需等待确认，但它也受限于在流水中未确认的分组数不能超过某个最大允许数N
• 如果我们将基序号定义为最早的未确认分组的序号，将下一个序号定义为最小的未使用序号，则可将序号范围分割4部分。
• 已经被发送但还未被确认的分组的许可序号范围可以被看成一个在序号范围内长度为N的窗口。随着协议的运行，该窗口在序号空间内向前滑动。因此常被称为窗口长度，GBN协议常被称为滑动窗口协议
• GBN发送方必须响应以下三种类型的事件：
  

  上层的调用

收到ACK

超时事件
- 在GBN中，接收方丢弃所有失序分组，这个方法看起来是愚蠢的，但是这种方法的优点是接收方缓存简单，即接收方不需要缓存任何失序分组

• 在这种基于事件的编程方式中，这些过程要么被协议栈中的其他其他过程调用，要么作为
  一次中断的结果。在发送方，这些时间包括：①上层实体调用rdt_send(),②定时中断，③报文到达时，底层调用rdt_rcv（）。

3.4.4 选择重传

• GBN协议允许发送方用多个分组“填充流水线”，因此避免了停等协议中所提到的信道利用率问题。 GBN本身也存在着性能问题。尤其是当窗口长度和带宽时延积都很大，在流水线中会有很多分组时更是如此。一个单个分组的差错就可能引起GBN重传大量分组，许多分组根本没有必要重传。随着信道差错率的增加，流水线可能会被这些没必要重传的分组填满
• 选择重传协议通过让发送方仅重传那些它怀疑在接收方出错（丢失或受损）的分组而避免了不必要的重传。