数据链路层的协议一个很重要的功能就是进行流量控制，那么链路层是怎么进行流量控制的呢？
首先什么是流量控制？为什么要进行流量控制？
我们看下面链路的一跳。发送发给接受方发送数据，如果发送方每1秒发送100包，接收方只能1秒处理50包，会出现什么现象呢？接收方会在缓存中大量缓存接受的包，直到缓存区满了。满了之后会怎么样？接着就会出现最不能容忍的情况，缓冲区溢出，也就是丢包的现象。所以接收方一定要在缓冲区快满的时候通知发送方让他降低发送速度，这就是链路层的流量控制。流量控制用于确保实体发送的数据不会覆盖接受实体已接收的数据。
那么流量控制有那些方法呢？主要有两种：停-等流量控制和滑动窗流量控制。下面具体解释一下：
-
停等流量控制：发送实体发送一个帧，接受实体接收处理完之后必须发回一个对于这个帧的确认表示自己同意接收下一个帧；发送方收到这个确认之后，才能发送下一个帧。所谓停等，接收方能够简单的通过停止发送确认的方式来阻止数据流的发送。
停等方式的有点很明显：它的控制非常简单，发送方除了数据就是接收确认，接受方每次就发送一个确认就行。但是他也有很明显地缺点：它的效率不高。考虑下面这个情景：如果发送一个包长424b,两端相距1000km,
光纤的传输数据速率为155Mbps，那么传播时间（实体发送数据的时间）Tframe是424/155000000 = 2.710^-6.
但是在介质中的传输时间Tprop却达到了100000/30000000 = 0.3310^-2. 对于停等协议，效率只有α=
Tframe/(Tframe+2*Tprop)=0.04% 。也就是线路很长时间都是空闲的，效率很差。 -
滑动窗口流量控制 所以我们很自然的想到，既然任何时刻都只有一个发送效率很低，那么我们一次发送n个，然后等待一个确认，不就会让效率高了吗？这个就是滑动窗口协议的思想。滑动窗口协议：利用窗口控制连续发送的数据量。注意：必须为每一个帧分配一个序号，接收端需要按照序号接收，进行校验是否出错。
如上图所示，发送窗口为5，所以一次最多就能发送五个帧；接受窗口只有1个，所以一次只能接收1帧。这里可以看出来，发送窗口和接受窗口不一样大也是可以的。发送方一次发送5个帧，接收方收到之后予以确认，发方收到确认之后窗口前移，接着发送下面的帧（5,6,7,0…）。收方发送确认之后窗口也要前移，等待下一个帧的接收。
这里应该注意：第一，序号是循环使用的，这很好理解，因为一共就那么多存储空间，肯定从7之后要回到0否则一直增大下去就会没有存储空间的。第二，滑动窗口只是一个序号，滑到这个窗口就发送或接收对应的帧，而不是代表窗口里面是这个帧。事实上应该是有专门的缓冲区来存这些帧，滑动窗滑到那里，就对应滑动窗的序号去缓冲区取那个有帧号的帧就行了。
我们看上面这个图。最开始在滑动窗口中的是0~4一共5帧，接受方滑动窗口只有1帧，序号为0. 发送方一次发送了两个帧0,1，那么滑动窗滑了2位，帧号变成了2~6，接收方收到了0,1，那么他的滑动窗也就变成了2，表示下一步我期待接收的是帧序号为2的帧，再给发送方发送ACK2,表示我正确接受了前两帧（0和1），等待开始接收2帧了。更具体来说：
发送方连续发送了5帧之后，每次再发送，窗口的 下限 前移（窗口变小），每次接收到之前的确认，窗口的 上限 前移（窗口变大变回原来的大小）。而对于接收方，每次接收到帧之后，窗口的 下限 前移（窗口减小），收到帧确认无误发送了确认之后， 窗口的 上限 前移（窗口变大，变回原来大小）。这样保证接收方和发送方的窗口大小都保持相对不变，不会随着发送过了一段时间变大或者变小。
对于发送方，他只能发送发送窗口内序号对应的帧。对于接收方来说，发送确认的前提条件是他接收到的帧落在自己的接受窗口里面，并且校验正确，这样才能发回确认，发回确认之后再把自己的窗口上限前移。
对于滑动窗口协议，它的效率明显变高了，因为它可以一直发送。如果窗口大小N要大于传输延迟和发送时间之和T（这个时间可以理解为一个帧从发送，到信道中的时间，再到确认返回的时间三者之和），那么就可以一直发送了，所以效率可以达到100%。如果N<T，那么最多把N个帧一起发送，没法再多发送了，因为循环序号的问题，不能同时存在两个同样序号的帧，所以最多一次发送N个帧，信道会有空闲，效率为N/T。
不论是停等协议还是滑动窗口协议，都是通过接收方把自己的反馈（ACK）发送给接受方, 发送方通过这个反馈判断接收方的状态再进行发送。停等协议是滑动窗口协议的特殊版（WT=1）而已。这就是链路层用于流量控制的方法。
</div>