数据链路层–流量控制和可靠传输

Kapler9

已于 2022-10-19 21:27:23 修改

阅读量1.6k

点赞数

文章标签：网络

于 2022-10-16 01:14:48 首次发布

本文链接：https://blog.csdn.net/chlet/article/details/127343174

版权

流量控制（接收方控制发送方速度）：

场景：

发送方：发送数据速率高。
接收方：接收数据能力差。

基本方法：接收方控制发送方发送数据的速率；

常见方法：

1.停止-等待协议

2.滑动窗口协议：后退N帧协议（GBN）、选择重传协议（SR）

与传输层的流量控制对比：

1.对象

数据链路层的流量控制是点对点的;是每两个相邻节点间的流量控制，如主机到路由器,路由器到路由器；

传输层的流量控制是端到端的，是两个主机端的流量控制；

2.机制

数据链路层的流量控制，如果接收方接收不了就不再给发送方发送确认帧，发送方长时间未收到确认帧或收到NAK等根据具体情况重传数据帧；

传输层的流量控制，通过**“告诉”发送方窗口值为多少**；

停止-等待协议：

发送方必须收到接收方发送的上一帧的确认才能继续发送下一帧；

信道占用率：
$\frac{\frac{帧长度}{数据传输速率}}{\frac{帧长度}{数据传输速率}+RTT+\frac{确认帧长度}{数据传输速率}}$
滑动窗口的思想来看：发送窗口=1，接收窗口=1；

需要和自动重传结合，否则可能会陷入发送方一直等待的死锁状态；

滑动窗口协议：

后退N帧协议（GBN）：

发送窗口控制发送端的发送速率

接收窗口=1的意义

发送端每收到一个确认帧，发送窗口就向前滑动一个帧的位置，当发送窗口内没有可以发送的帧（即窗口内的帧全部是己发送但未收到确认的帧），发送方就会停止发送，直到收到接收方发送的确认帧使窗口移动，窗口内有可以发送的帧，之后才开始继续发送。

接收端收到数据帧后，将窗口向前移一个位置，并发回确认帧，若收到的数据帧落在接收窗口之外则一律丢弃。

发送方：

上层的调用

上层要发送数据时，发送方先检查发送窗口是否已满，如果未满，则产生一个帧并将其发送，如果窗口已满，发送方只需将数据返回给上层，提示上层窗口已满，上层等一会再发送。（实际情况是发送方先缓存这些数据，窗口空闲时再发送）

收到了一个ACK帧

GBN协议中，对n帧的确认采用累积确认的方式，标明接收方已经收到n帧和它之前的全部帧。

超时

与停止-等待协议一样，如果出现超时，发送方重传所有已发送但未被确认的帧。

接收方：

如果正确收到n号帧，并且按序，那么接收方为n帧发送一个ACK确认帧，并将帧中的数据部分交付给上层。其余情况都丢弃帧，并为最近按序接收的帧重新发送ACK，接收方无需缓存任何失序帧，只需要维护一个信息，就是下一个按序接收的帧序号。意思是不是按序收到的帧都会被丢弃，并且不会回复确认帧。

发送方窗口最大为 2n - 1，接收窗口大小为1

一个小题目：

答案：B

解析：（这里的窗口大小指发送窗口+接收窗口）在连续ARQ协议中，发送窗口大小<=窗口总数-1；eg：窗口总数为8，编号为0 ~ 7，假设8个帧都已发出，下一轮又发出编号0 ~ 7的8个帧，接收方将无法判断第二轮发的8个帧到底是重传帧还是新帧。另外对于回退N帧协议，发送窗口的大小可以等于窗口总数-1，因为它的接收窗口大小为1，所有的帧保证按序接收。

滑动窗口的特性：

只有接收窗口向前滑动时（同时接收方发送了确认帧），发送窗口才有可能（只有发送方收到确认帧才是一定）向前滑动。

信道占用率：
$(RTT+\frac{确认帧长度}{数据传输速率})时间内连续发送的帧(受发送窗口的限制)以及开始的一帧，一共发送的时间除以整个发送周期$
从滑动窗口的概念看，停止-等待协议、后退 N 帧协议和选择重传协议只在发送窗口大小和接收窗口大小上有所差别：