滑动窗口概念不仅存在于
数据链路层,也存在于
传输层,两者有不同的协议,但基本原理是相近的。其中一个重要区别是,一个是针对于帧的传送,另一个是字节数据的传送。
基本信息
概念
滑动窗口(Sliding window)是一种
流量控制技术。早期的
网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道
网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了
滑动窗口机制来解决此问题。参见滑动窗口如何根据网络拥塞发送数据仿真视频。图片是一个滑动窗口的实例:
滑动窗口协议是用来改善吞吐量的一种技术,即容许发送方在接收任何应答之前传送附加的包。接收方告诉发送方在某一时刻能送多少包(称窗口尺寸)。
TCP中采用滑动窗口来进行传输控制,滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为0时,发送方一般不能再发送数据包,但有两种情况除外,一种情况是可以发送紧急数据,例如,允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。
窗口机制
滑动窗口协议的基本原理就是在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为
发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧。
下面举例说明,假设
发送窗口尺寸为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时,
滑动窗口协议退化为
停等协议(stop-and-wait)。该协议规定发送方每发送一帧后就要停下来,等待接收方已正确接收的确认(acknowledgement)返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧,因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧,因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
后退n协议
由于
停等协议要为每一个帧进行确认后才继续发送下一帧,大大降低了信道利用率,因此又提出了后退n协议。后退n协议中,发送方在发完一个
数据帧后,不停下来等待应答帧,而是连续发送若干个数据帧,即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍未收到确认帧,就要重发相应的数据帧。如:当发送方发送了N个帧后,若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息,则该帧被判为出错或丢失,此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出,后退n协议一方面因连续发送
数据帧而提高了效率,但另一方面,在重传时又必须把原来已正确传送过的数据帧进行重传(仅因这些数据帧之前有一个数据帧出了错),这种做法又使传送效率降低。由此可见,若传输信道的传输质量很差因而
误码率较大时,连续测协议不一定优于
停止等待协议。此协议中的
发送窗口的大小为k,接收窗口仍是1。
选择重传协议
在后退n协议中,接收方若发现错误帧就不再接收后续的帧,即使是正确到达的帧,这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层,但接收方仍可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后,就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT),其工作过程如图所示。显然,选择重发减少了浪费,但要求接收方有足够大的缓冲区空间。
背景
如果过多的源同时以很快的速度发送大量的数据包,而此时接收方并没有如此高的接收数据的能力,因此极易导致网络的拥塞。所以,为了控制发送方的发送速度,防止发送方并考虑到受发送缓冲区大小的制约等,要求对发送方已发出但尚未经确认的帧的数目加以限制,同时使网络的传输效率得到提高,
滑动窗口协议应运而生,它使得发送方可以在未收到确认的情况下,同时发送多个数据分组,由此大大提升了
网络吞吐量。
在任何基于自动重发请求进行错误控制的通信协议中,接收方必须确认收到的数据包。 如果发送方在合理的时间内没有收到确认,则重发数据。没有听到确认的发送方不知道接收方是否实际接收到分组(数据可能在传输中丢失或损坏)。 如果错误检测显示损坏,则数据包将被接收方忽略,并且不会发送确认。 因为网络传输的时延,将有大量时间被用于等待确认,导致传输效率低下。
工作机制
工作原理
通过限制在任何给定时间可以发送或接收的数据包的数量,
滑动窗口协议允许使用固定大小的序列号传送无限数量的数据包。发送方侧的术语“窗口”表示接收方尚未确认的分组总数的逻辑边界。接收方在每个确认包中通知发送器当前的最大接收缓冲区大小(窗口边界)。 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和ns之间的分组是不确定的,即na≤nr≤ns。
并且序列号总是符合na≤nr≤nx≤nt≤na+wt的规则,证明如下:
na≤nr:发送器接收到的最高确认不能高于接收方确认的最高nr。
nr≤ns:完全接收的数据包的范围不能超出部分接收的数据包的结尾。
ns≤nt:接收到的最高报文不能高于发送的最高报文。
nt≤na + wt:发送的最高数据包同时受到接收到的最高确认和发送窗口大小的限制。
发送方操作
每当发送方具有要发送的数据时,它可以在最新的确认na之前传输序列号高达wt数据包。也就是说,只要nt
在没有通信错误的情况下,发送方很快就会收到所有发送的数据包的确认信息,这等于nt。如果在合理的延迟之后不会发生这种情况,则发送方必须在na和nt之间重传数据包。
接收方操作
每次接收到一个编号为x的数据包时,接收方检查它是否落入接收窗口,nr≤x nr,则存储数据包直到接收到所有先前的数据包为止。如果x≥ns,后者更新为ns = x + 1。
如果数据包的序列号不在接收窗口内,则接收方将丢弃该数据包,并且不修改nr或ns。无论数据包是否被接受,接收方发送包含当前nr的确认。 (确认还可以包括关于nr或ns之间接收的附加数据包的信息,但这只能帮助效率。)
请注意,没有必要让接收窗口wr大于发送窗口wt,因为不需要担心接收到永远不会发送的数据包;有用范围为1≤wr≤wt。
流量控制
TCP的特点之一是提供体积可变的
滑动窗口机制,支持端到端的
流量控制。TCP的窗口以
字节为单位进行调整,以适应接收方的处理能力。处理过程如下:
TCP连接阶段,双方协商窗口尺寸,同时接收方预留
数据缓存区;
发送方根据协商的结果,发送符合窗口尺寸的数据
字节流,并等待对方的确认;
发送方根据确认信息,改变窗口的尺寸,增加或者减少发送未得到确认的字节流中的字节数。调整过程包括:如果出现发送拥塞,
发送窗口缩小为原来的一半,同时将超时重传的时间间隔扩大一倍。
滑动窗口机制为端到端
设备间的数据传输提供了可靠的
流量控制机制。然而,它只能在源端设备和目的端设备起作用,当网络中间设备(例如
路由器等)发生拥塞时,滑动窗口机制将不起作用。
应用场景
滑动窗口协议以基于分组的数据传输协议为特征。因此该协议适用于对按顺序传送分组的可靠性要求较高的环境,例如在
数据链路层(
OSI模型)以及
传输控制协议(TCP)中。
增强应答的链路层重传,在长线传输中,因软故障造成的消息传输错误占据了绝大部分,对于这些问题的解决可以是系统的可靠性大大提高。这种机制,向通过实现简单、检突发错误能力高的CRC码的校验进行错误检查,再由相应的滑动窗口协议实现重传恢复。