- 专栏目录首页:【专栏必读】考研湖科大教书匠计算机网络笔记导航
文章目录
- 一:可靠传输基本概念
- (1)不可靠传输与可靠传输
- (2)分组丢失、分组失序和分组重复
- (3)可靠传输注意
- 二:可靠传输的实现机制
- (1)停止等待协议(SW)
- A:概述
- B:三种情形和应对手段
- ①:数据分组丢失(超时重传)
- ②:确认分组丢失(数据分组编号)
- ③:确认分组迟到(确认分组编号)
- C:注意事项
- D:停止等待协议信道利用率
- E:滑动窗口协议
- (2)后退N帧协议(GBN)
- A:后退N帧协议中的发送窗口和接收窗口
- B:无差错情况下的传输过程
- C:累积确认
- D:有差错情况下的传输过程
- E:为什么发送窗口尺寸不能超过上限
- F:总结
- (3)选择重传协议(SR)
本节对应视频如下
- 【计算机网络微课堂(有字幕无背景音乐版):3.4.1 可靠传输的基本概念】:对应“一:可靠传输基本概念”
【计算机网络微课堂(有字幕无背景音乐版)】:3.4.2 可靠传输的实现机制 — 停止-等待协议 :对应“二:可靠传输的实现机制-(1)停止等待协议(SW)”
【计算机网络微课堂(有字幕无背景音乐版)】:3.4.3 可靠传输的实现机制 — 回退N帧协议 :对应“二:可靠传输的实现机制-(2)后退N帧协议(GBN)”
【计算机网络微课堂(有字幕无背景音乐版)】 :3.4.4 可靠传输的实现机制 — 选择重传协议:对应“二:可靠传输的实现机制-(3)选择重传协议(SR)”
一:可靠传输基本概念
(1)不可靠传输与可靠传输
通过前文我们可以得知,接收方数据链路层可以通过差错检测技术(如CRC)检测出帧在传输过程中是否出现了误码
如果出现了误码,那么数据链路层接下来应该如何做呢?这取决于数据链路层向其上层提供的服务类型,分为如下两种
- 不可靠传输:仅仅丢弃有误码的帧,其他什么都不做
- 可靠传输:想办法实现发送端发送什么、接收端就收到什么。例如接收方可以发送一个通知帧,告诉发送方:“之前的帧出现了误码,请重发”
一般情况下
- 对于有线链路:其误码率较低,因此不要求数据链路层向上提供可靠传输服务;即使出现了误码,可靠传输的问题也会交由上层处理
- 对于无线链路:由于其极易受到干扰,误码率高,因此要求数据链路层必须向上提供可靠传输服务
(2)分组丢失、分组失序和分组重复
前文我们一直介绍的是比特差错,但它仅仅是传输差错中比较简单的一种。从整个计算机网络体系来看,传输差错还包括分组丢失、分组失序和分组重复
-
分组丢失:如下图,主机H6给主机H2发送的分组到达了路由器R5,由于此时R5的输入队列快满了,R5根据相关策略将该分组丢弃
-
分组失序:如下图,主机H6依次给主机H2发送了三个分组,但是它们并未按照发送顺序依次到达H2
-
分组重复:如下图,主机H6依次给主机H2发送了分组,由于某些原因该分组在网络中滞留,没有及时到达H2,这可能会触发H6的超时重传机制,重发的分组达到H2,一段时间后滞留在网络中的那个分组又达到了H2
(3)可靠传输注意
需要注意的是,可靠传输服务并不局限于数据链路层。分组丢失、分组失序和分组重复这些传输差错一般不会出现在数据链路层,而会出现在其上层。可靠传输的实现比较复杂,开销也很大,是否需要实现可靠传输取决于具体的应用场景和需求
- 802.11无线局域网要求数据链路层实现可靠传输;以太网不要求数据链路层实现可靠传输
- IP向上提供无连接、不可靠传输服务
- TCP向其上层提供面向连接的可靠传输服务;UDP向其上层提供无连接、不可靠传输服务
二:可靠传输的实现机制
可靠传输的实现机制:主要如下三种实现可传输的机制,这三种机制不仅仅局限于数据链路层,可以应用到计算机网络体系结构的各层协议中
- 停止等待协议(SW)
- 回退N帧协议(GBN)
- 选择重传协议(SR)
(1)停止等待协议(SW)
A:概述
停止-等待协议(Stop-and-Wait):发送方每发送完一个数据分组后就停止发送下一个数据分组,该数据分组也不能马上从其缓存中删除,在收到针对该数据分组的确认分组(ACK)或否认分组(NAK)后再进行下一步处理:
- 如果收到确认分组(ACK):则可以继续发送下一个数据分组,并把该数据分组从其缓存中删除
- 如果收到否认分组(NAK):则重发之前的数据分组,然后继续等待该数据分组的ACK或NAK
如下图,收发双方基于互联网进行通信,纵坐标为时间,收发过程如下
- ①:发送方给接收方发送数据分组
- ②:接收方收到后对其进行差错检测,发现没有误码,则接受该数据分组,并给发送方发送确认分组(ACK)
- ③:发送方收到对所发送数据分组的确认分组后再次发送数据分组
- ④:这个数据分组在传输过程中出现了误码,接收方检测到误码后丢弃该数据分组,并给发送方发送否认分组(NAK)
- ⑤:发送方收到对所发送数据分组的否认分组后就明白了之前所发送的数据分组出现了差错而被对方拒绝,于是立刻重传该数据分组
- ⑥:这个数据分组没有出现误码,接收方返回确认分组(ACK)
B:三种情形和应对手段
上面只是停止-等待协议中最为简单的一种情形,但实际情况远比这个复杂,面对其他情形,会有如下三种手段应对
- 数据分组丢失:超时重传
- 确认分组丢失:数据分组编号
- 确认分组迟到:确认分组编号
①:数据分组丢失(超时重传)
数据分组丢失(超时重传):如果发送方给接收方发送的数据分组在传输过程中丢失,那么就意味着接收方接收不到数据分组,进而不会发送ACK或NAK,如果不采取任何措施,那么发送方就会一直处于等待状态。为了解决这个问题,可以在发送方发送完一个数据分组时,启动超时计时器,如果到了超时计时器所设置的重传时间后仍收不到对方任何ACK或NAK,那么就重传原来的数据分组。一般可以将重传时间设置为略大于从发送方到接收方的平均往返时间(RTT)
如下图,收发双方基于互联网进行通信,纵坐标为时间,收发过程如下
- ①:发送方给接收方发送数据分组,但该数据分组在传输过程中丢失
- ②:超过重传时间后,发送方仍然没有收到任何ACK或NAK,于是超时重传之前的数据分组
- ③:接收方正确接收重传数据分组后给发送方发送ACK
- ④:发送方收到ACK后发送下一个数据分组
- ⑤:接收方正确接收数据分组后发送方发送ACK
②:确认分组丢失(数据分组编号)
确认分组丢失(数据分组编号):如果接收方发送的ACK在传输过程中丢失,这必然造成发送方对之前所发送数据分组的超时重传,假如重传的数据分组也正确到了接收方,那么接收方应该如何判断该数据分组是否是一个重复的分组呢?因此,为了避免分组重复这种传输错误,必须给每个分组带上序号。对于停止-等待协议,由于每发送一个数据分组就停止等待,因此只要保证每发送一个新的数据分组,其发送序号与上次发送的数据分组序号不同就可以了,所以只需要一个比特进行编号
**如下图,收发双方基于互联网进行通信,纵坐标为时间,收发过程如下
- ①:发送方给接收方发送数据分组0
- ②:接收方正确接收数据分组0后给发送方发送ACK,但该ACK在传输过程中丢失
- ③:发送方未收到数据分组0的ACK或NAK,触发超时重传,于是重传数据分组0
- ④:接收方正确接收数据分组0发现该数据分组重复,于是丢弃重复分组,并给发送方发送ACK
- ⑤:发送方正确接收数据分组0的ACK后,发送下一个数据分组1
- ⑥:接收方正确接收数据分组1后,给发送方发送ACK
③:确认分组迟到(确认分组编号)
确认分组迟到(确认分组编号):如果接收方针对数据分组0所发送的ACK在传输过程中未能及时到达, 这会导致发送方对数据分组0进行超时重传,在重传过程中发送方又收到了那个迟到的数据分组0的ACK,于是就会发送数据分组1,接收方在收到重传的数据分组0后发现这是一个重复的数据分组,将其丢弃,并针对数据分组0发送ACK,但现在问题出现了:发送方如何能确认这个ACK到底针对的是哪个数据分组?发送方有可能会误认为这是针对数据分组1的ACK
为了解决这个问题,必须对ACK分组进行编号
**如下图,收发双方基于互联网进行通信,纵坐标为时间,收发过程如下
- ①:发送方发送数据分组0
- ②:接收方正确接收数据分组0后,发送ACK0
- ③:ACK0未能在重传时间内容到达,发送方重传数据分组0
- ④:迟到的ACK0现在到达,发送方发送数据分组1
- ⑤:接收方收到重传的数据分组0,发现分组重复,于是丢弃分组,并发送发ACK0
- ⑥:接收方收到数据分组1后,发送ACK1
- ⑦:发送方收到ACK0,发送ACK分组重复,于是忽略ACK0
- ⑧:发送刚收到ACK1后,发送下一个数据分组0
C:注意事项
-
接收端检测到数据分组有误码时,将其丢弃并等待发送方的超时重传。但对于误码率较高的点对点链路,为使发送方尽早重传,也可给发送方发送NAK分组
-
为了让接收方能够判断所收到的数据分组是否是重复的,需要给数据分组编号。由于停止等待协议的停等特性,只需1个比特编号就够了,即编号0和1
-
为了让发送方能够判断所收到的ACK分组是否是重复的,需要给ACK分组编号:,所用比特数量与数据分组编号所用比特数量一样。数据链路层一般不会出现ACK分组迟到的情况,因此在数据链路层实现停止-等待协议可以不用给ACK分组编号
-
超时计时器设置的重传时间应仔细选择。一般可将重传时间选为略大于“从发送方到接收方的平均往返时间”
- 在数据链路层点对点的往返时间比较确定,重传时间比较好设定。
- 然而在运输层,由于端到端往返时间非常不确定,设置合适的重传时间有时并不容易
D:停止等待协议信道利用率
- 有关信道利用率前文已经介绍(考研湖科大教书匠计算机网络)第一章概述-第四节:计算机网络的性能指标
停止等待协议信道利用率:如下图,假设收发双方之间是一条直通的信道,横坐标 t t t为时间。发送方发送完一个数据分组后就停止发送,并等待接收方对该数据分组的确认,当收到确认分组后可以发送下一个数据分组,如此反复进行。其中
- T D T_{D} TD:是发送方发送数据分组所耗费的发送时延
- R T T RTT RTT:收发双方之间的往返时延
- T A T_{A} TA:接收方发送确认分组所耗费的发送时延
于是 T D + R T T + T A T_{D}+RTT+T_{A} TD+RTT+TA就表示从发送一个数据分组开始到可以发送下一个数据分组为止所经历的总时间,由于仅仅是在 T D T_{D} TD时间内用来传送有用的数据(数据分组),因此信道利用率 U U U计算公式如下
U = T D T D + R T T + T A U=\frac{T_{D}}{T_{D}+RTT+T_{A}} U=TD+RTT+TATD
T A T_{A} TA一般远小于 T D T_{D} TD,故可以忽略
U = T D T D + R T T U=\frac{T_{D}}{T_{D}+RTT} U=TD+RTTTD
因此,当 R T T RTT RTT远大于 T D T_{D} TD时,信道利用率就会非常低,若出现重传,则对于传送有用的数据信息来说,信道利用率还会更低。所以这是停止-等待协议最大的缺点,为了解决这个问题,就产生了如下两种协议
- 后退N帧协议(GBN)
- 选择重传协议(SR)
这两种协议统称为滑动窗口协议,主要区别在于接收方窗口大小
E:滑动窗口协议
滑动窗口协议:在任意时刻,发送方维持一组连续的允许发送的分组序号,称为发送窗口,同时接收方也维持一组连续的允许接收的分组序号,称为接收窗口
- 发送窗口:在还未收到对方确认分组的情况下最多还可以发送多少个数据分组
- 接收窗口:控制可以或者不可以接受哪些数据分组
根据发送和接受窗口的大小不同,滑动窗口协议可以有三种
- 所以,停止-等待协议是一种特殊的滑动窗口协议(发送/接受窗口均为1)
发送窗口大小 | 接受窗口大小 | |
---|---|---|
停止-等待协议 | =1 | =1 |
后退N帧协议(GBN) | >1 | =1 |
选择重传协议(SR) | >1 | >1 |
(2)后退N帧协议(GBN)
为了方便讲述,这里用 n = 3 n=3 n=3个对数据分组进行编号,所以范围为 0 − 7 0-7 0−7
A:后退N帧协议中的发送窗口和接收窗口
发送窗口:由发送方进行维护,序号落在发送窗口内的数据分组可被连续发送,而不需要等到相应的确认分组到达后再发送。发送窗口的尺寸记为 W T W_{T} WT,其范围为
1 < W T ≤ 2 n − 1 1<W_{T}\leq 2^{n}-1 1<WT≤2n−1
n n n为构成分组序号的比特数量,本例中取3,因此可得 W T = 5 W_{T}=5 WT=5
- 如果 W T = 1 W_{T}=1 WT=1,则后退N帧协议就是停止等待协议
- 如果 W T W_{T} WT超过取值上限则会产生严重错误
如下图,落在发送窗口内的这个5个分组可以连续发送,落在发送窗口外的分组不允许发送
接收窗口:由接收方进行维护,序号落在接收窗口内的数据分组允许接收,之外的数据分组不允许接收。对于后退N帧协议,其接收窗口固定为1
B:无差错情况下的传输过程
无差错情况下的传输过程:以上面的发送窗口和接收窗口为例,在最简单也即没有差错情况下,传输过程如下
-
发送方将序号落在发送窗口内的0-4号数据分组依次连续发送出去
-
经过互联网传输正确无误地到达了接收方
-
接收方按序接收,每接收1个接收窗口就向前滑动1个位置,并给发送方发送针对所接收数据分组的确认分组
-
0-4号确认分组经过互联网传输正确到达发送方
-
发送方每接收1个发送窗口就向前滑动1个位置,这样就有新的序号落入了发送窗口
-
发送方将收到确认的数据分组从缓存中删除
-
接收方择机将已接收的数据分组交付上层处理
C:累积确认
累积确认:接收方不一定非要对收到的数据分组逐个确认,而是可以在收到几个数据分组后(由具体实现决定)对按序达到的最后一个数据分组发送确认,使用ACKn表示序号为n及其之前的所有数据分组都已被正确接收。使用累积确认优缺点如下
- 优点:
- 即使确认分组丢失,发送方也可能不必重传
- 可以减少接收方的开销,减少对网络资源的占用
- 缺点:
- 不能向发送方及时反映出接收方已经正确接收的数据分组信息
举例如下
-
发送方将序号落在发送窗口内的0-4号数据分组依次连续发送出去
-
经过互联网传输正确无误地到达了接收方
-
接收方按序接收。当接收完0号和1号数据分组后给发送方发送一个累积确认ACK1;当接受完2-4号数据分组后给发送方发送一个累积确认ACK4
-
假设ACK1在传输过程中丢失了,而ACK4正确到了发送方。发送方接收到ACK4后就明白了序号为4及之前的数据分组都已经被接收方正确接收了
D:有差错情况下的传输过程
有差错情况下的传输过程:
-
发送方将序号落在发送窗口内的这5个数据分组依次连续发送出去
-
经过互联网传输到达了接收方
-
假设它们在传输过程中受到了干扰,其中5号数据分组出现了误码,接收方通过检错码也发现了错误,于是接收方选择丢弃5号数据分组
-
后续到达的这个4个数据分组的序号与接收窗口中的序号不匹配
-
接收方同样也不能接受他们,因此丢弃,并对之前按序接收的最后一个数据分组进行确认,也即发送ACK4。需要注意,每丢弃一个数据分组就发送一个ACK4
-
这4个ACK4经过互联网的传输到达了发送方
-
当收到这些重复的ACK4时,就知道了之前所发送的数据分组出现了差错,于是可以不等超时计时器的超时时间就立即重传,至于收到几个重复的确认就立即重传,由具体实现决定
-
在本例中,假设收到这4个重复的确认并不会触发发送方立即重传,一段时间后,超时计时器超时,发送方将发送窗口内已发送的这些数据分组全部重传
可以看到,尽管序号为6、7、0、1的数据分组已经正确到达了接收方,但由于5号数据分组误码而不被接受,它们也受到牵连而被丢弃,发送方还需要重传这些数据分组,这就是所谓的后退N帧
另外,当通信线路质量不好时,后退N帧协议的信道利用率并不见得就比停止等待协议高
E:为什么发送窗口尺寸不能超过上限
对于上面的例子,采用3个比特给分组编号, W T W_{T} WT最大值为7,这里我们将 W T W_{T} WT设置为8,看看会发生什么
-
发送方将序号落在发送窗口内的0-7号这8个数据分组依次连续发送出去
-
经过互联网传输后正确无误地达到了接收方
-
接收方按序接收,给发送方发累积确认ACK7
-
假设ACK7在传输过程中丢失
-
这将导致发送方的超时重传,重传的0-7号数据分组到达接收方
-
现在问题出现了,接收方现在在重复接收分组,它无法分辨新旧分组,进而会产生分组重复这种差错