对于SR协议而言,为什么滑动窗口长度必须小于或等于序号空间大小的一半?

发布于:2023-01-11 ⋅ 阅读:(408) ⋅ 点赞:(0)

为什么滑动窗口长度必须小于或等于序号空间大小的一半?

首先我先下个结论:当滑动窗口长度大于序号空间一半时,在某些情况下会导致接收方无法确定发送方到底是重传还是初次传输

重点概念
在实践中,分组的序号是承载在分组首部的一个固定长度的字段中。所以序号的大小是有限制的,如果字段长度为k,那么序号的范围就是【0,2k - 1】。所以,对于一些过长的序号就必须进行模2k 运算。所以对于一些相同序号的分组,接收方该如何处理呢?是认为是重传的分组还是新的分组呢?

首先你必须清楚一个接收方的事件与动作;

接收的序号在[rcv_base - N,rcv_base - 1]内的分组被正确收到。在此情况下,必须产生一个ACK,即时该分组是接收方以前已经确认过的分组。

N是滑动窗口的大小

rcv_base是SR接收方当前窗口中还未接收序号的最小序号

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RupPXieW-1660879348421)(D:\note\笔记仓库\图片\image-20220819111439926.png)]

下面我举一个序号长度为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确认报文给发送方。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rz2ir5qv-1660879348424)(D:\note\笔记仓库\图片\image-20220819102923537.png)]

  • 第二种情况;对前三个分组的ACK都正确交付,因此发送方会发送分组4、5、6,对应的分组序号为3、4、0。在发送分组时,分组序号3、4丢失,但分组序号为0的成功到达

    这种情况下接收方的行为;在我们人的视角来看,接收方是接收到了不同内容的分组(只是分组序号相同)。但是从接收方来看,它会认为是发送方重传的分组即在分组==[rcv_base - N,rcv_base - 1]==范围内,就会直接返回ACK,而不会做其它处理。这是显然错误的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gh29ghdD-1660879348426)(D:\note\笔记仓库\图片\image-20220819110237617.png)]

对于以上两种情况,由于接收方是没有办法判断到底是哪一种情况的,所以对于SR协议而言,就有了窗口长度必须小于或等于序号空间的一半。在窗口长度大于序号空间的一半时,都会产生相同的错误。

例如上述例子;假如序号空间为6,即0、1、2、3、4、5,窗口长度还是3,满足窗口长度必须小于或等于序号空间的一半。则第二种情况的分组0会变成分组5,发现在分组[rcv_base - N,rcv_base - 1]范围内没有发现对于的分组序号,所以是肯定能够区分滴👍

更能说明问题的是当发送方要开始发送第二批序号为0的分组时,如下图所示;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ev0qN2VE-1660882231034)(D:\note\笔记仓库\图片\image-20220819120652401.png)]

此时接收方的滑动窗口必须是以下这种情况或者是更向右移

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lj6JIyC8-1660882231036)(D:\note\笔记仓库\图片\image-20220819120800743.png)]

无论是这种情况还是更向右移,发送过来的序号0都不在[rcv_base - N,rcv_base - 1]的范围内,接收者都能够区分

类似的,如果序号空间更大,更不会方式相似的情况💅

参考资料:《计算机网络 自定向下方法》

本文含有隐藏内容,请 开通VIP 后查看

网站公告

今日签到

点亮在社区的每一天
去签到