计算机网络-数据链路层(流量控制与可靠传输机制(停止等待协议、滑动窗口协议(GBN,SR)))

1. 数据链路层的流量控制与可靠传输

较高的发送速度和较低的接收能力的不匹配,会造成传输出错,因此数据链路层也要具备流量控制的功能。

注意区分:

  • 数据链路层的流量控制是点对点的(相邻节点),而传输层的流量控制是端到端的(两个主机)

  • 数据链路层流量控制手段是通过:接收方收不下就不回复确认。

    传输层流量控制手段:接收端给发送端一个窗口公告。

链路层的流量控制和可靠传输有两个手段

  1. 停止等待协议:每发送完一个帧就停止发送,等待对方的确认,在收到确认后再发送下一个帧。(效率比较低)

  2. 滑动窗口协议:发送一个发送窗口的帧,每当收到接受窗口发送的确认,发送窗口就向前滑动。

    后退N帧协议(GBN)

    选择重传协议(SR)

注意:

停止等待协议也可以看作特殊的滑动窗口协议,可以看作发送窗口和接受窗口大小都是1的情况。

后退N帧协议(GBN):发送窗口>1;接受窗口=1

选择重传机制(SR):发送窗口>1;接受窗口>1

在数据链路层的滑动窗口在发送过程中大小是确定的。

注意一组概念

可靠传输:发送端发送任何数据,接收端接受任何数据,没有差错。
流量控制:控制发送速率,使接收方有足够的缓冲空间来接收每一个帧。
通过滑动窗口可以解决流量控制和可靠传输(发送端自动重传)问题。

停止-等待协议

停止等待协议存在的意义:底层信道除了会发生比特位错误,还会出现丢包问题。为了解决丢包和流量控制的问题,就引出了停止等待协议。

有时会将停止等待协议放到传输层上,这里仅讨论可靠传输的原理,所以并不考虑数据是在哪一个层次上传送的。这里按照数据链路层的数据帧讨论

停止等待协议思路:就是每发送完一个分组就停止发送,等待对方确认,在收到确认后再发送下一个分组。

停止等待协议分为两种情况:1. 无差错 2. 有差错

  1. 无差错情况:

    假设发送方发送一个数据帧就停止等待接受方响应。发送1号帧,发送方等待到接受方发送1号帧数接受响应后继续发送其他数据帧。
    (因为发送方发送每发送1个数据帧就停止等待接受方响应,所以只需要1bit来编号即可)

  2. 有差错情况:

    • 数据帧丢失或检测到帧出错

         数据帧丢失:发送方在发送数据后,超时计时器就启动。当没有收到接受方的响应时就重传这个数据帧。
         (超时计时器设置的重传时间应当比帧传输的平均RTT更长一些。)
      
        所以就需要如下条件:
        1. 发完一个帧后,必须保留它的副本。
        2. 数据帧和确认帧必须编号。(防止接受方收到重复的数据)
      
        数据帧错误和数据帧丢失处理情况类似:接受方发现数据帧错误,直接丢弃
        不返回确认帧,让发送方重新发送。
      
    • 确认帧丢失:

        发送方没有收到ACK,继续重发原来帧,接受方收到重复帧,直接丢弃并返回确认帧 
      

停止等待协议
优点:简单。缺点:信道利用率比较低。

信道利用率:发送方在一个发送周期内,有效地发送数据所需要的时间占整个发送周期的比率。

信道吞吐量:信道吞吐率=信道利用率×发送方的发送速率

后退N帧协议(GBN)

后退N帧协议中的滑动窗口:

发送窗口:发送方维持一组连续的允许发送的帧的序号。

接收窗口:接收方维持一组连续的允许接收帧的序号。

在发送窗口内的数据帧都可以发送给接收端。
为了提高效率接受方可以累积接受一些数据帧后发送帧号最后的编号响应,代表这个编号前的帧都收到了。
在接受方接受到响应,滑动窗口向前移动。

GBN协议发送方:

  1. 网络层调用:上层要发送数据时,发送方先检查发送窗口是否已满,如果未满,则产生一个帧并将其发送;如果窗口已满,发送方只需将数据返回给上层,暗示上层窗口已满。上层等一会再发送。(实际实现中,发送方可以缓存这些数据,窗口不满时再发送帧)。
  2. 收到响应ACK:GBN协议中,对n号帧的确认采用累积确认的方式,标明接收方已经收到n号帧和它之前的全部帧。
  3. 超时事件响应:出现丢失和时延过长帧时发送方的行为时类似停等协议中一样,定时器将再次用于恢复数据帧或确认帧的丢失。如果出现超时,发送方重传所有己发送但未被确认的帧。

GBN接收方:

  1. 如果正确收到n号帧,并且排好序,那么接收方为n帧发送一个ACK,并将该帧中的数据部分交付给上层。
  2. 如果是其余情况都需要丢弃帧,并为最近按序接收的帧重新发送ACK。接收方无需缓存任何失序帧,只需要维护一个信息:expectedseqnum(下一个按序接收的帧序号)。如果这个帧序号是2,即使接收方收到的是3,4,5都不会保存,它只会保存2号帧号。

注意:滑动窗口长度不是越大越好。滑动窗口太大,接收方无法区分新帧和旧帧(因为帧号不是唯一的,是循环分配的)。滑动窗口大小W应为应满足:1≤ W ≤2n-1。(采用nbit位帧号进行编号)

GBN协议重点:

  1. 累计确认
  2. 接收方只按顺序接收帧,帧不按序则丢弃。
  3. 确认时返回收到的帧序列号最大的、按序到达的帧。
  4. 发送窗口最大为2n-1。接收窗口大小为1

性能分析:

优点:
(相比于停止等待协议)因连续发送数据帧而提高了信道利用率

缺点:

在重传时必须把原来已经正确传送的数据帧重传,是传送效率降低。

选择重传机制(SR)

针对GBN协议的弊端引出了SR协议

SR协议的解决办法:设置单个确认,同时加大接收窗口,设置接收缓存,缓存乱序到达的帧。

对于SR协议的发送方:

  1. 从上层收到数据后,SR发送方检查下一个可用于该帧的序号,如果序号位于发送窗口内,则发送数据帧;否则就像GBN一样,要么将数据缓存,要么返回给上层之后再传输。
  2. 收到ACK响应后:如果收到ACK,加入该帧序号在窗口内,则SR发送方将那个被确认的帧标记为已接收。如果该帧序号是窗口的下界(最左边第一个窗口对应的序号),则窗口向前移动到具有最小序号的未确认帧处。如果窗口移动了并且有序号在窗口内的未发送帧,则发送这些帧。
  3. 超时机制:每个帧都有自己的定时器,一个超时事件发生后只重传一个帧。

对于SR协议的接受方:

  1. SR接收方将确认一个正确接收的帧而不管其是否按序。失序的帧将被缓存,并返回给发送方一个该帧的确认帧,直到所有帧(即序号更小的帧)皆被收到为止,这时才可以将一批帧按序交付给上层,然后向前移动滑动窗口。

需要注意:

  1. 接受方只会接受在滑动窗口上的数据。

  2. 滑动窗口长度不是无限长的,窗口大小和序号编号有关,如果滑动窗口太大,接受方就不能区分帧是新帧还是旧帧。

    发送窗口大小=接受窗口大小=2n-1(n是使用n比特来对帧序号进行编号)

  3. SR协议重点:

    • 对数据帧逐一确认,收一个确认一个
    • 只重传出错帧
    • SR接受方有缓存
(1)初始化。开网络层允许;ack_expected = 0(此时处于发送窗口的下沿);next_frame_to_send = 0,frame_expected = 0(初始化正在发送的帧和期待的帧序号);nbuffered = 0(进行发送窗口大小初始化);(2)等待事件发生(网络层准备好,帧到达,收到坏帧,超时)。(3)如果事件为网络层准备好,则执行以下步骤。从网络接收一个分组,放入相应的缓冲区;发送窗口大小加1;使用缓冲区中的数据分组、next_frame_to_send和frame_expected构造帧,继续发送;next_frame_to_send加1;跳转(7);(4)如果事件为帧到达,则从物理层接收一个帧,则执行以下步骤。首先检查帧的seq域,若正是期待接收的帧(seq = frame_expected),将帧中携带的分组交给网络层,frame_expected加1;然后检查帧的ack域,若ack落于发送窗口内,表明该序号及其之前所有序号的帧均已正确收到,因此终止这些帧的计时器,修改发送窗口大小及发送窗口下沿值将这些帧去掉,继续执行步骤(7);(5)如果事件是收到坏帧,继续执行步骤(7)。(6)如果事件是超时,即:next_frame_to_send = ack_expected,从发生超时的帧开始重发发送窗口内的所有帧,然后继续执行步骤(7)。(7)若发送窗口大小小于所允许的最大值(MAX-SEQ),则可继续向网络层发送,否则则暂停继续向网络层发送,同时返回互步骤(2)等待。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

NUC_Dodamce

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值