TCP之四：TCP 滑动窗口协议 详解
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为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比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。
- 1比特滑动窗口协议：发送窗口=1，接收窗口=1；
- 后退n协议：发窗口>1，接收窗口>1；
- 选择重传协议：发送窗口>1,接收窗口>1。
1比特滑动窗口协议
当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
后退n协议
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。
选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
仍然考虑链路的延迟与带宽的乘积为8 K B，帧尺寸为1 K B的情形。让发送方在收到第一帧的A C K的同时准备发送第九帧。允许我们这样做的算法称为滑动窗口（ sliding window），时间线如图2 - 2 1所示。
1. 滑动窗口算法
滑动窗口算法工作过程如下。首先，发送方为每1帧赋一个序号（sequence number），记作S e q N u m。现在，让我们忽略S e q N u m是由有限大小的头部字段实现的事实，而假设它能无限增大。发送方维护3个变量：发送窗口大小（send window size），记作S W S，给出发送方能够发
送但未确认的帧数的上界； L A R表示最近收到的确认帧（ last acknowledgement re c e i v e d）的序号；L F S表示最近发送的帧（last frame sent）的序号，发送方还维持如下的不变式：
LAR-LFR≤RWS
当一个确认到达时，发送方向右移动L A R，从而允许发送方发送另一帧。同时，发送方为所发的每个帧设置一个定时器，如果定时器在A C K到达之前超时，则重发此帧。注意：发送方必须存储最多S W S个帧，因为在它们得到确认之前必须准备重发。
接收方维护下面3个变量：接收窗口大小（receive window size），记为RW S，给出接收方所能接收的无序帧数目的上界； L A F表示可接收帧（l a rgestacceptable frame）的序号；L F R表示最近收到的帧（last frame re ce i v e d）的序号。接收方也维持如下不变式：
LFS-LAR≤SWS
当一个具有顺序号S e q N u m的帧到达时，接收方采取如下行动：如果S e q N u m≤L F R或S e q N u m > L A F，那么帧不在接收窗口内，于是被丢弃；如果L F R＜Se q N u m≤L A F，那么帧在接收窗口内，于是被接收。现在接收方需要决定是否发送一个A C K。设S e q N u m To A C K表示未被确认帧的最大序号，则序号小于或等于S e q N u m To Ac k的帧都已收到。即使已经收到更高序号的分组，接收方仍确认S e q N u m To A c k的接收。这种确认被称为是累积的（c u m u l a t i v e）。然后它设置L F R = S e q Nu m To A c k，并调整L A F = L F R + RW S。例如，假设L F R= 5（即，上次接收方发送的A C K是为了确认顺序号5的），并且RWS = 4。这意味着L A F = 9。如果帧7和8到达，则存储它们，因为它们在接收窗口内。然而并不需要发送A C K，因为帧6还没有到达。帧7和8被称为是错序到达的。（从技术上讲，接收方可以在帧7和8到达时重发帧5的A C K。）如果帧6当时到达了（或许它在第一次丢失后又重发从而晚到，或许它只是被延迟了），接收方确认帧8，L F R置为8，L A F置为1 2。如果实际上帧6丢失了，则出现发送方超时，重发帧6。我们看到，当发生超时时，传输数据量减少，这是因为发送方在帧6确认之前不能向前移动窗口。这意味着分组丢失时，此方案将不再保证管道满载。注意：分组丢失时间越长，这个问题越严重。
注意，在这个例子中，接收方可以在帧7刚一到达时就为帧6发送一个认帧N A K（negative acknowledgment）。然而，由于发送方的超时机制足以发现这种情况，发送N A K反而为发送方增加了复杂性，因此不必这样做。正如我们已提到的，当帧7和8到达时为帧5发送一个额外的A C K是合理的；在某些情况下，发送方可以使用重复的A C K作为一个帧丢失的线索。这两种方法都允许早期的分组丢失检测，有助于改进性能。
关于这个方案的另一个变种是使用选择确认（selective acknowledgements）。即，接收方能够准确地确认那些已收到的帧，而不只是确认按顺序收到最高序号的帧。因此，在上例中，接收方能够确认帧7、8的接收。如果给发送方更多的信息，就能使其较容易地保持管道满载，但增加了实现的复杂性。
发送窗口大小是根据一段给定时间内链路上有多少待确认的帧来选择的；对于一个给定的延迟与带宽的乘积，S W S是容易计算的。另一方面，接收方可以将RW S设置为任何想要的值。通常的两种设置是：RW S= 1，表示接收方不存储任何错序到达的帧； RW S=S W S，表示接收方能够缓存发送方传输的任何帧。由于错序到达的帧的数目不可能超过S W S个，所以设置RWS >S W S没有意义。
2. 有限顺序号和滑动窗口
现在我们再来讨论算法中做过的一个简化，即假设序号是可以无限增大的。当然，实际上是在一个有限的头部字段中说明一个帧的序号。例如，一个3比特字段意味着有8个可用序号0 ~ 7。因此序号必须可重用，或者说序号能回绕。这就带来了一个问题：要能够区别同一序号的不同次发送实例，这意味着可用序号的数目必须大于所允许的待确认帧的数目。例如，停止等待算法允许一次有1个待确认帧，并有2个不同的序号。
假设序号空间中的序号数比待确认的帧数大1，即S W S ≤ M A a xS e q N u m -1 ，其中M a x Seq N u m 是可用序号数。这就够了吗？答案取决于RW S 。如果RW S = 1，那么MaxSeqNum≥SWS+1是足够了。如果RW S等于S W S，那么有一个只比发送窗口尺寸大1的M a x S e q N u m是不够的。为看清这一点，考虑有8个序号0 ~ 7的情况，并且S W S = RW S = 7。假设发送方传输帧0 ~ 6，并且接收方成功接收，但A C K丢失。接收方现在希望接收帧7，0 ~ 5，但发送方超时，然后发送帧0 ~ 6。不幸的是，接收方期待的是第二次的帧0 ~ 5，得到的却是第一次的帧0 ~ 5。这正是我们想避免的情况。
结果是，当RW S = S W S时，发送窗口的大小不能大于可用序号数的一半，或更准确地说，SWS<(Maxseqnum+1)/2直观地，这说明滑动窗口协议是在序号空间的两半之间变换，就像停止等待协议的序号是在0和1之间变换一样。唯一的区别是，它在序号空间的两半之间连续滑动而不是离散的变换。
注意，这条规则是特别针对RW S = S W S的。我们把确定适用于RW S和S W S的任意值的更一般的规则留做一个练习。还要注意，窗口的大小和序号空间之间的关系依赖于一个很明显以至于容易被忽略的假设，即帧在传输中不重新排序。这在直连的点到点链路上不能发生，因为在传输过程中一个帧不可能赶上另一个帧。然而，我们将在第5章看到用在一个不同环境中的滑动窗口算法，并且需要设计另一条规则。
3. 滑动窗口的实现
下面的例程说明我们如何实现滑动窗口算法的发送和接收的两个方面。该例程取自一个正在使用的协议，称为滑动窗口协议S W P（Sliding Window Pro t o c o l）。为了不涉及协议图中的邻近协议，我们用H L P（高层协议）表示S W P上层的协议，用L I N K（链路层协议）表示S W P下层的协议。我们先定义一对数据结构。首先，帧头部非常简单：它包含一个序号（ S e q N u m）和一个确认号（ A c k N u m）。它还包含一个标志（ F l a g s）字段，表明帧是一个A C K帧还是携带数据的帧。
其次，滑动窗口算法的状态有如下结构。对于协议发送方，该状态包括如上所述的变量L A R和L F S，以及一个存放已发出但尚未确认的帧的队列（ s e n d Q）。发送方状态还包含一个计数信号量（ counting semaphore），称为s e n d Wi n d o w N o t F u l l。下面我们将会看到如何使用它，但一般来说，信号量是一个支持s e m Wa i t和s e m S i g n a l操作的同步原语。每次调用S e m S i g n al，信号量加1，每次调用S e m Wa i t，信号量减1。如果信号量减小，导致它的值小于0，那么调用进程阻塞（挂起）。一旦执行了足够的s e m S i g n a l操作而使信号量的值增大到大于0，在调用s e m Wa i t的过程中阻塞的进程就允许被恢复。
对于协议的接收方，如前所述，该状态包含变量L F R ，加上一个存放已收到的错序帧的队列（r e c v Q）。最后，虽然未显示，发送方和接收方的滑动窗口的大小分别由常量S W S和RW S表示。
S W P的发送方是由s e n d S W P过程实现的。这个例程很简单。首先， s e m Wa i t使这个进程在一个信号量上阻塞，直到它可以发另一帧。一旦允许继续， s e n d S W P设置帧头部中的顺序号，将此帧的拷贝存储在发送队列（s e n d Q）中，调度一个超时事件以便处理帧未被确认的情况，并将帧发给低层协议。
值得注意的一个细节是刚好在调用m s g A d d H dr之前调用s t o r e _ s w p _ h d r。该例程将存有S W P头部的C语言结构（ s t a t e -> h d r）转化为能够安全放在消息前面的字节串（ h b u f）。该例程（未给出）必须将头部中的每一个整数字段转化为网络字节顺序，并且去掉编译程序加入C语言结构中的任意填充。7 . 1节将详细讨论字节顺序的问题，但现在，假设该例程将多字整数中最高有效位放在最高地址字节就足够了。
这个例程的另一个复杂性是使用s e m Wa i t 和s e n dW i n d ow N o t F u l l 信号量。S e n dWi n d o w N o t F u l l被初始化为发送方滑动窗口的大小S W S（未给出这一初始化）。发送方每传输一帧， s e m Wa i t操作将这个数减1，如果减小到0，则阻塞发送方进程。每收到一个A C K，在d e l i v e r SW P中调用s e m S i g n a l操作（见下面）将此数加1，从而激活正在等待的发送方进程。
在继续介绍S W P的接收方之前，需要调整一个看上去不一致的地方。一方面，我们说过，高层协议通过调用s e n d操作来请求低层协议的服务，所以我们就希望通过S W P发送消息的协议能够调用s e n d（S W P, p a c k e t）。另一方面，用来实现S W P的发送操作的过程叫做s e n d S W P，并且它的第一个参数是一个状态变量（ S w p S t a t e）。结果怎样呢？答案是，操作系统提供了粘结代码将对s e n d的一般调用转化为对s e n d S W P的特定协议调用的粘结代码。这个粘结代码将s e n d的第一个参数（协议变量S W P）映射为一个指向s e n d S W P的函数指针和一个指向S W P工作时所需的协议状态的指针。我们之所以通过一般函数调用使高层协议间接调用特定协议函数，是因为我们想限制高层协议中对低层协议编码的信息量。这使得将来能够比较容易地改变协议图的配置。现在来看d e l i v e r操作的S W P的特定协议实现，它在过程d e l i v e r SW P中实现。这个例程实际上处理两种不同类型的输入消息：本结点已发出帧的A C K和到达这个结点的数据帧。在某种意义上，这个例程的ACK部分是与send SWP中所给算法的发送方相对应的。通过检验头部的F l a g s字段可以确定输入的消息是ACK还是一个数据帧。注意，这种特殊的实现不支持数据帧中捎带A C K。当输入帧是一个ACK时，delive rSWP仅仅在发送队列（send Q）中找到与此ACK相应的位置（slot），取消超时事件，并且释放保存在那一位置的帧。由于A C K可能是累积的，所以这项工作实际上是在一个循环中进行的。对于这种情况值得注意的另一个问题是子例程swp In Wind o w的调用。这个子例程在下面给出，它确保被确认帧的序号是在发送方当前希望收到的A C K的范围之内。
当输入帧包含数据时， d e l i v e r S W P首先调用m s g S t r i pH d r和l o a d _ s w p _ h d r以便从帧中提取头部。例程l o a d _ s w p_ h d r对应着前面讨论的s t o r e _ s w p _ h d r，它将一个字节串转化为容纳S W P头部的C语言数据结构。然后d e l i v e r SW P调用s w p I n Wi n d o w以确保帧序号在期望的序号范围内。如果是这样，例程在已收到的连续的帧的集合上循环，并通过调用d e l i v e r HL P例程将它们传给上层协议。它也要向发送方发送累积的A C K，但却是通过在接收队列上循环来实现的（它没有使用本节前面给出的s e q N u m To Ac k变量）。
最后，s w p I n Window是一个简单的子例程，它检查一个给定的序号是否落在某个最大和最小顺序号之间。
4. 帧顺序和流量控制
滑动窗口协议可能是计算机网络中最著名的算法。然而，关于该算法易产生混淆的是，它可以有三个不同的功能，第一个功能是本节的重点，即在不可靠链路上可靠地传输帧。（一般来说，该算法被用于在一个不可靠的网络上可靠地传输消息。）这是该算法的核心功能。
滑动窗口算法的第二个功能是用于保持帧的传输顺序。这在接收方比较容易实现，因为每个帧有一个序号，接收方要保证已经向上层协议传递了所有序号比当前帧小的帧，才向上传送该当前帧。即，接收方缓存了（即没有传送）错序的帧。本节描述的滑动窗口算法确实保持了帧的顺序，尽管我们可以想象一个变异，即接收方没有等待更早传送的帧都到达就将帧传给下一个协议。我们可以提出的一个问题是：我们是否确实需要滑动窗口协议来保持帧的顺序，或者，这样的功能在链路层是否是不必要的。不幸的是，我们还没有看到足够多的网络体系结构来回答这个问题我们首先需要理解的是，点到点链路序列如何由交换机连接而形成一条端到端的路径。
滑动窗口算法的第三个功能是，它有时支持流量控制（f l o w c o n t ro l），它是一种接收方能够控制发送方使其降低速度的反馈机制。这种机制用于抑制发送方发送速度过快，即抑制传输比接收方所能处理的更多的数据。这通常通过扩展滑动窗口协议完成，使接收方不仅确认收到的帧，而且通知发送方它还可接收多少帧。可接收的帧数对应着接收方空闲的缓冲区数。在按序传递的情况下，在将流量控制并入滑动窗口协议之前，我们应该确信流量控制在链路层是必要的。
尚未讨论的一个重要概念是系统设计原理，我们称其为相关性分离（separation of concerns）。即，你必须小心区别有时交织在一种机制中的不同功能，并且你必须确定每一个功能是必要的，而且是被最有效的方式支持的。在这种特定的情况下，可靠传输、按序传输和流量控制有时组合在一个滑动窗口协议里，我们应该问问自己，在链路层这样做是否正确。带着这样的疑问，我们将在第3章（说明X. 2 5网如何用它实现跳到跳的流量控制）和第5章（描述T C P如何用它实现可靠的字节流信道）重新考虑滑动窗口算法。
