滑动窗口协议

滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。

中文名: 滑动窗口协议
外文名: Sliding Window Protocol

类型: 可靠数据传输协议
层次结构: 4层

背景

编辑

如果过多的源同时以很快的速度发送大量的数据包，而此时接收方并没有如此高的接收数据的能力，因此极易导致网络的拥塞。所以，为了控制发送方的发送速度，防止发送方并考虑到受发送缓冲区大小的制约等，要求对发送方已发出但尚未经确认的帧的数目加以限制，同时使网络的传输效率得到提高，滑动窗口协议应运而生，它使得发送方可以在未收到确认的情况下，同时发送多个数据分组，由此大大提升了网络吞吐量。

在任何基于自动重发请求进行错误控制的通信协议中，接收方必须确认收到的数据包。如果发送方在合理的时间内没有收到确认，则重发数据。没有听到确认的发送方不知道接收方是否实际接收到分组（数据可能在传输中丢失或损坏）。如果错误检测显示损坏，则数据包将被接收方忽略，并且不会发送确认。因为网络传输的时延，将有大量时间被用于等待确认，导致传输效率低下。

定义

编辑

传输的每个部分被分配唯一的连续序列号，接收方使用数字并以正确的顺序放置接收到的数据包，丢弃重复的数据包并识别丢失的数据。

协议中规定，对于窗口内未经确认的分组需要重传。这种分组的数量最多可以等于发送窗口的大小，即滑动窗口的大小n减去1（因为发送窗口不可能大于（n-1），起码接收窗口要大于等于1）。

滑动窗口协议必须保证数据包的按序传输，发送窗口中的序列号代表已发送但尚未收到确认的数据包，发送窗口可持续地维持一系列未经确认的数据包，因为发送方窗口内的数据包可能在传输过程中丢失或损坏，所以发送过程必须把发送窗口中的所有数据包保存起来以备重传。发送窗口一旦达到最大值，发送过程就必须停止接收新的数据包，直到有空闲缓存区。接收窗口外的数据包都要丢弃，当序列号等于接收窗口下限的数据包到达时，把它提交给应用程序并向发送端发送确认，接收窗口向前移动一位。发送窗口和接收窗口上下限无需相同，大小也无需相同，但接收窗口大小需保持固定，发送窗口大小可随着数据包而改变。[1]

滑动窗口协议的时间线

工作机制

编辑

工作原理

通过限制在任何给定时间可以发送或接收的数据包的数量，滑动窗口协议允许使用固定大小的序列号传送无限数量的数据包。发送方侧的术语“窗口”表示接收方尚未确认的分组总数的逻辑边界。接收方在每个确认包中通知发送器当前的最大接收缓冲区大小（窗口边界）。 TCP报头使用16位字段向发送方报告接收窗口大小。因此，可以使用的最大窗口是2^16 = 64千字节。在慢启动模式下，发送器以低分组计数器开始，并且在从接收方接收到确认分组之后增加每个传输中的分组数量。对于接收的每个ACK分组，该窗口通过一个分组（逻辑地）滑动以传送一个新分组。当达到窗口阈值时，发送器发送一个包，用于接收到的一个ACK分组（确认分组）。如果窗口限制为10个数据包，则在慢启动模式下，发送器可以开始发送一个数据包，后跟两个数据包（发送两个数据包之前必须接收一个数据包），其次是三个数据包等等，直到10个数据包。但是在达到10个分组之后，进一步的传输被限制为一个接收到的一个分组发送的分组。在仿真中，看起来好像窗口对于接收到的每个ACK分组移动一个分组距离。在接收方侧，窗口也会为接收到的每个数据包移动一个数据包。滑动窗口方法可以确保网络上的交通拥堵得以避免。应用层仍将提供传输到TCP的数据，而不用担心网络流量拥塞问题，因为发送方和接收方的TCP实现分组缓冲区的滑动窗口。窗口大小可能根据网络流量而动态变化。

操作

发送方和接收方分别具有当前序列号nt和nr。它们各自还有一个窗口大小wt和wr。窗口大小可能会根据网络流量的变化而有所不同，但是在更简单的实现中它们是固定的。窗口大小必须大于零才能进行任何操作。

通常情况下，nt是要发送到下一个分组，即尚未发送的第一分组的序列号。同样地，nr尚未收到的第一个分组的序列号。这两个序列号会随着时间逐渐增加。

接收方还可以跟踪未接收到的最高序列号，变量ns比接收到的最高序列号还多一。对于仅接受数据包（wr = 1）的简单接收方，这与nr相同，但如果wr> 1，则可以更大。注意区别：已经收到nr以下的所有数据包，没有接收到ns以上的任何数据包，在nr和ns之间，已经收到一些数据包。

当接收方接收到一个数据包时，它会适当地更新其变量，并用新的nr发送确认。发送方跟踪其收到的最高确认。发送方知道已经接收到但不包括na的所有分组，但是对于na和ns之间的分组是不确定的,即na≤nr≤ns。

并且序列号总是符合na≤nr≤nx≤nt≤na+wt的规则,证明如下：

na≤nr：发送器接收到的最高确认不能高于接收方确认的最高nr。

nr≤ns：完全接收的数据包的范围不能超出部分接收的数据包的结尾。

ns≤nt：接收到的最高报文不能高于发送的最高报文。

nt≤na + wt：发送的最高数据包同时受到接收到的最高确认和发送窗口大小的限制。

发送方操作

每当发送方具有要发送的数据时，它可以在最新的确认na之前传输序列号高达wt数据包。也就是说，只要nt<na + wt，它可以传送分组号nt。

在没有通信错误的情况下，发送方很快就会收到所有发送的数据包的确认信息，这等于nt。如果在合理的延迟之后不会发生这种情况，则发送方必须在na和nt之间重传数据包。

接收方操作

每次接收到一个编号为x的数据包时，接收方检查它是否落入接收窗口，nr≤x<ns + wr。（最简单的接收方只需要跟踪一个值nr =ns。）如果它落在窗口内，接收方接受它。如果编号为nr，则接收序列号增加1，并且如果先前接收和存储更多的连续分组，则可能更多。如果x> nr，则存储数据包直到接收到所有先前的数据包为止。如果x≥ns，后者更新为ns = x + 1。

如果数据包的序列号不在接收窗口内，则接收方将丢弃该数据包，并且不修改nr或ns。无论数据包是否被接受，接收方发送包含当前nr的确认。（确认还可以包括关于nr或ns之间接收的附加数据包的信息，但这只能帮助效率。）

请注意，没有必要让接收窗口wr大于发送窗口wt，因为不需要担心接收到永远不会发送的数据包;有用范围为1≤wr≤wt。

应用场景

编辑

滑动窗口协议以基于分组的数据传输协议为特征。因此该协议适用于对按顺序传送分组的可靠性要求较高的环境，例如在数据链路层（OSI模型）以及传输控制协议（TCP）中。 [2]

增强应答的链路层重传，在长线传输中，因软故障造成的消息传输错误占据了绝大部分，对于这些问题的解决可以是系统的可靠性大大提高。这种机制，向通过实现简单、检突发错误能力高的CRC码的校验进行错误检查，再由相应的滑动窗口协议实现重传恢复。 [3]

应用实例

编辑

[1] 停止等待协议（stop-and-wait）

停止等待协议示意图

这时接受方的窗口和发送方的窗口大小都是1，1个比特就够表示了，所以也叫1比特滑动窗口协议。发送方这时自然发送每次只能发送一个，并且必须等待这个数据包的ACK，才能发送下一个。虽然在效率上比较低，带宽利用率明显较低，不过在网络环境较差，或是带宽本身很低的情况下，还是适用的。

存在的问题是，当发送方交替发送标记为“奇数”和“偶数”的数据包。发送的确认同样为“奇数”和“偶数”。假设已经发送了奇数分组的发送方没有收到奇数确认，而是立即发送下一个偶数分组，在此之后它可能会收到一个确认，为“下一个奇数包”。这将使发送方出现不确定因素：接收方有可能接收到这两个数据包，或者两者都没接收到。

[2]回退n步协议（GO-BACK-N）

回退N-步协议示意图

由于停止等待协议效率太低，因此有了回退n-步协议，这也是滑动窗口协议真正的用处，这里发送的窗口大小为n，接受方的窗口仍然为1。具体看下面的图，这里假设n=9：首先发送方一口气发送10个数据帧，前面两个帧正确返回了，数据帧2出现了错误，这时发送方被迫重新发送2-8这7个帧，接受方也必须丢弃之前接受的3-8这几个帧。后退n协议的好处无疑是提高了效率，但是一旦网络情况糟糕，则会导致大量数据重发，反而不如上面的停等协议。

存在的问题在于，假设我们使用3位序列号，这是HDLC的典型值。这使得N =

= 8。由于wr = 1，我们必须限制wt≤7。这是因为在发送7个数据包之后，有8个可能的结果：0到7个数据包都可能被成功地接收。这有8种可能性，发送方在确认中需要足够的信息来区分它们。如果发送方发送8个数据包而不等待确认，则可能会发现自己存在和停止等待协议一样的问题：这意味着所有8个数据包都可能被成功接收，亦或是一个都没有被成功接收。

[3]选择重传协议（selective repeat）

后退n协议的另外一个问题是，当有错误帧出现后，总是要重发该帧之后的所有帧，毫无疑问在网络不是很好的情况下会进一步恶化网络状况。

重传协议便是用来解决这个问题。原理也很简单，接收端总会缓存所有收到的帧，当某个帧出现错误时，只会要求重传这一个帧，只有当某个序号后的所有帧都正确收到后，才会一起提交给高层应用。重传协议的缺点在于接受端需要更多的缓存。

存在的问题在于：最为普遍的HDLC协议使用3位序列号，并具有选择性重复的可选条件。但是，如果使用选择性重复，则必须保持nt +nr≤8的要求;如果wr增加到2，则wt必须降低到6。假设wr = 2，但是与wt = 7一起使用未修改的发射机。进一步假设接收器以nr = ns = 0开始。
　　现在假设接收器看到以下一系列数据包（均为模8）：
　　0 1 2 3 4 5 6（暂停）0
　　由于wr = 2，接收方将接受并存储最终的数据包0（在系列中认为它是数据包8），同时请求重发数据包7。.然而，发送方也不可能接收到任何确认，并且在后一种情况下，接收机将接收错误的分组作为分组8。解决方案是发送方限制wt≤6。通过这种限制，接收方在接收到分组6后知道发送方的na≥1，并且因此编号为0的后续分组必须是分组8。如果所有确认丢失，则发送方将不得不在分组5之后停止。

注意事项

编辑

（1）发送方不必发送一个全窗口大小的数据。

（2）来自接收方的一个报文段确认数据并把窗口向右边滑动，这是因为窗口的大小是相对于确认序号的。

（3）窗口的大小可以减小，但是窗口的右边沿却不能够向左移动。

（4）接收方在发送一个ACK前不必等待窗口被填满。

协议改进

编辑

由于“滑动窗口”协议的性能取决于窗口大小和网络接收数据包的速度，在流量不稳定的环境中，性能下降甚至可能会使网络发生冲突。为了避免和提供端到端流量控制，可以建议“慢启动”协议。

对于该协议的改进主要集中在如何减少TCP报文重传方面，目前在TCP中每传输一个报文都要求接收方进行确认，大量短而频繁的确认报文给网络带来了很多开销。因此采取了延迟ACK策略来减少ACK的数量，就是接收方收到一个报文以后，不会立即发送ACK，而是等待1~200ms，这期间若有回送数据报文就捎带确认，但收到两个连续数据报文或者等待超时则发送一个独立确认。有效减少了ACK的数量，改善了TCP的整体性能。 [4]

TCP滑动窗口机制

TCP滑动窗口机制

我们可以大概看一下上图的模型：

首先是AB之间三次握手建立TCP连接。在报文的交互过程中，A将自己的缓冲区大小（窗口大小）3发送给B，B同理，这样双方就知道了对端的窗口大小。

A开始发送数据，A连续发送3个单位的数据，因为他知道B的缓冲区大小。在这一波数据发送完后，A就不能再发了，需等待B的确认。

A发送过来的数据逐渐将缓冲区填满。

这时候缓冲区中的一个报文被进程读取，缓冲区有了一个空位，于是B向A发送一个ACK，这个报文中指示窗口大小为1。

A收到B发过来的ACK消息，并且知道B将窗口大小调整为1，因此他只发送了一个单位的数据并且等待B的下一个确认报文。

如此反复。

什么是滑动窗口协议？
一图胜千言，看下面的图。简单解释下，发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，而导致溢出，同时控制流量也可以避免网络拥塞。下面图中的4,5,6号数据帧已经被发送出去，但是未收到关联的 ACK，7,8,9帧则是等待发送。可以看出发送端的窗口大小为6，这是由接受端告知的（事实上必须考虑拥塞窗口cwnd，这里暂且考虑 cwnd>rwnd）。此时如果发送端收到4号ACK，则窗口的左边缘向右收缩，窗口的右边缘则向右扩展，此时窗口就向前“滑动了”，即数据帧10 也可以被发送。

下面就滑动窗口协议做出更详细的说明，这里为了简单起见设定发送方窗口大小为2，接受方大小为1。看下面图：

一：初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；
二：发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；
三：发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；
四：接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；
五：发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变
六：发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；
七：接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；
八：发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。

1比特滑动窗口协议?
上面说的只是滑动窗口协议的理论，实际应用中又有不同。首先就是停等协议(stop－and－wait)，这时接受方的窗口和发送方的窗口大小都是1，1 个比特就够表示了，所以也叫1比特滑动窗口协议。发送方这时自然发送每次只能发送一个，并且必须等待这个数据包的ACK，才能发送下一个。虽然在效率上比较低，带宽利用率明显较低，不过在网络环境较差，或是带宽本身很低的情况下，还是适用的。看下面的流程图：

后退n协议?
    停等协议虽然实现简单，也能较好的适用恶劣的网络环境，但是显然效率太低。所以有了后退n协议，这也是滑动窗口协议真正的用处，这里发送的窗口大小为n，接受方的窗口仍然为1。具体看下面的图，这里假设n=9：
    首先发送方一口气发送10个数据帧，前面两个帧正确返回了，数据帧2出现了错误，这时发送方被迫重新发送2-8这7个帧，接受方也必须丢弃之前接受的3-8这几个帧。
    后退n协议的好处无疑是提高了效率，但是一旦网络情况糟糕，则会导致大量数据重发，反而不如上面的停等协议，实际上这是很常见的，具体可以参考TCP拥塞控制。

选择重传协议？
后退n协议的另外一个问题是，当有错误帧出现后，总是要重发该帧之后的所有帧，毫无疑问在网络不是很好的情况下会进一步恶化网络状况，重传协议便是用来解决这个问题。原理也很简单，接收端总会缓存所有收到的帧，当某个帧出现错误时，只会要求重传这一个帧，只有当某个序号后的所有帧都正确收到后，才会一起提交给高层应用。重传协议的缺点在于接受端需要更多的缓存。

TCP滑动窗口易错处

前段时间研究分布式时写了一个可扩展的服务器组程序，服务器组之间通信时老是达不到想要的性能。后来抓包排查，原来是TCP滑动窗口引起的问题，本来是很基础的东西，奈何当初没有太在意，导致错误的产生，现在详细写出来，忘不太清楚者警惕！

滑动窗口的基本情况我有必要废话一下。TCP通信为了保证可靠性，每次发送的数据都需要得到对方的ACK才确认对方收到了(仅保证对方TCP接收缓冲收到数据了，但不保证对方应用程序取到数据了)，这时如果每次发送一次就要停下来等着对方的ACK消息，显然是一种极大的资源浪费和低下的效率，这时就有了滑动窗口的出现。

发送方的滑动窗口维持着当前发送的帧序号，已发出去帧的计时器，接收方当前的窗口大小(由接收方ACK通知，大体等于接收缓冲大小-未处理的消息包)，接收方滑动窗口保存的有已接收的帧信息、期待的下一帧的帧号等，至于滑动窗口的具体工作原理这里就不说了。

一个socket有两个滑动窗口(一个sendbuf、一个recvbuf)，两个窗口的大小是通过setsockopt函数设置的，现在问题就出在这里，通过抓包显示，设置的窗口大小没有生效，最后排查发现setsockopt函数是后来加上的，写到了listen函数的后面，这样每次accept出的socket并没有继承得到主socket设置的窗口大小，无语啊……

解决办法：setsockopt函数提前到listen函数之前，这样在服务器程序启动监听前recvbuf就已经有了，accept后的链接得到的就是recvbuf了，启动程序运行，抓包显示窗口已经是指定的大小了。

网络编程其实很简单，任何人都可以写出一套自己的服务器框架，但是细节决定成败，性能的高低有时候就是几个小细节决定的（当然这里说的这个问题是个编程错误，不属于可优化的细节问题）

前言

你现在的努力，是为了以后有更多的选择。

在上一篇文章通过“表白”方式，让我们快速了解网络七层协议了解了网络七层协议。
接下来我们要把重心放在网络传输的可靠性上面。一起来看TCP协议，它是如何解决网络传输不可靠的问题。这其中有个很关键的部分，就是我们的滑动窗口协议。

从工程学角度上，我们来看一看滑动窗口协议，它到底解决了一个怎样的问题？

滑动窗口协议：

TCP协议的使用
维持发送方/接收方缓冲区
缓冲区是用来解决网络之间数据不可靠的问题，例如丢包，重复包，出错，乱序

在TCP协议中，发送方和接受方通过各自维护自己的缓冲区。通过商定包的重传机制等一系列操作，来解决不可靠的问题。

问题一：如何保证次序？

提出问题：在我们滑动窗口协议之前，我们如何来保证发送方与接收方之间，每个包都能被收到。并且是按次序的呢？

问题1 发送方发送一个包1，这时候接收方确认包1。发送包2，确认包2。就这样一直下去，知道把数据完全发送完毕，这样就结束了。那么就解决了丢包，出错，乱序等一些情况！同时也存在一些问题。问题：吞吐量非常的低。我们发完包1，一定要等确认包1.我们才能发送第二个包。

问题二：如何提高吞吐量？

提出问题：那么我们就不能先连发几个包等他一起确认吗？这样的话，我们的速度会不会更快，吞吐量更高些呢？

改进方案如图，这个就是我们把两个包一起发送，然后一起确认。可以看出我们改进的方案比之前的好很多，所花的时间只是一个来回的时间。接下来，我们还有一个问题：改善了吞吐量的问题

问题三：如何实现最优解？

问题：我们每次需要发多少个包过去呢？发送多少包是最优解呢？

我们能不能把第一个和第二个包发过去后，收到第一个确认包就把第三个包发过去呢？而不是去等到第二个包的确认包才去发第三个包。这样就很自然的产生了我们"滑动窗口"的实现。
在图中，我们可看出灰色1号2号3号包已经发送完毕，并且已经收到Ack。这些包就已经是过去式。4、5、6、7号包是黄色的，表示已经发送了。但是并没有收到对方的Ack，所以也不知道接收方有没有收到。8、9、10号包是绿色的。是我们还没有发送的。这些绿色也就是我们接下来马上要发送的包。可以看出我们的窗口正好是11格。后面的11-16还没有被读进内存。要等4号-10号包有接下来的动作后，我们的包才会继续往下发送。

正常情况

正常情况可以看到4号包对方已经被接收到，所以被涂成了灰色。“窗口”就往右移一格，这里只要保证“窗口”是7格的。我们就把11号包读进了我们的缓存。进入了“待发送”的状态。8、9号包已经变成了黄色，表示已经发送出去了。接下来的操作就是一样的了，确认包后，窗口往后移继续将未发送的包读进缓存，把“待发送“状态的包变为”已发送“。