3.4 可靠传输

3.4.1 基本概念

假如接收端检测到了有一个帧出现错误,那就告诉发送方:哥们,有一个帧出错了,麻烦重发一下。

试想一下这样一种情况,假如接收方告诉发送方的话是有误的,欺骗的,那会引起更大的灾难。

后面我们会介绍三种实现可靠传输的方法。

 

一般情况下,有线链路的误码率比较低,为了减少开销,并不要求数据链路层向上层提供可靠传输服务,即使出现误码,可靠传输的问题由上层处理。

无线链路易受干扰,误码率较高,因此要求数据链路层必须向上层提供可靠传输服务。

 

3.4.1 停止-等待协议

发送方每发送完一个分组后,就停止发送下一个分组。并且缓存还不能清掉,等到接收到接收方的确认ACK那就清掉缓存,并且发送下一个分组。如果接收方发送的是否认NAK没有收到,那就重发。

但是实际情况更复杂,我们来看下面这种情况。一开始传输的时候就出现错误,并且接收方收不到,也就不会发ACK或者NAK,那这样就一直等着。破冰的办法就是超时计时器。比往返时间略大一点,超时了还没收到回复,那就重传。

既然发送方发送的数据分组可能丢失,那我接收方发送的接收分组也可能会丢失。这必然会造成超时重传。假设这个重传的也达到了接收方,那么问题来了,接收方如何判断该数据分组是不是重复的呢?

为了避免出现分组重复,必须给分组带上序号。

通过确认分组丢失的情况,引出了给确认分组编号的操作。

请大家思考一下:既然数据分组需要编号,那么确认分组是否也需要编号呢?

如果我们的确认迟到了,发送方到点重传了,收到重复确认,那他怎么知道是对1还是0的确认呢?所以得编号

需要说明的是:对于数据链路层的点对点信道,往返时间比较固定,不会出现确认迟到的情况。因此,如果只在数据链路层实现停止等待协议,不用给确认分组编号。

 

注意事项:

练习题:

3.4.2 回退N帧协议

我们可以看出,停止等待协议信道利用率很低,并且如果发生超时重传的话,信道利用率更低,所以我们可以用流水线的方式发送数据分组,一次发5个,提高信道的利用率

那么我们的回退N帧协议GBN(Go -Back -N)就是在流水线的基础上设计的。利用发送窗口来限制发送方可发送的数据分组的个数。在发送窗口里面的数据分组可被连续发送,而不必等待。

发送窗口的尺寸记为WT。

如果WT的值取1就是停止等待协议。如果WT的值超过取值范围的上限,则会造成严重的错误。

接收窗口的大小为Wr:对于回退N帧协议,其取值只能为1。

 

我们先来看最简单的没差错的情况:

发送方按序发送,接收方一个一个接收,每接收一个,接收窗口就向前滑动一个位置。并给发送方发送所接收分组的确认分组。

发送方每接收一个接收方的ACK,发送窗口就向前滑动一个位置。

并且发送方可以将已发送的分组缓存清除,接收方呢就将已接收的分组交付给上层去处理。

接下来我们看看累积确认的概念:使用后退N帧协议的接收方,可以使用累积确认的机制。也就是我接收方不必啰嗦的每个都发个收到。而是收到5个分组之后再说一句收到5个了。ACKn表示N以及之前的分组全部都接收了。

使用累积的一个优势:比如你先发一个ACK1,之后又发了一个ACK4,ACK1在路上丢失了,但是最后我发送方还是接收到ACK4,不会因为ACK1的丢失而发生重传。还有其他优点:减少接收方的开销,减少网络资源的占用等。

使用累积确认的缺点:不能及时的反映接收方已经接收的信息。

 

我们来看一种出错的情况:发送方发送的数据1丢失了,5670跟着受到牵连,也不被接收方接收。那超时之后引起重传,重传的话我5670这四个倒霉蛋又被重传了一次。可见网络不好的时候,回退N帧协议的信道利用率不见得要比停止等待协议的好。

接下来我们看一看发送窗口尺寸超出上限会怎么样:

现在我Wt是8,我序号编的是0-7,接收方接收到之后,发送ACK7,但是ACK7在路上丢失了,没有正确达到发送方,超时之后,发送方重传0-7,此时接收方一看,丫的,这0-7到底是重传的还是新的啊,我也看不出来。

回退N帧协议名字的由来:一人犯错,牵连全家。

练习题:

因为该协议的发送窗口和接收窗口是不断滑动的,所以又叫滑动窗口协议。

 

3.4.3 选择重传协议SR

回退N帧协议的接收窗口只能为1,因此接收方只能按序接收正确达到的数据分组。

一颗老鼠屎会坏了一锅汤,前面只要有一个接收有误,那后面的就不能被正确接收,引起超时重传,对通信资源造成浪费。

那么我们可不可以只重传出错的那个分组,不连累其它人呢?

那我的接收窗口就不应该为1,应该大于1,哪些没错的就接受让他们先在接收方休息,只重传出错的那个,等重传的到达后他们再一起送到上一层去。这个就是选择重传协议。

需要注意:你如果想要发送方发送出错的那个分组,那你接收方就不能再采用累积确认的机制了。应该是对每一个正确到达的分组逐一确认。

这个协议需要注意的就是发送窗口和接收窗口大小的设计

 

如果发送窗口和接受窗口的尺寸超过了范围。那也会引起上面的新旧不分的问题

发送方发了0-4,接收方接收到0-4之后自己的滑动窗口就向前移动了,然后发ACK给发送方,但是ACK0丢失了。一段时间超时了,发送方重发0,但是此时滑动窗口已经不再是当年那个滑动窗口了,此时的0非当年的0。

 

练习题:

3号帧题目没说啥,那就别考虑他。

原文地址:https://www.cnblogs.com/YXBLOGXYY/p/15399748.html