本节对应参考书CH7

引入

在一次链路中的数据交换中，需要涉及以下任务：

帧同步（在这门课中不重要）
流控
错误控制
寻址
控制和发送数据
链路管理

流控（flow control）

流控的作用是确保发送端发送的信息不会在因接收端处理速度不足而被忽略，也就是防止缓冲区溢出。

流控可以出现在通信协议中的任意一层，只要对等层采用流控协议即可（差错控制也是一样）。这一节只介绍了两种常见的流控手段，并没有带入特定协议，后续课程会带入协议深入介绍。

停等流控(stop & wait)

工作流程：

发信端发送信息
接收端接受
接收端就绪接收后发送ACK信息
发送端传输下一帧

这是最简单，但非常有效的流控形式。可靠性较好，但是效率较低。

通常情况下，发送端会将一个大数据块分解成更小的块进行传输，因为：

接收端buffer大小有限
越长的数据出现错误的概率越高，若出现不可纠正错误则需要重传整个数据。分解成小块后可以独立重传小数据块，数据量小。
在共享的传输介质中，通常不允许单一通信长时间占用传输介质，因为这样会造成其他终端间的通信产生较大延迟。

滑窗流控(Sliding Windows)

考虑收发两端都与一些缓存空间，因此可以连续发送一些东西而无需应答。连续发送的这些数据，就是“窗口”。例如下图，规定数据窗口为6个数据包。那么：

每一个数据帧都有一个id，下图中记为1 2 3 4 5 6 7，规定窗口大小为6帧。
发送端可以连续发送帧1 2 3 4 5 6
如果发送6时，还没有收到帧1的ACK，那么就停下
如果收到了帧1的ACK，窗口就向后滑动，可发送7

如此操作，就无需及时的应答，因此ACK数据包可以随其他必要的通信包一起发送，无需为了ACK单独发信一次。

这在实现还有一些细节差异：

例如，可以同时通知发送段1-5都收到了，这样发送端只需要一个ACK窗口就可以直接向后滑动5位。
再例如，ACK信号可以返回“最后一次接收到的正确的帧”，例如最后一次收到的正确帧是3，那窗口会滑动到4开始继续发送，这样可以同时进行流控和差错控制。
如果发送端资源空闲，线路负荷较低时，那么为保证效率，发送端可以在接收到ACK之前反复重发窗内数据。

什么时候用停等，什么时候用滑窗？

随着不同的载波、介质、帧长度不同，会出现下图两种不同的情况。第一种是接收端已经开始收到了发送的信号，发送端的帧还没完。情况二是帧非常短，发送端发了之后就进入空闲等待了。

对于情况1，可使用停等，因此比特流本身较长，采用滑窗机制提前发送意义不大。
对于情况2，有大量的信道资源被浪费，因此可以使用滑窗机制来提高比特流长度，减少信道空闲时间。

收发机间信号临界比特长度可用如下公式计算。大于这个长度，接收端将在发送端结束发送前收到信号，是上述情况1；小于这个长度，则发送端空闲较大，是上述情况2；

$B=R\times \frac{d}{V}$

其中：

B：链路长度（单位：bit），这个链路的物理长度能容纳多长的比特流
R：数据传输速率 (单位：bps)
d：收发机间物理距离（单位：m）
V：介质中信号传播速度（单位：m/s）

差错控制（五星级)

前面介绍的流控是为了避免接收端反应速度不够，而遗漏了发送端的消息。这里的差错控制则是避免数据传输时，由于信道衰落，干扰等因素，出现帧错误、帧丢失。但是他们的手段非常类似，采用的协议也高度相似。

Automatic Repeat Request (ARQ)

Automatic Repeat Request 的简写是ARQ而非ARR！

自动请求重发（automatic repeat request）是数据通信中在接收端进行差错检测，并自动请求发送端重发的差错控制技术，简称ARQ。在ARQ中，重发要一直延续到该码字被成功地接收为止。ARQ协议有不同的实现方式。

Stop & Wait ARQ（需要掌握细节！）

停等ARQ与停等流控机制类似。

在数据正向传输过程中，可能出现两种错误，这两种错误都可以通过ACK机制解决：

到达目的地的帧可能会损坏。接收方通过错误检测可以检测到这一点，并返回帧错误，请求重发的ACK。
还有一种可能是在发送过程中出现了问题，接收方根本没有接收到这个帧。为解决这种情况源站配有计时器，发送一个帧后，源开始计时，如果到时未收到接收方的ACK信号，则再次发送相同的帧。

但是如果A发送了数据，B正确接收了数据并发送了正确接收的ACK，但是这个ACK在传回A的途中损坏了，那A又会重复发送这一帧，此时B接收了一个重复的帧。如何解决这个问题呢？

帧在发送时，会被交替地标记0或1。同样的，ACK信号也分为ACK0或ACK1，源收到一个ACK0信号，代表接收端已经准备好接受label为0的帧；收到ACK1信号，代表接收端准备好接收label为1的帧。下图展示了这一过程

在上图中，ACK0丢失导致A发送了两次frame1, B发现两次接收到的label都是1，因此知道这是同一帧，发送ACK0表示准备好接收frame0，数据传输继续进行。

Go-Back-N ARQ

Go-Back-N AQR其实就是滑窗机制+重发机制的组合。这是最常用的差错控制手段。在Go-Back-N ARQ 中，同样使用滑窗尺寸（Window size）来规定在没有收到ACK前最多一次能发多少。

确定滑窗大小的注意点：

因为对数据帧的label（即，标注帧顺序的序号）是重复使用的，因此要确保ACK上一轮回的某一序号前，不会发送新轮回的序号。例如轮回1发送了帧5，那么下一次发帧5之前就必须收到这个帧5的ACK，否则无法确认ACK的是哪一次的帧5。因此，滑窗的大小必须小于帧label数量的大小。
Go-Back-N差错控制与滑窗流控基本一致。如果出现错误，则会将从错误帧开始往后的帧全部丢弃，并从错误帧开始重发。因此如果Window Size太大，会对网络资源造成较大占用。

控制流程：

发送端A发送一串帧给B
如果B校验全部正确，则会发送RR(Receive Ready)作为ACK；
如果B校验不正确，则会发送REJ(reject)作为ACK；
一旦A收到REJ，则必须从错误帧开始全部重发

实际传输过程中，会出现如下情况：

A->B过程中，帧$i$损坏,但A还在持续发送：当收到$i+1$时，B发现缺失了$i$，帧顺序不对，B发送$REJ\ i$,$i$后续的帧都被丢弃了，A从$i$开始重传。
A->B过程中，帧$i$损坏，但A没有后续帧要发送或必须等待收到ACK后再发送：此时B没有达到规定需要发ACK的帧个数，因此不会返回ACK信号。此时A中时钟继续计数，当超时时，A发送一个 Poll bit为1的RR帧，B会将此帧作为一个命令处理，B必须发送一个指明其需要的下一帧label的ACK。当A收到ACK后，它从该label开始重传。
B->A过程中，帧$i$的RR信号损坏，后续RR信号正常抵达：因为RR信号是持续的，例如收到了RR6，表明RR5也得到了确认，因此在等待$i$的ACK计时器超时前，可以通过后续的RR对$i$进行确认。
B->A过程中，$i$帧的REJ信号损坏：由于B发送了REJ，因此后续的帧都将被丢弃。A在超时未收到ACK后发送RR帧，待B ACK期望帧后继续传输。

这种差错控制方式实现较为简单，且可以复用为滑窗流控。但是一旦出现错误，会丢弃很多帧，这对资源是一种浪费。

Selective-Reject ARQ (要求完全掌握)

相较于Go-Back-N ARQ，Selective-Reject (ARQ)流程相似，但不会丢弃错误帧之后收到的帧，提高效率。以A发送端，B为接收端：

在SR ARQ模式下，当错误出现时，B会发送”Selective Reject （SREJ）”，并将后续收到的帧存在自己的缓存中。则是SR-ARQ与Go-Back-N的核心区别。
A收到SREJ后，立马重发SREJ指定的帧，重发之后继续发送滑窗内剩下的内容。
B收到更正后，会立马发送一次ACK来更新A的窗。
若ACK信号丢失，处理机制和Go-Back-N一致。

在上图中，帧4丢失。因此B发送SREJ4，同时暂存后续的帧5和6。收到SREJ4后，立马重发4，重发后继续发送5 6后续的帧7，B收到后立马回复RR来刷新A的窗。

若B的RR丢失，A在Timer超时后，会发送RR （Poll bit = 1）来要求B发送RR，并在收到B的RR后再继续发送下面的帧。