Bootstrap

​数据链路层——流量控制&可靠传输机制 ​

https://www.cnblogs.com/nekodream/p/18048072

数据链路层的流量控制

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

数据链路层的流量控制是点对点的,而传输层的流量控制是端到端的。

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

传输层流量控制手段:接收端给发送端一个窗口公告,高速发送端还能发多少

流量控制的方法

  • 停止-等待协议:每发送完一个帧就停止发送,等待对方的确认,在收到确认后再发送下一个帧。

  • 滑动窗口协议:发送窗口内的帧可以逐个发送,但是只有受到对应接受窗口的确认帧,发送窗口才会后移

    image-20240229162614022

    所以停等协议可以理解为发送窗口只有一位的滑动窗口

    • 后退N帧协议(GBN)
    • 选择重传协议

image-20240229162743850

可靠传输、滑动窗口、流量控制区别

可靠传输:发送端发啥,接收端收啥。

流量控制:控制发送速率,使接收方有足够的缓冲空间来接收每一个帧。

滑动窗口解决1、可靠传输(发送方自动重传) 2、流量控制(收不下就不给确认,想发也发不了)

1、停等协议

停等协议究竟放在哪一层?因为技术进步,链路层很靠谱了,所以可以放到传输层里。

为什么要有停等协议

除了比特出差错,底层信道还会出现丢包问题。为了实现流量控制。

丢包:物理线路故障、设备故障、病毒攻击、路由信息错误等原因,会导致数据包的丢失。

研究停等协议的前提

  • 虽然现在常用全双工通信方式,但为了讨论问题方便,仅考虑一方发送数据(发送方),一方接收数据(接收方)

  • 因为是在讨论可靠传输的原理,所以并不考虑数据是在哪一个层次上传送的。(究竟是在哪一层?)

  • “停止-等待”就是每发送完一个分组就停止发送,等待对方确认,在收到确认后再发送下一个分组。

停等协议——无差错情况

image-20240229163337419

确认帧:ACK

停等协议——有差错情况

1、数据帧丢失或检测到帧出错——超时自动重传

超时计时器:每次发送一个帧就启动一个计时器。设置的时间应该比往返传播时延RTT更长一些

image-20240229163531500

为了重传顺利:

  • 发完一个帧后,必须保留它的副本。
  • 数据帧和确认帧必须编号。

2、确认帧(ACK)丢失——超时重传,接收方丢弃重复帧

image-20240229163732082

3、确认帧(ACK)迟到——丢弃重复的ACK

第一个ACK0,收下就丢弃。因为已经收到过一个ACK0了!!!

image-20240229224146011

性能分析

简单!

但是信道利用率太低!

利用率计算

信道利用率

什么是信道利用率?

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

image-20240229225112159

image-20240229224836005

发送时延

往返时延

确认时延

信道利用率:

image-20240229224915372

信道吞吐率

信道吞吐率=信道利用率*发送方的发送速率

例题:一个信道的数据传输率为4kb/s ,单向传播时延为30ms ,如果使停止-等待协议的信道最大利用率达到80%,要求的数据帧长度至少为

设数据帧的长度为L比特,则发送方发送全部的数据需要时间:L/4。再除以总时长:发送时间+往返时间(2*30)

image-20240229225228754

;