码迷,mamicode.com
首页 > 其他好文 > 详细

“玩具协议”——保障数据链路层的服务质量

时间:2021-06-02 13:44:44      阅读:0      评论:0      收藏:0      [点我收藏+]

标签:sea   假设   ebs   request   第一个   ima   数据   应该   文件   

为了保证通信质量和服务质量,我们需要制定靠谱的协议,下面我们的分析的过程就是来学习制定好的协议需要考虑什么因素

 

考虑最简单的点对点通信,只有一个发送者和一个接收者

联系上下两层的函数:

  • from_network_layer
  • to_network_layer
  • from_physical_layer
  • to_physical_layer 

帧长什么样子?

技术图片

技术图片

下面我们利用数学建模的思路,从最离谱的假设开始一步一步实现协议

乌托邦的梦——无限制单工协议

最最离谱的三条假设:

  • 单方向数据传输(即只有一个发送者和接收者)    
  • 理想信道(信道不出错,传输速度极快)    
  • 通信双方能力无穷(发送者不停发送,接收者不停接收)

这就很好办了,上图:

技术图片

单工—理想—停-等协议

最最离谱的三条假设:

  • 单方向数据传输(即只有一个发送者和接收者)    
  • 理想信道(信道不出错,传输速度极快)    
  • 通信双方能力无穷(发送者不停发送,接收者不停接收)

破除第三点假设——实现3.4平起平坐——基于反馈的流控制

模型优化:

技术图片

单工—停-等协议

最最离谱的三条假设:

  • 单方向数据传输(即只有一个发送者和接收者)    
  • 理想信道(信道不出错,传输速度极快)    
  • 通信双方能力无穷(发送者不停发送,接收者不停接收)

再破除一条假设——为了解决3.5犯了错怎么办——检错+重传

我们考虑以下数据传输的情况:

  • 数据正常传输
  • 数据帧出错:支持重传——PAR ( Positive Acknowledgement with Retransmission,支持重传的肯定确认协议)
  • 数据帧丢失:定时器——超时重发——ARQ (Automatic Repeat reQuest,自动重复请求协议) 
  • 确认帧出错:定时器——超时重发——ARQ (Automatic Repeat reQuest,自动重复请求协议) 
  • 确认帧丢失:根据老帧和新帧的序列号比较然后舍掉

模型优化:

技术图片

停-等协议

最最离谱的三条假设:

  • 单方向数据传输(即只有一个发送者和接收者)    
  • 理想信道(信道不出错,传输速度极快)    
  • 通信双方能力无穷(发送者不停发送,接收者不停接收)

再破除一条假设——实现数据的双向传输

如何解决?

一种方案如下:

技术图片

会造成带宽的大量浪费

另一种方案:一条线路+2逻辑信道+2单工协议

技术图片

引入捎带确认技术(Piggybacking)——将数据帧和确认帧合并一起发送?也就是发送数据的同时,将确认信息附到外发的数据帧上

技术图片

滑动窗口协议——回退n帧技术与选择性重传技术

最最离谱的三条假设:

  • 单方向数据传输(即只有一个发送者和接收者)    
  • 理想信道(信道不出错,传输速度极快)    
  • 通信双方能力无穷(发送者不停发送,接收者不停接收)

破除所有假设,这样的话我们要考虑传输时延的问题

如果距离很大导致传播时延很大,我们会看到如果我们发一个数据帧等到收到确认帧我们再去发下一个帧的话会导致信道利用率相当低

所以我们考虑一下子发好多好多帧

那到底一下子最多发多少呢?

我们引入窗口这个概念

技术图片

窗口大小=1+时延带宽积/帧长度

其中时延带宽积=双向传播时延×带宽,以比特数据量表示信道最大容量

所以窗口大小可以近似等于把来回两个信道填满的帧数+1

当窗口填满时,第一个确认帧正好赶了回来

那么确认帧的内容是什么呢?

是累计确认机制,也就是说该数前面的都收到了

在这种协议下的出错处理对应了两种协议

回退n帧的滑动窗口协议

 

技术图片

当超时重传时把从错误帧开始的缓冲区的所有帧重发

 

窗口与序号有什么关系呢?

技术图片

我们假设上图的这种情况,假设我们设定序号为0~7的编码,窗口大小为8,那么确认帧全部丢失后会发生什么事情呢?

我们重复发送的0~7会被接收方第二轮0~7接收并确认,而他们本来应该是第一轮的数据

因此我们看到了假设不成立

技术图片

换到下面这种方式呢?

7处需要针对0~6的重发依次发送确认帧,并把重发的包丢掉

所以此时需要满足w<=2^n-1

 

发送窗口为>1,接收窗口为1 

发送方需要较大的缓冲区,以便重传 

适用于信道出错率较少的情况 

选择重传的滑动窗口技术

技术图片

0~8可以看做很快的一个一个发出去了,此时各自的定时器也打开了

等到收到了0、1的确认帧,分别为1,2,他俩的定时器关闭

2在半路丢掉了,3~8在缓存里待命

2的确认帧迟迟不来,后面的数字都接到了确认帧,但都是2,不是他们各自期望的数字,所以定时器不关闭

直到2的定时器触发,将2重发,按照发送时延间隔,3~8的定时器准备依次触发,3~8准备依次重发,重发时定时器会再次打开

发到4的时候,新2的确认帧9传了回来,9之前的定时器全部关闭,5~8不必重发

重发的3,4帧不是新鲜帧,舍掉

 

为了保证数据传输的检错机制的运行,和回退n帧不同,此时是整个接收窗口接收数据

我们需要保证新老窗口不重叠,即满足w<=2^(n-1)

举个栗子:

SR条件:

序号空间为4, 即:0 1 2 3 0 1 2 3 ... , 假设窗口大小为3(大于序号一半)

  1. 发送方传012
  2. 接收方收到,滑动窗口前进至 3,0,1,接收方发回ack
  3. ack丢失,发送方重传 0,1,2
  4. 问题来了,此时接收方如何判断是发送方重传的0,1,2还是发送方传了第二个重复序列的0,1,但第一个序列的3丢失了呢?

 

此时修改窗口大小为序号空间一半,即窗口大小等于2

  1. 发送方传0,1
  2. 接收方收到,滑动窗口移动至2,3,发回ack
  3. ack丢失,发送方重传0,1
  4. 接收方看到发送方发0,1,与当前窗口不符,判断重传

 

技术图片

发送窗口为>1,接收窗口为>1

接收方也需要较大的缓冲区,以便按正确顺序将分组提交网络层

适于信道质量不好的情况 

“玩具协议”——保障数据链路层的服务质量

标签:sea   假设   ebs   request   第一个   ima   数据   应该   文件   

原文地址:https://www.cnblogs.com/yuxiaohan1236/p/14820458.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!