滑动窗口算法.docxVIP

滑动窗口算法 滑动窗口算法 滑动窗口算法工作过程如下。首先，发送方为每1帧赋一个序号(sequence number),记作S e q N u m。现在，让我们忽略S e q N u m 是由有限大小的头部字段实现的事实，而假设它能无限增大。发送方维护3个变量：发送窗口大小(send window size)，记作S W S 给出发送方已经发 发送方 接收方 图2-以滑动窗口宾法的时间线 送但未确认的帧数的上界；L A R表示最近收到的确认帧(last acknowledgement re c e i v e d)的序号；L F S表示最近发送的帧(last frame sent)的序号，发送方还维持如下的不变式： LAR-LFRRWS ^SWS ■ LAR LFS 图N-22发送方的滑动商品 当一个确认到达时，发送方向右移动LAR，从而允许发送方发送另一帧。同时，发送方为所发的每个帧设置一个定时器，如果定时 器在ACK到达之前超时，则重发此帧。注意：发送方必须存储最多SWS个帧，因为在它们得到确认之前必须准备重发。 接收方维护下面3个变量：接收窗口大小(receive window size)，记为RW S/*对应允许接受的数据包*/，给出接收方所能接收的无 序帧数目的上界；L A F表示可接收帧(largest acceptable frame)的序号；L F R表示最近收到的帧(last frame re c e i v e d)的序号。 接收方也维持如下不变式： LFS-LARSWS …w I I「「〕T I I I… r n!e lfa 图冬巧捶收方的滑动窗口 (NFE为等待下一帧的序号) 当一个具有顺序号S e q N u m的帧到达时，接收方采取如下行动：如果S e q N u mL F R或S e q N u m L A F，那么帧不在接收窗 口内，于是被丢弃；如果L F RVSe q N u mL A F，那么帧在接收窗口内，于是被接收。现在接收方需要决定是否发送一个A C K。 设SeqNumToACK表示未被确认帧的最大序号，则序号小于或等于SeqNumToACK的帧都已收到。即使已经收到更高序号的分组，接 收方仍确认SeqNumToACK的接收。这种确认被称为是累积的(c u m u l a t i v e)。然后它设置L F R = S e q N u 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的ACK。)如果帧6当时到达了(或许它在第一次丢失后又 重发从而晚到，或许它只是被延迟了)，接收方确认帧8, L F R置为8, L A F置为1 2。如果实际上帧6丢失了，则出现发送方超时， 重发帧6。我们看到，当发生超时时，传输数据量减少，这是因为发送方在帧6确认之前不能向前移动窗口。这意味着分组丢失时， 此方案将不再保证管道满载。注意：分组丢失时间越长，这个问题越严重。 注意，在这个例子中，接收方可以在帧7刚一到达时就为帧6发送一个认帧N A K (negative acknowl edgment )。然而，由于发送方 的超时机制足以发现这种情况，发送NAK反而为发送方增加了复杂性，因此不必这样做。正如我们已提到的，当帧7和8到达时为 帧5发送一个额外的ACK是合理的；在某些情况下，发送方可以使用重复的ACK作为一个帧丢失的线索。这两种方法都允许早期 的分组丢失检测，有助于改进性能。 关于这个方案的另一个变种是使用选择确认(selective acknowledgements)。即，接收方能够准确地确认那些已收到的帧，而不只是确 认按顺序收到最高序号的帧。因此，在上例中，接收方能够确认帧7、8的接收。如果给发送方更多的信息，就能使其较容易地保持 管道满载，但增加了实现的复杂性。 发送窗口大小是根据一段给定时间内链路上有多少待确认的帧来选择的；对于一个给定的延迟与带宽的乘积，SWS是容易计算的。 另一方面，接收方可以将RW S设置为任何想要的值。通常的两种设置是：RW S= 1，表示接收方不存储任何错序到达的帧；RW S=S W S，表示接收方能够缓存发送方传输的任何帧。由于错序到达的帧的数目不可能超过S W S个，所以设置RWS S W S没有意义。 有限顺序号和滑动窗口 现在我们再来讨论算法中做过的一个简化，即假设序号是可以无限增大的。当然，实际上是在一个有限的头部字段