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

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

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

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

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

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

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

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

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

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

并且序列号总是符合n_a≤n_r≤n_x≤n_t≤n_a+w_t的规则,证明如下：

n_a≤n_r：传送器接收到的最高确认不能高于接收方确认的最高n_r。

n_r≤n_s：完全接收的数据包的範围不能超出部分接收的数据包的结尾。

n_s≤n_t：接收到的最高报文不能高于传送的最高报文。

n_t≤n_a + w_t：传送的最高数据包同时受到接收到的最高确认和传送视窗大小的限制。

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

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

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

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

请注意，没有必要让接收视窗w_r大于传送视窗w_t，因为不需要担心接收到永远不会传送的数据包;有用範围为1≤w_r≤w_t。

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

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

[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的整体性能。