十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
最简单的协议,假设信道是单工的,无差错的,且接收方有无限的缓冲区。
10年积累的成都网站建设、网站建设经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先做网站后付款的网站建设流程,更有汉源免费网站建设让你可以放心的选择与我们合作。所以发送方就可以一直发
问题:现实情况比这个恶劣的多。
二、Simplex Stop-and-Wait Protocol for an Error-Free Channel(简单停等)假设:单工信道,无差错,接收方是有限的缓冲区。
发送方发送数据,然后停下来等待接收方的ack,收到ack之后再发数据。这样接收方就可以不发ack来控制发送的速度。
问题:
1、如果信道不是无差错的,那么接收方算了CRC之后发现不对,就会丢弃包,不发ack,这时发送方的timer超时,就会重传。
2、如果数据帧丢了,那么发送方就会收不到ack,timer超时重传。
3、如果ack丢了,那么同样发送方就会收不到ack,timer超时重传。可是这就会有一个问题
发送方重传的是一样的东西,这样接收方就会收到同样的帧,可接收方不知道是同样的帧,这时就需要给数据帧加序号。
可是这样还没完,接收方收到重复的帧后,接受方发现是重复的序号,就丢掉了,不发ack,可发送方不知道啊,发送方觉得是这一帧又没发到,timer到了就又重传。所以这时就需要给ack帧加序号,加上这两个序号,就是第三个协议。
三、Stop-and-Wait ARQ(停等ARQ)就是用0和1给数据和ack编号,这样就解决了重复数据帧和延迟ack的问题。
四、One-Bit Sliding Window Protocol窗口大小为1的滑动窗口协议,其实就是停等,只不过这个是双工的,刚才的停等是单工的信道。
工作流程如下:
1、发收双方窗口大小都为1,初始窗口状态都一样,发送方准备发送序号为0的数据,接收方等待接收序号为0的数据,
2、发送方发送数据,把该数据标记为已发送待确认
3、接收方收到数据,crc确认后将数据交给上层,发送ack给发送方,并同时把窗口向右滑动,表示下一个待收的数据序号为1
4、发送方收到ack,将窗口向右滑动,准备发送下一个序号为1的数据,如此反复。
问题:这样对于一些带宽时延积较大的信道,会导致低效,比如卫星信道,数据的发送时延很短,但是传播时延很长,发送方花了很短的时间将数据发送出去,剩下很大一部分时间都在等待数据发给接收方,然后接收方回ack,时间主要都用到这两次传播时延上了,效率很低。
五、Protocol Using Go Back N还是滑动窗口,这次发送窗口有很多,但是接收窗口还是一个,这个协议采用了累计ack的方法。
1、正常情况看这个正常情况的例子,发送窗口大小是3,按顺序发0、1、2帧,接收方一开始窗口在0那,收到0号帧之后,由于是累计确认,所以不发ack,把窗口向右滑,等待1号帧,收到1号帧后,滑动窗口,回一个ack1,表示0和1号帧都收到了,发送方收到这个之后,就明白了,就把窗口向右滑动两个。这里有一个问题,那就是累计确认的话,什么时候选择回ack呢,如果收到的帧一直都是对的,迟迟不回,发送方岂不是会超时。
2、丢数据看这个例子,发送方发送0、1、2,接收方收到0、1后回了ack1,发送方滑动两个窗口,接着发3号帧,可是这时2号帧丢了,接收方收到3号帧后,发现这不是我要的啊,我要的是2号帧,他就丢弃,并且回一个ack1,表示并没有受到2号帧。 这是有一个问题,那就是只有收到帧校验和对的时候,才会回ack,例如这里3号帧如果校验和不对,那就不会回ack1,因为校验和不对时,序号就没有意义了,有可能是错的。然后继续,发送方没有收到ack2和ack3,2、3号帧就会依次超时,并重传。
3、ack丢失考虑一个极端情况,发送方发送0、1、2号帧,接收方都正确收到并滑动了窗口,并且回了ack,可是ack全丢了,这时接收方窗口在等3号帧,发送方0号帧超时重传,接收方收到后发现不是我要的帧,就会丢掉,回一个我正在等的帧序号的前一个序号,比如这里等的是3号帧,回的ack就是ack2。这时发送方收到ack2后,就知道前三个帧都收到了,就会往右滑三次窗口。
4、窗口大小问题窗口大小和序号的二进制位数有关,对于n比特位的序号来说,发送窗口和接收窗口的大小的和需要小于等于2的n次方。对于GBN协议来说,接收窗口大小是1,那发送窗口大小就要小于等于2的n次方减一。
如何考虑窗口大小的问题呢,只需要考虑一种极限情况,那就是发送窗口把所有帧全发出去了,接收方的ack全丢了,这时候接收窗口不能和发送窗口有重叠,有重叠就有问题。
看这样一个例子
这里n=2,按照原理,发送窗口大是3,考虑发送和窗口是4的情况,也就是右边这张图,发送方发了0、1、2、3号帧,接收方全部正确收到并回了ack,可是全丢了,这时接收方在等待新的0号帧,可是这时发送方重传了上一次的0号帧,而接收方收到后,会误以为这时新的0号帧,那么就出错了。
5、问题问题就在于这个go back n,可能发送方发了8个帧,除了第二帧别的都对了,可这样发送方还是得重传2号帧以及他之后的所有帧,这样效率太低了。
六、Selective Repeat(选择重传) ARQ选择重传其实就是上一个GBN得改进,把接收方窗口扩大了,遵循的窗口大小原则还是一样
Wt是发送窗口大小,Wr是接收窗口大小,第一条的原因和上一个协议一样,第二条的原因是接收窗口的大小大于发送窗口是没有意义的。
这里涉及一个ack timer的问题,接收方收到数据后,会设置一个timer,等待高层的数据,看能不能稍待确认过去,如果timer过了还没有高层的数据,那么就会发送ack。这里这个timer的时间需要考虑,发送方发送数据过来,接收方设置timer,timer超时回ack,这是三段时间,发送方发过来数据的时间加上ack回去的时间是一个RTT,也就是说,RTT加上timer必须要小于发送方超时重传的timer。
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧