滑动窗口协议的真谛和伟大之处

滑动窗口协议是个很古老的协议,在X.25中就有定义.但是现在的TCP协议依然在使用,因为它的流量控制和差错控制的实现实在是很伟大的创举.

学网络工程师的人,即使考过了,甚至考高分,但其实大部分依然不理解真正的滑动窗口协议,这就是应试教育的弊端.看起来非常非常简单的滑动窗口协议,但是其实并不简单.

假设从A端发送数据到B端,A端怎么知道数据已经发送过去,B端正确接收了呢?最简单的的协议是停等协议,就是B端接收到A端的一个帧,就发生一个ACK给A端,A端收到这个ACK,继续发送下一个帧.如果超时,或者错误,则重发.但是这个协议,导致线路利用率很低,尤其信道延时大的情况下,极为低下.时间都耗费在等待回应上面了.

于是产生了滑动窗口协议.

假设有8个帧大小的窗口,A端在没有收到ACK的情况下,可以一直发送8个帧(0,1,2,3,4,5,6,7)到B端,如果发送完8个帧也没有收到ACK,那么A将一直等待.如果在发送到4号帧时,收到ACK1,那么将窗口向后滑动一位,此时窗口内的帧为1,2,3,4,5,6,7,0,也就是说,除了已经发送的0,1,2,3,A还可以发送4,5,6,7,0号.

要注意,A端只能发送窗口内的帧,而只有接受到ACK,才将窗口向后滑动,也就是说,B端先滑动窗口,然后A端才滑动窗口.而B端只能接受接受窗口内的帧.

教材上说,滑动窗口协议效率为E=W* tf / (2tp + tf),W是窗口大小,tp是信道延时,tf是帧的发送时长,也就是说,滑动窗口协议的效率是停等协议效率 E= tf / (2tp + tf)   的W倍,实际上这是片面的说法.

只有滑动窗口在最低效的情况下,效率才是停等的W倍,也就是当窗口内的帧全部发送完毕且等待了tp时间,才收到ACK时,效率才这么低下,但只要在窗口时间内收到ACK,A端就可以一直不停发送.所以滑动窗口效率是极高的.

滑动窗口协议的信道利用率与发送窗口的大小有关，当Ws × Ts ≥ ( Ts + 2Tp )时，信道利用率为100%，否则信道利用率为Ws × Ts / ( Ts + 2Tp )。

接下来,我要问大家两个问题,为什么选择重发ARQ的窗口必须小于等于帧编号的一半?为什么后退N帧ARQ的窗口大小必须必帧编号数小1?

这个原因,教材上用两个字回答:"显然.",此时我心里默默跑了N个显NMB.

选择重发ARQ:

首先我们看看错误的情况:

如果窗口大小大于帧编号的一半,比如说,窗口大小为5,帧编号为0-7.

当A端发送0,1,2,3,4之后等待ACK,B端收到这5个帧之后,将窗口滑动到[5,6,7,0,1],然后B发送ACK到A,结果ACK因为故障丢失,

当A段等待超时之后,从新发送0,1,2,3,4,此时0和1,号帧,落在B的窗口内,于是B端将帧当做新的帧保存起来,产生了错误.

接下看看正确的情况:

如果窗口大小小于等于帧编号的一半,比如说,窗口大小为4,帧编号为0-7.

当A端发送0,1,2,3之后等待ACK,B端收到这4个帧之后,将窗口滑动到[4,5,6,7],然后B发送ACK到A,结果ACK因为故障丢失,

当A段等待超时之后,从新发送0,1,2,3,此时这几个帧,都不会落在B的窗口内,于是不会产生错误.

上面讲了一大堆,总结起来其实就一句话:

当窗口大小小于等于帧编号的一半时,A端重发的帧编号,不会落在B端的窗口内,因为A端的窗口和B端的窗口是完全错开的,没有重合部分!!!

那么,下面说明回退N帧ARQ窗口大小W<=2^k-1 的原因

先看错误的情况:

在网络中,ACK帧有可能会被A端重复接收,比如帧编号0-7,窗口大小8,当A端收到一个ACK1,(这个回应表示B端窗口已经滑动到1号帧)此时A段将窗口向后滑动一位,并且将0,[1,2,3,4,5,6,7,0]全部发送,此时又收到ACK1,那么这个ACK1可能表示,B端已经滑动到第二段帧编号的1号帧,也可能表示这个ACK1是网络中的重复帧,B端其实窗口根本没有移动,一个帧都没有收到.于是产生二义性.

再看正确的情况:

帧编号0-7,窗口大小7,当A端收到ACK1,于是继续将窗口[1,2,3,4,5,6,7]全部发送,然后等待,此时又收到ACK1,此时这个ACK1,只可能是重复帧,而不是第二段的0号帧的回应(注意,0号帧的回应就是ACK1)ACK1中的1,表示的是窗口的位置,而不是帧编号,因为A端根本就没有发送第二段的0号帧,所以不可能收到第二段的ACK1.

以上便是回退N帧ARQ窗口大小W<=2^k-1 的原因.