标签:sea 假设 ebs request 第一个 ima 数据 应该 文件
为了保证通信质量和服务质量,我们需要制定靠谱的协议,下面我们的分析的过程就是来学习制定好的协议需要考虑什么因素
考虑最简单的点对点通信,只有一个发送者和一个接收者
联系上下两层的函数:
帧长什么样子?
下面我们利用数学建模的思路,从最离谱的假设开始一步一步实现协议
最最离谱的三条假设:
这就很好办了,上图:
最最离谱的三条假设:
破除第三点假设——实现3.4平起平坐——基于反馈的流控制
模型优化:
最最离谱的三条假设:
再破除一条假设——为了解决3.5犯了错怎么办——检错+重传
我们考虑以下数据传输的情况:
模型优化:
最最离谱的三条假设:
再破除一条假设——实现数据的双向传输
如何解决?
一种方案如下:
会造成带宽的大量浪费
另一种方案:一条线路+2逻辑信道+2单工协议
引入捎带确认技术(Piggybacking)——将数据帧和确认帧合并一起发送?也就是发送数据的同时,将确认信息附到外发的数据帧上
最最离谱的三条假设:
破除所有假设,这样的话我们要考虑传输时延的问题
如果距离很大导致传播时延很大,我们会看到如果我们发一个数据帧等到收到确认帧我们再去发下一个帧的话会导致信道利用率相当低
所以我们考虑一下子发好多好多帧
那到底一下子最多发多少呢?
我们引入窗口这个概念
窗口大小=1+时延带宽积/帧长度
其中时延带宽积=双向传播时延×带宽,以比特数据量表示信道最大容量
所以窗口大小可以近似等于把来回两个信道填满的帧数+1
当窗口填满时,第一个确认帧正好赶了回来
那么确认帧的内容是什么呢?
是累计确认机制,也就是说该数前面的都收到了
在这种协议下的出错处理对应了两种协议
当超时重传时把从错误帧开始的缓冲区的所有帧重发
窗口与序号有什么关系呢?
我们假设上图的这种情况,假设我们设定序号为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(大于序号一半)
此时修改窗口大小为序号空间一半,即窗口大小等于2
发送窗口为>1,接收窗口为>1
接收方也需要较大的缓冲区,以便按正确顺序将分组提交网络层
适于信道质量不好的情况
标签:sea 假设 ebs request 第一个 ima 数据 应该 文件
原文地址:https://www.cnblogs.com/yuxiaohan1236/p/14820458.html