前言
我们知道,TCP的数据包是交给IP层传输的,而IP没提供可靠服务,所以,要想实现可靠,必须在传输层中结合相关规则来实现。
那么怎样才算可靠呢?
- 传输过程不出差错
- 不管发送方以多少的数据发送,接收方都来得及接收到数据
所以,可靠传输协议都是基于一应一答来的,我发给你一个数据包,然后你收到之后发送一个确认信息给我。
首先介绍一下最简单的一个——停止等待协议,从字面上我们就可以猜出来了,就是我发给你一个数据包M,然后我就等着你收到之后给你发一个确认信息,然后我再继续给你发送信息;那么考虑一下丢失情况:
- 1、假设我发给你,然后包丢失了怎么办?一直没收到你的确认信息,岂不是要一直等下去,不是这样的。当大于一定的时间后,我就会认为数据包丢失了,就会执行超时重传,再给你发一次咯。
- 2、假设你已经收到了,然后给我发了应答,然而应答丢失了怎么办?还是一样的,我会认为包已经丢失了,然后给你再发一次,这时候,你接收到了同样的包后就会依次执行以下两个操作:(1)丢弃该分组;(2)向我发送确认信息。
image.png
这样是不是一目了然了呢?
那么如果让你设计这个协议,你知道需要注意哪些了吧?
- 首先我们需要设计一个超时计时器,到达该时间最大值就要重传。
- 其次在分组过程中我们需要进行编号,这样你才能知道哪一个分组确认了呀。
- 为了重传,所以我们必须要暂时保留已经发送的分组的副本。
- 对于已经确认过的编号,如果再次受到后不予理会。
好了,介绍完上面这个了,你是不是会发现停止等待协议的缺点太明显了——信道利用率太低啦!为了提高效率,我们采用流水线传输的方式,连续发送多个分组,下面我们将介绍连续ARQ协议和滑动窗口协议
什么意思呢?
简单的来说就是发送方维持一个窗口:在窗口中的分组都可以发送出去,不需要等待对方的确认。


在发送窗口中的分组都可以发送,例如图中的4-12号的包在发送窗口里面,所以数据包可以同时发送,不用等到确认消息。而在12后面的都不能发送。
都说滑动窗口,那它什么时候滑动呢? 当发送端接受到确认消息之后就会向后滑动,举个例子吧:当接收到ACK = 6,时候,就说明前面已经都收到了,接收方希望下次发来的包是从6开始的,所以,发送窗口滑到以6为头,涵盖6-14,接着它就会把在发送窗口中的包全都发送一遍。
那么问题来了,既然包可以一次性都发出去,那你怎么保证确认6之后,4,5号包已经到达了呢?
这就要考虑一下它发送确认消息的时间了,假设现在4,6号包提前到达了,5号却没到达(比较慢),这时候他就会发送ACK = 5过去,不会发送ACK = 7,什么意思呢?就是当且仅当你之前序号的包都到达之后,才会发送确认包,这就是我们所说的累积确认的方式。
这两种大概都介绍完了,我想问一个问题,是不是连续ARQ就一定会胜过停止等待协议呢?
我们来做一下这个题目 :
在连续ARQ协议中,设编号为3位(000-111),发送窗口为8,试找出一种情况使得协议不能正常工作,并分析连续ARQ协议是否一定优于停止等待协议?
答:所有确认帧都正确到达发送端,发送段又接着发送8个新的数据帧,其编号为0-7,而一旦所有确认帧都丢失了 ,经过一段时间后,发送端重传这8个旧的数据帧,其编号仍为0-7,显然接收端2次收到0-7 8个数据帧时无法判定这是新数据帧还是重传数据帧。
连续ARQ协议一方面因因连续发送数据帧而提高效率,但另一方面在重传过程中又必须把原来正确传送过的数据帧进行重传,仅因这些数据帧之前有一个数据帧出错,这种做法又使传送效率降低,由此可见,若传输信道传输质量很差,误码率很大时,连续ARQ协议不一定优于停止等待协议。
网友评论