掌握TCP/IP链路层滑动窗口协议

引语

万丈高楼平地起，靠的就是深厚的地基

什么是流量控制

流量控制涉及对链路上的帧的发送速率的控制 ，以使接收方有足够的缓冲空间来接收每一个帧。例如，在面向帧的自动重传请求系统中 ，当待确认帧的数量增加时 ，有可能超出缓冲存储空间而造成过载 。流量控制的基本方法是由接收方控制发送方发送数据的速率 ，常见的方式有两种 ： 停止-等待协议和滑动窗口协议 。

流量控制的一些知识点

1. 接收端抑制发送端的依据：接收端缓冲区的大小
2. 流量控制的目标是接收端，是怕接收端来不及处理
3. 流量控制的机制是丢包

停止-等待流量控制的基本原理

发送方每发送一帧，都要等待接收方应答信号，之后才能发送下一帧；接收方每接收一帧，都要反馈一个应答信号，表示可以接收下一帧，如果接收方不反馈应答信号，则发送发必须一直等待。每次只允许发送一帧，然后就陷入等待接收对方确认信号的过程中，因而传输效率很低。

滑动窗口流量控制的基本原理

在任意时刻，发送方都维持一组连续的允许发送的帧的序号，称为发送窗口；同时接收方也维持一组连续的允许接收的序号，称为接收窗口。发送窗口用来对发送方进行流量控制，而发送窗口的的大小 Wt 代表还没有收到对方确认信息的情况下发送方最多还可以发送多少数据帧。同理，在接收端设置接收窗口是为了控制可以接收哪些数据帧而不可以接收哪些数据帧。在接收数据方只有收到当前数据帧的序号落入接收窗口内才允许将该数据帧收下，若接收的数据帧落在接收窗口之外，则一律将其丢弃。

下图给出了发送窗口和接收窗口的工作原理。

滑动窗口的重要特性

1. 只有接收窗口向前滑动时（同时接收方发送确认帧）发送窗口才有可能（只有发送方收到确认帧才是一定）向前滑动。
2. 从滑动窗口的概念看，停止-等待协议、后退N帧协议和选择重传协议只有在发送窗口大小和接收窗口大小有区别。
   停止等待协议：发送窗口大小=1，接收窗口大小=1；
   后退N帧协议：发送窗口大小>1，接收窗口大小=1；
   选择重传协议：发送窗口大小>1，就收窗口大小>1;
3. 当滑动窗口大小为1时，可保证帧的有序接收；
4. 数据链路层的滑动窗口协议中 ，窗口的大小在传输过程中是固定的（注意与传输层的滑动窗口协议的区别）。

可靠传输机制

数据链路层的可靠传输通常使用确认帧和超市重传两种机制来完成。

确认帧是一种无数据的控制帧，这种控制帧使得接收方可以让发送方知道哪些内容被正确接收。有些情况下为了提高传输效率。将确认帧捎带在一个回复帧中，成为捎带确认。

超时重传是指发送方在发送某一个数据帧以后就开始一个计时器，在一定时间内如果没有得到发送的数据帧的确认帧，那么就重新发送该数据帧，直到发送成功为止。

自动重传请求（Auto Repeat reQuest, ARQ），通过接收方请求发送方重传出错的数据帧来恢复出错的帧，是通信中用于处理信道所带来差错的方法之一。
传统自动重传请求分为三种，即停等式（Stop-and-Wait）ARQ、后退N帧（Go-Back-N）ARQ以及选择性重传（Selective Request）ARQ。后两种协议是滑动窗口技术与请求重传技术的结合，由于窗口尺寸开到足够大，帧在线路上可以连续流动，因此又称为连续ARQ协议
。

对于停止-等待协议，由于每发送一个数据帧就停止并等待，因此用1bit编号就够。在停止-等待协议中，若连续出现相同发送序号的数据帧，表明发送端进行了超时重传。连续出现相同序号的确认帧，表明接收端收到了重复帧。
此外，为了超时重发和判定重复帧的需要，发送方和接收方都需设置一个帧缓冲区。发送端在发送完数据帧时，必须在其发送缓存中保留此数据帧的副本，这样才能在出差错时进行重传。只有在收到对方发来的确认帧ACK时，方可清除此副本。

由下图可知，停止-等待协议通信信道的利用率很低 。为了克服这一缺点 ，就产生了另外两种协议 ，即后退 N帧协议和选择重传协议。

多帧滑动窗口协议与后退N帧协议（GBN）

在后退N帧ARQ中，发送方不需要收到上一帧的ACK后才开始发送下一帧，而是可以连续发送帧。当接收方检测出失去的信息帧后，可以要求发送方重发最后一个正确接收的信息帧之后的所有未确认的帧；或者当发送方发送了N个帧后，若发现该N个帧的前一个帧被判为出错或丢失，此时发送方就不得不重传该出错帧及随后的N个帧。换句话说，接收帧方只允许按顺序接收帧。

如图所示，源站向目的站发送数据帧 。当源站发完 0 号帧后，可以继续发送后续的 1 号帧、2 号帧等。源站每发送完一帧就要为该帧设置超时计时器 。由于连续发送了许多帧，所以确认帧必须要指明是对哪一帧进行确认 。

为了减少开销 ，GBN协议还规定接收端不一定每收到一个正确的数据帧就必须立即发回一个确认帧 ，而是可以在连续收到好几个正确的数据帧后，才对最后一个数据帧发确认信息 ，或者可以在当自己有数据要发送时才将对以前正确收到的帧加以捎带确认 。这就是说 ，对某一数据帧的确认就表明该数据帧和这以前所有的数据帧均己正确无误地收到了。

在图中，ACKn 表示对第 n 号帧的确认 ，表示接收方己正确收到了第 n 号帧及以前的所有帧，下一次期望收到第 n+1 号帧 （也可能是第 0 号帧）。接收端只按序接收数据帧 。 虽然在有差错的 2 号帧之后接着又收到了正确的 6 个数据帧，但接收端都必须将这些帧丢弃。接收端虽然丢弃了这些不按序的无差错帧 ，但应重复发送己经发送过的最后一个确认帧 ACK1 （ 这是防止己经发送过的确认帧 ACK1 丢失）。

后退N帧协议的接收窗口为1，可以保证按序接收数据帧。若采用n个比特对帧编号，则期发送窗口的尺寸 Wt 应满足：1 <= Wt <= 2^n - 1。若发送窗口的尺寸大于2^n - 1，则会造成接收方无法分辨新帧和旧帧。‘

后退N帧协议一方面因连续发送数据帧而提高了信道的利用率，但另一方面，在重传时又必须把原来已发送正确的数据帧进行重传（仅因这些数据帧的前面有一个数据帧出了错），这种做法又使传送速率降低。由此可见，若信道的传输质量很差导致误码率较大时，后退N帧协议不一定优于停止等待协议。

多帧重传窗口与选择重传协议（SR）

只重传出现差错的数据帧或者是计数器超时的数据帧。

在选择重传协议中，每一个发送缓冲区对应一个计时器，当计时器超时时，缓冲区的帧就会重传。一旦接收方怀疑帧出错，就会发送一个否定帧NAK给发送方，要求发送方对NAK中指定的帧进行重传。

选择重传协议的接收窗口尺寸 Wr 和发送窗口尺寸 Wt 都大于1，一次可以发送或接收多个帧。若采用 n 比特对帧编号，为了保证接收方向向前移动窗口后，新窗口序号与旧窗口序号没有重叠部分，需要满足条件：接收窗口Wr + 发送窗口Wt <= 2^n。假定仍然采用累计确认的方法，并且接收窗口 Wr 显然不应超过发送窗口 Wt(否则无意义)，那么接收窗口尺寸不应超过序号范围的一半 Wr <= 2^(n-1)。当接收窗口为最大值时，Wtmax = Wrmax = 2^(n-1)。

选择重传协议可以避免重复传送那些本已正确到达接收端的数据帧，但在接收端要设置具有相当容量的缓冲区来暂存那些未按序正确收到的帧。接收端不能接收窗口以下或窗口上界以上的序号的帧，因此所需缓冲区的数目等于窗口的大小，而不是序号数目。

补充问题

在停止-等待协议中 ，确认帧为什么不需要序号（如用 ACK0 和 ACK1 ) ?

答：
在停止等待协议中，发送方每发送一帧，都需要等收到接收方的确认帧后，才能进行下一帧的发送，而发送方收到的确认帧也一定是 自己刚刚发出去的数据帧的确认帧,无须加序号标记。

为什么当用n个比特进行编号时 ，若接收窗口的大小为 1，则只有在发送窗口的大小 Wt <= 2^n-1 时，连续ARQ 协议才能正确运行 ?

答:
我们举一个具体的例子说明。例如用3比特可编出8个不同的序号，因而发送窗口的最大值似乎应为8。但实际上，设置发送窗口为8将使协议在某些情况下无法工作。现在我们就来说明这一点。

设发送窗口Wτ =8，发送端发送完0~7号共8个数据帧。因发送窗口已满，发送暂停。假定这8个数据帧均已正确到达接收端，并且对每一个数据帧，接收端都发送出确认帧。下面考虑两种不同的情况。

第一种情况是:所有的确认帧都正确到达了发送端，因而发送端接着又发送8个新的数据帧，其编号应当是0~7。请注意，序号是循环使用的。所以序号虽然相同，但8个帧都是新的帧。

第二种情况是:所有的确认帧都丢失了。经过一段由超时计时器控制的时间后，发送端重传这8个旧的数据帧，其编号仍为0~7。

于是，当接收端第二次收到编号为0~7的8个数据帧时，就无法判定:这是8个新的数据帧，或这是8个旧的、重传的数据帧。
因此，将发送窗口设置为8显然是不行的。

---

参考：
《计算机网络》（王道计算机考研系列）

推荐阅读：
【专题：JavaScript进阶之路】
TCP三次握手和四次挥手
AJAX原理及常见面试题
ES6 尾调用和尾递归
JavaScript之函数柯理化
浅谈 MVC 和 MVVM 模型

---

我是Cloudy，年轻的前端攻城狮一枚，爱专研，爱技术，爱分享。
个人笔记，整理不易，感谢关注、阅读、点赞和收藏。
文章有任何问题欢迎大家指出，也欢迎大家一起交流各种技术问题！