笔记 数据链路层中(1)流量控制与可靠传输机制
(一)流量控制与可靠传输机制简介
一、数据链路层的流量控制
较高的发送速度和较低的接受能力的不匹配,会造成传输出错,因此流量控制也是数据链路层的一项重要工作。
注:数据链路层的流量控制是点对点的,而传输层的流量控制是端到端的
数据链路层流量控制手段:接收方收不下就不回复确认
传输层流量控制手段:接收端给发送端一个窗口公告。
二、流量控制的方法简介
(1)停止-等待协议(相当于发送窗口是1的滑动窗口协议)
每发送完一个帧就停止发送,等待对方的确认,在收到确认后再发送下一个帧。
(2)滑动窗口协议
1.后退N帧协议(GBN)
2.选择重传协议(SR)
注:每一个小格都代表一个帧,可发现序号有重复,这是因为帧序号是可以重复利用的。
代表发送了发送窗口的第一个帧。0号帧。
代表在接收了0号帧后,接收方再向发送方发送确认帧,并且接收窗口向右移动
发送方在接收到确认帧后,发送窗口向右移动。
注:如果这时候没有收到确认帧,它会继续将发送窗口的帧发送出去,直到接收到确认帧,才会向右移动一格。
注:
停止等待协议:发送窗口大小=1,接收窗口大小=1
后退N帧协议(GBN):发送窗口大小>1,接收窗口大小=1
选择重传协议(SR):发送窗口大小>1,接收窗口大小>1
注:链路层的滑动窗口大小是固定值,在传输层的窗口大小可能改变
(3)可靠传输、滑动窗口、流量控制
可靠传输:发送端发啥,接收端收啥
流量控制:控制发送速率,使接收方有足够的缓冲空间来接收每一个帧
滑动窗口解决:流量控制(收不下就不给确认,想发也发不了) 可靠传输(发送方自动重传)
(二)停止—等待协议
(1)为什么要有停止等待协议
除了比特出差错,底层信道还会出现丢包问题。为了实现流量控制。
注:丢包:物理线路故障、设备故障、病毒攻击、路由信息错误等原因,会导致数据包的丢失。
(2)停止等待协议的前提
虽然现在常用全双工通信方式,但是为了讨论问题的方便,仅考虑一方发送数据(发送方),一方接收数据(接收方)。
因为是在讨论可靠传输的原理,所以并不考虑数据是在哪一个层次上传送的。
停止等待就是每发送完一个分组就停止发送,等待对方确认,再收到确认后在发送下一个分组。
(3)停等协议有几种应用情况
1.无差错情况
2.有差错情况
数据帧丢失或检测到帧出错
注:1.发送完一个帧后,必须保留它的副本。这样如果发生帧丢失,就可以重传。
2.数据帧和确认帧必须编号
ACK(确认帧)丢失
发送方由于没收到确认帧,所以依旧会重传,但是接收方就相当于重复接收了两次。所以接收方会丢弃重复的1帧,重传确认1帧
ACK迟到
发送方对于迟到的确认帧不做处理,直接丢弃
(4)性能分析
方式简单,但是信道利用率太低
(5)信道利用率&信道吞吐率
信道利用率:发送放在一个发送周期内,有效的发送数据所需要的时间占整个发送周期的比率。
引言
停等协议的弊端:发送方每发送一个帧,就处于等待状态,只有当接收到了确认帧才继续发送。发送效率很低,浪费时间和资源。
那么我们可以连续发送三个帧码,这又被称为流水线技术。
注:1.必须增加序号的范围,即连续发送的序号要不同
2.发送方需要缓存多个分组,来为重传做准备。比停止等待的缓存要大一点
针对以上两个解决方案,我们有了后退N帧协议(GBN)和选择重传协议(SR)
(三)后退N帧协议(GBN)
(1)GBN中的滑动窗口机制
发送窗口:发送方维持一组连续的允许发送的序号
接收窗口:接收方维持一组连续的允许就收帧的序号
后退N帧协议的滑动窗口机制是:GBN的发送窗口内的帧可以连续发送,被发送的帧同时会保存副本,防止需要重传情况的发生。当接收方接收到帧后,接收窗口就会向右滑动,同时发送确认帧。发送方在收到确认帧的时候,发送窗口就会向右滑动。
(2)发送方必须响应的三件事
上层(网络层)调用(网络层如果让链路层给他发送数据,链路层应当在GBN协议中做些什么)
上层要发送数据的时候,发送方首先检查发送窗口是否已满,如果未满,则产生一个帧并将其发送,如果窗口已满,发送方只需将数据返回给上层,暗示上层窗口已满。上层等一会再发送。(实际实现中,发送方可以缓存这些数据,窗口不满时再发送帧)
收到一个ACK
GBN协议中,对n号帧的确认采用累计确认的方式。标明接收方已经收到n号帧和它之前的全部帧(也就是说,不需要逐个发确认帧)
超时事件
协议的名字为后退N帧,来源于出现丢失和时延过长帧时发送方的行为。就像在停等协议中一样,定时器将再次用于恢复数据帧或确认帧的丢失。如果出现超时,发送方重传所有已发送但未被确认的帧。
(3)接收方要做的事
正确接收
如果正确收到n号帧,并且按序,那么接收方为n帧发送一个ACK,并将该帧的数据部分交付给上层
接收错误
其余情况都丢弃帧,并为最近按序接收的帧重新发送ACK。接收方无需缓存任何失序帧,只需要维护一个信息:expectedseqnum(下一个按序接收的帧序号)
(4)运行中GBN协议(一个例子)
假设发送窗口尺寸为4
(5)发送窗口的大小上限
Q:窗口的长度可以无限吗?
A:若采用n个比特对帧编号,那么发送窗口的尺寸WT应满足:1≤WT≤2^n-1。因为发送窗口尺寸过大,就会使得接收方无法区别新帧和旧帧。(旧帧全部丢失,要重传的时候全部都要重传,那么没有重复编号的话就会无法分辨新帧和旧帧)
(6)GBN的重点总结(考研)
1.累计确认
2.接收方只按顺序接收帧,不按序无情丢弃
3.确认序列最大的,按序到达的帧
比如接收到124,那么接收方丢弃4,发会序号为2的确认帧
4.发送窗口最大为2^n-1,接收窗口大小为1
(7)GBN的性能分析
优点:因连续发送数据帧而提高了信道利用率
缺点:(累计确认导致的批量重传现象)在重传时必须把原来已经正确传送的数据帧重传,使传送效率降低
引言
那么有没有办法只重传出错的帧呢?
解决办法:设置单个确认,同时加大接收窗口,设置接收缓存,缓存乱序到达的帧
(四)选择重传协议(SR:Selective Repeat)
(1)SR中的滑动窗口机制
SR中的滑动窗口:
设发送窗口和接收窗口的大小都是4.那么此时发送窗口里的帧的类型分为这几种。
与GBN协议不同的是,此时的发送窗口可能不都是发完等待确认或者还能发送的的帧,可能还有发完也确认过了的帧,只不过在它前面的帧还没有被确认,所以滑动窗口还不能被滑动。
同样的,接收方除了等待接收的,还有可能存在已经收到了,但他前面有帧还没有收到,所以接受滑动窗口还不能移动。
(2)发送方必须响应的三件事
上层调用
从上层收到数据后,SR发送方检查下一个可用于该帧的序号,如果序号位于发送窗口内,则发送数据帧。否则就像GBN一样,要么将数据缓存,要么返回给上层之后再传输。
收到一个ACK
如果收到ACK,假如该帧序号在窗口内,则SR发送方将那个被确认的帧标记为已接受。如果该帧序号是窗口的下界(最左边第一个窗口对应的序号),则窗口向前移动到具有最小序号的未确认帧处。如果窗口移动了,并且有序号在窗口内的为发送帧,则发送这些帧。
例:这里,2.4是发送了,有副本,但没有收到确认的帧,3是发送了也受到确认的帧,5是等待发送的帧。
如果此时2受到了确认。那么发送窗口会直接滑到4567,并开始发送窗口中还未发送的帧
超时事件
每一个帧都有一个自己的定时器,一个超时事件发生后只重传一个帧。
(3)接收方要做的事
窗口内的帧来者不拒(在接收窗口的帧)
SR接收方将确认一个正确接收的帧而不管其是否按顺序。失序的帧将被缓存。并返回给发送方一个该帧的确认帧(收谁确认谁),直到所有帧(即序号更小的帧)都被收到为止,这时才可以将一批帧按序交付给上层,然后向前移动滑动窗口。
例:此时5是准备接收的,6是已经确认且发送确认帧的,如果这时候接收到了7号帧,那么会将他缓存起来。等到接收到5号帧的时候再一起按顺序交付给网络层,且移动滑动窗口。
其余情况
如果收到了窗口序号外(小于窗口下界)的帧,就返回一个ACK。其他情况,就忽略该帧。
(4)运行中的SR
(5)窗口大小上限
注:发送窗口最好等于接收窗口(大了会产生溢出现象,小了没有意义),窗口过大会导致可能辨别不出是旧帧还是新帧。
WTmax=WRmax=2^(n-1),n是表示帧号用的比特数