为什么滑动窗口长度必须小于或等于序号空间大小的一半?
首先我先下个结论:当滑动窗口长度大于序号空间一半时,
在某些情况下会导致
接收方
无法确定发送方到
底是重传还是初次传输
重点概念
;
在实践中,分组的序号是承载在分组首部的一个固定长度的字段中。所以序号的大小是有限制的,如果字段长度为k,那么序号的范围就是【0,2
k
– 1】。所以,对于一些过长的序号就必须进行模2
k
运算。所以对于一些相同序号的分组,接收方该如何处理呢?是认为是重传的分组还是新的分组呢?
首先你必须清楚一个接收方的事件与动作;
接收的序号在[rcv_base – N,rcv_base – 1]内的分组被正确收到。在此情况下,必须产生一个ACK,即时该分组是接收方以前已经确认过的分组。
N是滑动窗口的大小
rcv_base是SR接收方
当前窗口
中还未接收序号的最小序号
![]()
下面我举一个序号长度为5,窗口长度为3的例子说明原因(其它情况原理也相似):
假设有5个分组序号0、1、2、3、4的有限序号范围且窗口长度为3。假定现在发送了分组0~2,并且接收方正确接收并且确认。则现在接收方窗口落在4、5、6分组上,序号对应位3、4、0。现在发生以下两种情况;
-
第一种情况;接收方正常接收到3个分组,但是在响应给发送方时,对前3个分组的ACK丢失,因此在发送方超时重传时间到后,发送方会重传这些分组,接收方下一步要重新接收序号为0的分组,即第一个发送分组的副本。
这种情况下接收方的行为
;接收方发现此时序号为0的分组在[rcv_base – N,rcv_base – 1]范围内,会重新确认这些分组,也就是再次发送ACK确认报文给发送方。 -
第二种情况;对前三个分组的ACK都正确交付,因此发送方会发送分组4、5、6,对应的分组序号为3、4、0。在发送分组时,分组序号3、4丢失,但分组序号为0的成功到达
这种情况下接收方的行为
;在我们人的视角来看,接收方是接收到了不同内容的分组(只是分组序号相同)。但是从接收方来看,它会认为是发送方重传的分组即在分组==[rcv_base – N,rcv_base – 1]==范围内,就会直接返回ACK,而不会做其它处理。这是显然错误的。
对于以上两种情况,
由于接收方是没有办法判断到底是哪一种情况的,
所以对于SR协议而言,就有了
窗口长度必须小于或等于序号空间的一半
。在窗口长度大于序号空间的一半时,都会产生相同的错误。
例如上述例子;假如序号空间为6,即0、1、2、3、4、5,窗口长度还是3,满足窗口长度必须小于或等于序号空间的一半。则第二种情况的分组0会变成分组5,发现在分组[rcv_base – N,rcv_base – 1]范围内没有发现对于的分组序号,所以是肯定能够区分滴?
更能说明问题的是当发送方要开始发送
第二批序号为0的分组
时,如下图所示;
此时接收方的滑动窗口必须是以下这种情况
或者是更向右移
;
无论是这种情况还是更向右移,
发送过来的序号0都不在[rcv_base – N,rcv_base – 1]的范围内
,接收者都能够区分
类似的,如果序号空间更大,更不会方式相似的情况?
参考资料:《计算机网络 自定向下方法》