可靠数据传输原理

三叶屋猪子
386 阅读6分钟

趣解"可靠数据传输原理"

前言

  • 可靠数据传输协议（Reliable Data Transfer protocal）在应用层、传输层、数据链路层都很重要，是网络 TOP10 问题之一
  • 信道的不可靠特点决定了 rdt 的复杂性
  • 下面将带领各位学习如何构造一个可靠的数据传输协议

Rdt1.0：在可靠信道上的可靠数据传输

image.png

纯粹的发送，机制的接收。错误？不存在的！

Rdt2.0:具有比特差错的信道

image.png

阿发：阿接，我给你送礼物啦！

阿接：阿发，你送的奥特曼真好玩，下次送我假面骑士吧。

阿发：阿接，我又给你送礼物啦！

阿接：不对啊，我要的是假面骑士，不是超级战队。

...

Rdt2.0：具有比特差错的信道

  1. 发送方发送一段信息，接收方接收到信息后，发出确认指令
  2. 当接收到正确的信息时，接收端发送ACK给发送端
  3. 当接收到错误的信息时，接收端发送NAK给发送端

Rdt2.1:解决ACK、NAK出错的情况

有一天，阿发鼓起勇气向阿接发出了世纪难题：你喜欢奥特曼多一点还是超级战队多一点？阿接发出回复：我喜欢假面骑士多一点。但是信件在回复的过程中，被粗心的邮递员弄混成了一份名为“我喜欢高达”的信件，于是阿接下一次收到的礼物变成了高达模型...

此后，为了防止这个现象再次发生，一个大帅*研究出了Rdt2.1，成功解决了信件错误的情况。

image.png

阿发：今天中午吃什么-0

阿接：歪比歪比*&……%￥#@

阿发：今天中午吃什么-0

阿接：吃饭

阿发：今天晚上吃什么-1

阿接：吃饭

...

Rdt2.1:解决ACK、NAK出错的情况

  1. 发送方不会发送确认的确认
  2. 发送方接收到的Ack若有误，则发送老分组
  3. 发送方接收到的Ack正确，则发送下一个分组

Rdt2.2:无NAK的协议

此外，由于某些原因，阿接的回信变得委婉了些...

image.png

阿发：你觉得我怎么样？

阿接：你是个好人

阿发：你做我的女朋友吧

阿接：你是个好人

...

Rdt2.2:无NAK的协议

  1. 功能与Rdt2.1相同，但只使用带有编号的ack
  2. 接收方对最后正确的分组发ack，以代替nak
  3. 发送方收到重复的ack，则重传当前分组
  4. 为后面一次发送多个数据单位做准备

Rdt3.0:具有比特差错和分组丢失的信道

阿发与阿接你一段我一段的对话往来，日子过的很安详。可是有一天，阿接的回复信件被寄件员弄丢了，阿接却不知道，结果阿发在家依旧苦苦等待阿接的回复信件，而阿接也继续等待着阿发的快递，世界顿时静止了下来~

就在这时，一个大帅*发现了问题：下层通信可能会丢失分组，导致发生死锁。于是想出了一个方法:发送方等待Ack一段合理的时间，得出了Rdt3.0，成功解决了信件丢失的问题。

Rdt3.0:具有比特差错和分组丢失的信道

  1. 过早的超时也能正常操作，但是效率较低，一半的分组和确认是重复的
  2. 设置一个合理的超时时间也是比较重要的

流水线协议

因为阿发每次发送东西给阿接时，都需要等待阿接的回应或超时后才会继续发送，这就造成了邮递员失业的情况（邮递员很多），要是能够在阿接还未回复的时候继续发送信件就好了。

这时又出现了一个大帅*研究出了流水线协议。

image.png

流水线协议：允许发送方在未得到对方确认的情况下一次发送多个分组

  1. 必须增加编号的范围：用多个bit表示分组的序号
  2. 在发送方/接收方要有缓冲区
  3. 两种通用的流水线协议：回退N步（GBN）、选择重传（SR）

此外，在了解流水线协议时，还需要了解滑动窗口协议（slide window） 。

滑动窗口协议——发送窗口（sending window）

  • 发送缓冲区：

    1. 内存中的一个区域，落入缓冲区的分组可以发送；
    2. 用于存放已发送但未确认的分组；
    3. 需要重发时可用。

  • 发送缓冲区的大小：一次最多可以发送多少个未经确认的分组

  • 发送缓冲区中的分组：

    1. 未发送的落入缓冲区的分组可以连续发送出去
    2. 已发送且等待确认的分组，发送缓冲区的分组只有得到确认才能删除

滑动窗口协议——接收窗口（receiving window）

  • 接收窗口 = 接收缓冲区
  • 只有收到的分组、序号落入接收窗口内才允许接收；若序号在接收窗口外，则丢弃
  • 当接收窗口 w=1，则只能顺序接收；w>1，则可以乱序接收，但提交给上层要按序

两个典型的流水线协议

GBN

回退N步（Go Back N）协议其实也就是滑动窗口协议

image.png

  • 发送端最多在流水线中有N个未确认的分组

  • 接收端只是发送累计型确认，接收端如果发现错误，则不确认新到来的分组

  • 发送端拥有对最老的未确认分组的定时器

    1. 只需设置一个定时器
    2. 当定时器到时时，重传所有未确认分组

SR

选择重传（Selective Repeat）协议

image.png

  • 接收方对每个到来的分组单独确认，非累计确认
  • 发送方为每个未确认的分组保持一个定时器，当超市定时器到时，只重发到时的未确认分组

比较 GBN 与 SR

  • 相同之处
  1. 发送窗口都大于1
  2. 一次能够发送多个未经确认的分组
  • 不同之处

GBN：

  1. 接收窗口尺寸为1
  2. 接收端只能顺序接收
  3. 发送端从表现来看，一旦一个分组没有发送成功，如：发送0、1、2、3、4，假设1未发送成功，2、3、4都发送出去了，要返回1重新发送，GB1

SR：

  1. 接收窗口尺寸大于1
  2. 发送端发送0、1、2、3、4，假设1未发送成功，2、3、4都发送出去了，无需重发，选择性发送1即可，SR1
  • 优劣分析
GBNSR
优简单，所需资源少出错时，重传一个代价小
劣一旦出错，回退N步代价大复杂，需要资源多
avatar
文章
阅读
粉丝