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

通过限制在任何给定时间可以发送或接收的数据包的数量，滑动窗口协议允许使用固定大小的序列号传送无限数量的数据包。发送方侧的术语“窗口”表示接收方尚未确认的分组总数的逻辑边界。接收方在每个确认包中通知发送器当前的最大接收缓冲区大小（窗口边界）。 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的所有分组，但是对于na和ns之间的分组是不确定的,即na≤nr≤ns（nr的结果在此时可能还没有传回到发送方）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

由于停止等待协议效率太低，因此有了回退n-步协议，这也是滑动窗口协议真正的用处，这里发送的窗口大小为n，接受方的窗口仍然为1。具体看下面的图，这里假设n=10： 首先发送方一口气发送9个数据帧，前面两个帧正确返回了，数据帧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的整体性能。