计算机网络——可靠数据传输

---

一、可靠数据传输的原理

可靠数据传输指的是数据比特无损坏（由0变成1，或者相反）、丢失情况，并且数据是按照发送顺序进行交互的。

如图所示，运输层需要为应用层提供可靠信道，但是运输层的下层网络层又是不可靠的。需要在不可靠的信道上为上层提供可靠传输，实现这种服务抽象是可靠数据传输协议。

二、构建可靠数据传输协议

2.1经完全可靠信道的可靠数据传输：rdt1.0

rdt1.0是基于底层信道是完全可靠的假设建立的，所以其根本不需要做额外的工作，发送端等待上层调用将数据打包并传到下层，接收端接收下层传来的数据包，解析出数据并传到上层。

rdt的发送端只通过rdt_send(data)事件接受来自上层的数据，通过make_pkt产生一个包含该数据的分组，并将分组发送到信道中。

在接收端，rdt通过rdt_rcv(packet)事件从下层层信道接受一个分组，通过extract（packet,data）从该分组中取得数据，最后通过deliver_data(data)将数据传送到上层。

2.2经具有比特差错信道的可靠数据传输：rdt2.0

rdt1.0是基于底层信道完全可靠的假设而设定的，而实际情况下底层信道更为实际的模型是分组中的比特可能受损的模型。在分组的传输、传播或缓存过程中，这种比特差错通常会出现在网络的物理部件中。我们现在就基于传输过程中比特容易受损的实际情况但接收方所有的分组接收顺序和发送顺序一样的假设，制作出rdt2.0协议。
rdt2.0相较于rdt1.0需要额外处理一个比特受损的情况。在介绍rdt2.0之前，现在实际生活中考虑一个这样场景：同事A向同事B讲述一段很长的报文，同事B如果理解并记下会恢复一句”OK“，但是如果某一段没有理解或者听清楚会说”NO“并请求同事A再重述一次。这种口述报文使用了肯定确认与否定确认。在计算机网络环境中，基于这种重传机制的可靠数据传输称为自动重传请求（Automatic Repeat reQuest ARQ）协议。
ARQ协议需要另外三种协议功能来处理存在比特差错的情况：

• 差错检测：接收方需要一种机制检测到何时出了比特差错
• 接收方反馈：接收方需要根部报文是否出现差错回复”肯定确认“（ACK）或”否定确认"(NAK)
• 重传：接收方收到有差错的分组是发送方重传该分组
  
  如上图表示rdt2.0发送端的FSM，发送端具有两个状态，在左边的状态中，当上层调用rdt_send(data)时，发送方将数据和校验和打包成一个分组并发送该分组，此时变成右边的状态，发送方等待接收方回复ACK或者NAK，如果是NAK，就代表分组出现比特差错，测试接收方重新传送分组；如果是ACK，则发送方知道最近发送的分组已经被正常接收，此时协议返回到等待来自上层数据的阶段。注意当发送方处于等待ACK或NAK状态的时候不能从上层获得数据，只有当接收到ACK离开刚状态的时候才能够从上层接收数据。因此发送方只有确信接收方正确接收当前分组时候才会发送一块新数据。由于这种需要等待接收方反馈发送方才能决定下一步动作的行为，rdt2.0成为停等（stop-and-wait）协议。
  
  如上图表示rdt2.0接收端的FSM，接收端只有一个状态，分组到达时视分组是否受损回答ACK或者NAK。
  rdt2.0看起来似乎可以运行了，但是它存在一个致命的问题，就是没有考虑到ACK或NAK分组受损的可能性。解决这个新问题的一个简单方法是接收方如果收到受损的回复报文，不管收到的是ACK还是NAK都重发上一次的报文
  
  

如上图表示rdt2.1的FSM描述。rdt2.1的发送端和接收端FSM的状态数都是以前的两倍，这是因为协议状态此时必须要反映出目前（由发送方）正发送或（接收方）希望接收的分组序号是0还是1。rdt2.1使用了从接收方到发送方的肯定确认和否定确认。当接收到失序的分组时，接收方对接收的分组发送一个肯定确认。如果收到受损的分组，则接收方将发送一个否定确认。


上图所示，rdt2.2的发送端和接收端FSM，和rdt2.1的区别就是如果接收端接收到分组受损的报文不在发送NAK而是发送对上次正确接收的分组发送一个ACK，发送端接收到对同一个分组的两个ACK（即冗余ACK）就知道接收方没有正确接收到跟在被确认两次分组后面的分组。

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

rdt2.2通过使用校验和、序号、ACK分组和重传等解决了传输过程钟比特差错的问题，但是底层信道还会出现丢包。丢包包括两种情况发送端的数据丢失和接收端回复的ACK丢失，这两种情况发送端都收不到接收端的回复。为了解决这个问题，rdt3.0采用定时器，即发送端等待足够长的时间（时间应该定为超过一个往返时延）如果还没有收到接收端的回复就重新发送该分组。

如图rdt3.0发送端FSM，发送端在发送分组的时候开启计时器，如果正常接收到接收端的回复则关闭计时器，否则等到计时器到达指定时间就重新发送该组。

三、 流水线的可靠数据传输

虽然rdt3.0是一个协议正确的传输协议，但是存在一个致命的效率问题，因为rdt3.0是基于停等协议。

如图所示，在基于停等协议中，发送方发送一个分组的最后一个比特数据后，直到收到接收方的确认回复过后才会进行下一个分组数据的发送，这段时间内，发送方就会处于空闲状态，就会造成资源的浪费，并且效率并不高。
解决这种性能问题的一个简单方法就是，发送方不以停等方式运行，允许发送方发送多个分组且无需等待确认。

如图所示，发送方发送完首个分组的最后一位比特数据后，无需等待首个分组的ACK，发送方可以接着发送第二个分组数据，因为许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中，故这种技术被称为流水线(pipeline)。流水线技术对可靠数据传输协议可带来如下影响：

• 必须增加序号范围，每个输送中的分组必须有一个唯一的序号
• 协议的发送方和接收方两端不得不缓存多个分组，比如发送方必须得缓存那些已经发送却没有收到确认的分组
• 所需序号范围和对缓冲区的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错回复有两种基本方法：回退N步（Go-Back-N,GBN） 和选择重传(Selective Reopeat,SR)

3.1回退N步协议

在回退N步协议(GBN) 中，允许发送方发送多个分组而不需要等待确认，但他也首先流水线中未确认的分组数不能超过某个最大允许数N。
如图所示，发送方在GBN协议的序号范围。其中base定义为最早未确认分组的序号，nextseqnum定义为最小未使用序号（即下一个待发分组序号），将左右的序号分成了四组：

• 【0,base-1】:已经被发送且并被确认的分组

• 【base,nextseqnum-1】:发送但是未被确认的分组

• 【nextseqnum,base+N-1】:代表那些将要立即发送的分组

• 【base+N,+∞】：不能使用的分组，直到流水线未被确认的分组已得到确认（就是base序号的前移）
  那些已被发送但是未被确认的分组的许可序号范围可以被看成一个序号范围内长度为N的窗口，随着协议的运行窗口的序号空间向前滑动，因此N常被称为窗口长度 ，GBN协议也被称为滑动窗口协议（sliding-window protocol）
  
  如图所示，GBN发送方必须响应三类类型的事件：

• 上层的调用：当上层调用rdt_send()时，发送方首先检查发送窗口是否已满，即是否有N个已发送但是没有未被确认的分组，如果窗口未满，则产生一个分组将其发送，响应的更新变量，如果满了，将数据返回给上层，并告诉上层窗口已满。

• 收到一个ACK：在GBN协议中，对序号为n的分组才去累计确认 的方式，表明接收方已经正确收到了序号为n以前且包括n的所有分组

• 超时事件：如果出现超时，发送方重传所用已发送但是还未被确认的分组
  
  在GBN中，接收方的动作很简单，如果接收到一个序号为n的分组，并且之前所有的分组（即0到n-1）都已经接收到并上传给上层了，则接收下这个分组将数据传给上层并返回ACK，其他任何情况都丢弃该分组。
  如图表示的运行中的GBN协议，值得注意的是，发送发发送分组2丢失，导致分组3比分组2更显到达接收方，但是测试接收方希望收到的是分组2，即丢弃分组3并告诉发送方希望收到分组2（发送ACK1）。

4.2选择重传

上述介绍了GBN协议，但是GBN协议本身也存在一定的性能问题，单个分组的出错就可能引起GBN重传大量分组。而选择重传，顾名思义，可以选择指定分组（即丢失或者出错的分组）重传而避免了不必要的重传。

如图所示，显示了选择重传协议中发送方和接收方的序号空间，发送方和GBN协议的区别在于在滑动窗口中存在已经被确认的分组；而在接收方，同样需要一个滑动窗口来表示期望收到的分组；

如图所示代表SR操作，接收方存在一个滑动窗口用于表示希望收到的分组，只要是接收到在滑动窗口的分组都会缓存，一并交付，除此之外接收的分组都会被丢失。

四、可靠数据传输机制及其用途的总结

至此已经结束了对可靠数据传输的讨论，介绍了多种机制，这些机制可一起提供可靠数据传输，下述列表就是可靠数据传输机制和用途的总结。

机制	用途和说明
校验和	用于检测一个传输分组中的比特错误
定时器	用于超时/重传以一个分组，可能因为该分组（或其ACK）在信道中丢失了。由于当一个分组延时但未丢失（过早超时），或者当一个分组已被接收方正常接收但从接收方到发送方的ACK丢失时，可能会产生超时事件，所以接收方可能会收到一个分组的多个冗余副本
序号	用于从发送方向接收方的数组分组按顺序编号。所接收分组的序号间的空隙可使接收方检测到丢失的分组。具有相同序号的分组可使接收方检测出一个分组的冗余副本
确认	接收方用于告诉发送方一个分组或者一组分组已经被正确的收到了，确认报文通常携带者被确认的分组或多个分组的序号。确认可以时逐个的或者累积的，这取决于协议
否定确认	接收方用于告诉发送方某个分组未被正确的接收。否定确认报文通常携带未被正确接收的分组序号
窗口、流水线	发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过允许一次发送多个分组但未被确认，发送方的利用率可在停等操作模式的基础上得到增加。