zoukankan      html  css  js  c++  java
  • 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号帧题目没说啥,那就别考虑他。

  • 相关阅读:
    微服务搭建说明(三)
    Bootstrap框架--DataTables列表示例--添加判断
    使用bootstrap-select 动态从后台加载下拉选项
    安全整改相关内容
    tomcat禁用PUT,DELETE等一些不必要的HTTP方法
    在Java web项目中防止用户注销后使用浏览器中的“后退”按钮返回注销前页面
    Tomcat修改最大连接数及查看最大连接数
    informix错误代码小结
    HTTP协议详解
    informix创建同义词
  • 原文地址:https://www.cnblogs.com/YXBLOGXYY/p/15399748.html
Copyright © 2011-2022 走看看