3.4 可靠传输
# 3.4 可靠传输
本节课我们介绍可靠传输的基本概念。
# 3.4.1 可靠传输基本概念
通过上节课的学习,我们已经知道使用差错检测技术,例如循环冗余校验crc,接收方的数据链路层,就可以检测出帧在传输过程中是否产生了误码,也就是出现比特错误。如下所示,帧在传输过程中受到干扰,产生了误码。接收方的数据链路层通过帧尾中的帧检验序列、FCS字段的值,也就是检测可以检测出帧中出现了比特差错,那么接下来该如何处理呢?
这取决于数据链路层向其上层提供的服务类型。如果提供的是不可靠传输服务,则仅仅丢弃有误码的帧,其他什么也不做。
如果提供的是可靠传输服务,那就还要想办法实现发送端发送什么,接收端就收到什么。例如接收方可以给发送方发送一个通知帧,告诉他之前发送的帧产生了误码,请重发。发送方收到通知后重发之前产生了误码的帧即可。实际上可靠传输的实现并没有我们想象的这么简单。试想一下,这个通知帧如果也出现了误码,又会怎么样?
本节课我们不会深入讨论实现可靠传输的具体方法,而是介绍可靠传输的基本概念。在后面的课程中,我们会详细介绍三种实现可靠传输的方法。一般情况下有线链路的误码率比较低,为了减小开销,并不要求数据链路层向上提供可靠传输服务,即使出现了误码,可靠传输的问题,由其上层处理。
然而对于无线链路,由于其容易受到干扰,误码率比较高,因此要求数据链路层必须向上层提供可靠传输服务。
需要说明的是比特差错只是传输差错中的一种。从整个计算机网络体系结构来看,传输差错还包括分组丢失,分组失序以及分组重复。请注意,此处我们将帧的称呼改为了分组,这意味着传输差错不仅仅局限于数据链路层的比特差错。
我们来举例说明,主机h6给主机h2发送的分组,到达了路由器R5,由于此时R5的输入队列快满了,R5根据自己的分组丢弃策略,将该分组丢弃,这是一种分组丢失的情况。
再来看分组失序的例子,主机h6依次给主机h2发送了三个分组,但他们并未按照发送顺序依次到达H2,也就是说最先发送的分组未必最先到达。
再来看分组重复的例子,主机H6给主机H2发送的分组,由于某些原因在网络中滞留了没有及时到达H2,这可能造成H6对该分组的超时重发,重发的分组到达H2一段时间后滞留在网络中的分组又到达了H2,这就会造成分组重复的传输差错。
分组丢失,分组失序以及分组重复这些传输差错,一般不会出现在数据链路层,而会出现在其上层。因此可靠传输服务并不仅局限于数据链路层,其他各层均可选择实现可靠传输服务。例如这是tcpip的4层体系结构,如果网络接口层使用的是802.11无线局域网,那么其数据链路层要求实现可靠传输,如果网络接口层使用的是以太网,那么其数据链路层不要求实现可靠传输,网际层中的IP协议向其上层提供的是无连接不可靠的传输服务。运输层中的TCP协议向其上层提供的是面向连接的可靠传输服务,而UDP协议向其上层提供的是无连接不可靠的传输服务,最后需要提醒大家注意,可靠传输的实现比较复杂,开销也就比较大,是否使用可靠传输取决于应用需求。
小结
# 3.4.2 可靠传输的实现机制 — 停止-等待协议
从本节课开始,我们将用几次课的时间来介绍三种可靠传输的实现机制,它们是停止等待协议SW,回退N帧协议GBN,选择重传协议SR。需要提醒大家注意的是,这三种可靠传输实现机制的基本原理,并不仅限于数据链路层,可以应用到计算机网络体系结构的各层协议中,希望同学们在学习时不要把思维局限在数据链路层,而应放眼于整个网络体系结构。
本节课我们介绍停止等待协议,如图所示,收发双方基于互联网进行通信,而不是局限在一条点对点的数据链路,纵坐标为时间。
发送方给接收方发送数据分组,接收方收到后对其进行差错检测,
若没有误码,则接受该数据分组,并给发送方发送确认分组,简称为ack。
发送方收到对所发送数据分组的确认分组后,才能发送下一个数据分组。
假设这个数据分组在传输过程中出现了误码,接收方收到后对其进行差错检测,发现了误码,则丢弃该数据分组,并给发送方发送否认分组,简称为nak。
发送方收到对所发送数据分组的否认分组后,就知道了之前自己所发送的数据分组出现了差错,而被接收方拒绝,于是立刻重传该数据分组。
因此发送方每发送完一个数据分组后,并不能立刻将该数据分组从缓存中删除,只有在收到帧对该数据分组的确认,分组后才能将其从缓存中删除。
看来每发送完一个数据分组后,就停止发送下一个数据分组,等待来自接收方的确认分组或否认分组。若收到确认分组,则可继续发送下一个数据分组。
若收到否认分组,则重发之前发送的数据分组,这样就要实现了发送方发送什么,接收方最终都能收到什么,也就是所谓的可靠传输。
但实际情况远比我们想象的要复杂。来看这种情况,发送方给接收方发送数据分组,然而该数据分组在传输过程中丢失了,需要说明的是对于数据链路层点对点信道而言,不太容易出现这种情况,但对于多个网络,通过多个路由器互联的复杂互联网环境而言,这种情况是会经常出现的。
对于这种情况,接收方既然收不到数据分组,那么也就不会无缘无故的发送确认或否认分组。如果不采取其他措施,发送方就会一直处于等待接收方确认或否认分组的状态。为了解决该问题,可以在发送方发送完一个数据分组时,启动一个超时计时器。若到了超时计时器所设置的重传时间,而发送方仍收不到接收方的确认或否认分组,则重传原来的数据分组,这就叫做超时重传。一般可将重穿时间选为略大于从发送方到接收方的平均往返时间。
如图所示发送方超时重传之前所发送的数据分组,接收方正确接收重传的数据分组后,给发送方发送确认分组,发送方收到确认分组后,发送下一个数据分组,接收方正确接收该数据分组后,给发送方发送确认分组,到目前为止,貌似基于停止等待,使用确认或否认分组,再加上超时重传的手段,就可以实现可靠传输了
但请大家再深入的思考一下,是否还会出现目前这些手段不足以应对实现可靠传输的其他情况?来看这种情况。既然发送方发送的数据分组可能丢失,那么接收方发送的确认或否认分组就也有可能丢失。例如发送方发送了一个数据分组,接收方正确接收该数据分组后,给发送方发送确认分组,但该确认分组在传输过程中丢失了,这必然会造成发送方对之前所发送数据分组的超时重传,假设重传的数据分组也正确到达了接收方。那么现在问题来了,接收方如何判断该数据分组是否是一个重复的分组?
为了避免分组重复这种传输错误,必须给每个数据分组带上序号。例如该数据分组的序号为0,对于停止等待协议,由于每发送一个数据分组,就进行停止等待,只要保证每发送一个新的数据分组,其序号与上次发送的数据分组的序号不同就可以了。因此用一个比特来编号就够了。即序号0和1,这样根据数据分组的序号,接收方就可以判断出该数据分组是否是重复的,接收方丢弃重复的数据分组,并给发送方发送帧对该数据分组的确认分组,以免发送方对该数据分组的再次超时重传。
发送方收到帧对0号数据分组的确认分组,就可以发送下一个数据分组了,其序号为1,接收方正确收到1号数据分组后,给发送方发送确认分组,我们通过确认分组丢失的情况,引出了给数据分组编号的问题。请大家思考一下,既然数据分组需要编号,那么确认分组是否也需要编号?
来看这种情况,发送方 发送0号数据分组,接收方正确接收后,给发送方发送确认分组,由于某些原因,该确认分组迟到了,这必然会导致发送方对0号数据分组的超时重传。在重传的0号数据分组的传输过程中,发送方收到了迟到的确认分组,于是发送一号数据分组,接收方收到重传的零号数据分组后,发现这是一个重复的数据分组,将其丢弃,并针对该数据分组给发送方发送确认分组,以免发送方再次超时重传该数据分组。现在问题来了,我们可以非常清楚的看到,这是一个对0号数据分组的重复确认,但是发送方又如何知道呢?如果不采取其他措施的话,发送方会误认为这是对1号数据分组的确认,如果对确认分组也进行编号,就可以使发送方避免这种误判。如图所示该确认分组的序号为0,发送方通过确认分组的序号,知道这是一个重复的确认分组,忽略即可。接收方正确接受一号数据分组后,给发送方发送帧对该数据分组的确认,分组其序号为一,发送方收到该确认分组后,发送下一个数据分组,序号为0。
请注意该数据分组与之前序号为0的数据分组,不是同一个数据分组,我们用给确认分组编号的方法,解决了确认迟到所导致的重复确认的问题。需要说明的是对于数据链路层的点对点信道,往返时间比较固定,不会出现确认迟到的情况。
因此如果只在数据链路层实现停止等待协议,可以不用给确认分组编号。接下来我们对停止等待协议的一些注意事项进行一下小结
- 接收端检测到数据分组有误码时,将其丢弃,并等待发送方的超时重传。但对于误码率较高的点对点链路,为使发送方尽早重传,也可给发送方发送否认分组。
- 为了让接收方能够判断所收到的数据分组是否是重复的,需要给数据分组编号,由于停止等待协议的停等特性,只需一个比特编号就够了,即序号0和1
- 为了让发送方能够判断所收到的确认分组是否是重复的,需要给确认分组编号,所用比特数量与数据分组编号所用比特数量一样,数据链路层一般不会出现确认分组迟到的情况,因此在数据链路层实现停止等待协议,可以不用给确认分组编号,
- 超时计时器设置的重装时间应仔细选择,一般可将重装时间选为略大于从发送方到接收方的平均往返时间。
- 在数据链路层点对点的往返时间比较确定,重传时间比较好设定。然而在运输层,由于端到端往返时间非常不确定,设置合适的重装时间有时并不容易,我们将在第5章有关TCP协议的课程中详细讨论该问题。
接下来我们来看看停止等待协议的信道利用率。如图所示,横坐标为时间。为了简单起见,假设收发双方之间是一条直通的信道,发送方发送完一个数据分组后,就要停止发送,并等待接收方对该数据分组的确认。当收到确认分组后可以发送下一个数据分组,如此反复进行,这一段时间是发送方发送数据分组所耗费的发送时延TD,这一段时间是收发双方之间的往返时间RTT,这一段时间是接收方发送确认分组所耗费的发送时延TA,途中忽略了接收方对数据分组的处理时延,以及发送方对确认分组的处理时延,这是使用停止等待协议的发送方,从发送一个数据分组开始,到可以发送下一个数据分组为止,所经历的总时间,因为仅仅是在时间TD内才用来传送有用的数据,也就是数据分组。因此信道的利用U可以用下式来计算,
TA一般都远小于TD,可以忽略,当儿RTT远大于TD时,信道利用率会非常低。
我们来举例说明,假设信道长度为2000公里,数据分组长度为1500字节,发送速率为10兆比特每秒,忽略TA,因为TA一般都远小于TD,可以计算出信道利用率约为5.66%,这是数据分组的发送时延TD,这是往返时间RTT。
如果将发送速率提高到100兆比特每秒,则可计算出信道利用率仅为0.6%。这是数据分组的发送时延TD,这是往返时间RTT
可以看出当往返时延rtt远大于数据帧发送时延TD时,例如使用卫星链路,信道利用率非常低,若出现重传,则对于传送有用的数据信息来说,信道利用率还要降低。为了克服停止等待协议信道利用率很低的缺点,就产生了另外两种协议及后退N帧协议GBN,和选择重穿协议SRr。
最后我们来做一道有关停止等待协议的练习题。这是计算机专业考研全国统考计算机网络部分2018年的题36,
答案是d选项,我们一起来分析该题,根据提议可以画出停止等待协议的示意图,这一段是数据帧的发送时延,这一段是数据帧的最后一比特信号,从主机甲传播到主机乙所耗费的传播实验,也就是信号在两主机之间的单程传播实验。同理,这一段也是单程传播时延,停止等待协议的信道利用率等于数据帧的发送时延除以数据帧发送时延加端到端往返时延,也就是两倍的单程传播时延,设数据帧长度为x个比特,将其与题目所给的相关已知量代入上式可得解得x等于800比特
像停止等待协议这种通过确认和重传机制实现的可靠传输协议,常称为自动请求重传协议ARQ,意思是重传的请求是自动进行的,因为不需要接收方显示的请求,发送方重传某个出错的分组
小结
# 3.4.3 回退N帧协议
在上节课中我们介绍了停止等待协议,如图所示,发送方每发送完一个数据分组,就要停止发送,并等待接收方的确认分组。当收到接收方的确认分组后,才能发送下一个数据分组,如此反复进行。
从图中可以看出,每发送完一个数据分组,至少要等待一个收发双方之间的往返时间。当往返时间较大时,例如卫星链路,停止等待协议的信道利用率很低,若出现超时重传,则信道利用率更低。
如图所示,如果发送方在收到接收方的确认分组之前,可以连续发送多个数据分组,则可大大提高信道利用率。这是一种流水线式的传说。就本例而言,同等条件下,在相同的时间内,使用停止等待协议的发送方,只能发送一个数据分组,而采用流水线传输的发送方可以发送5个数据分组。
本节课我们介绍回退N帧协议,该协议在流水线传输的基础上,利用发送窗口,来限制发送方可连续发送分组的个数。我们来举例说明,假设采用三个比特给分组编序号,因此序号的取值范围是0~7,如图所示,这是收发双方各自的分组序号,当序号增加到7,下一个序号又从0开始,发送方要维持一个发送窗口,序号落在发送窗口内的数据分组,可被连续发送,而不必等收到接收方的相应确认分组后再发送。发送窗口的尺寸即为WT。对于本例其取值范围是大于1,小于等于2^3^-1,其中的3是构成分组序号的比特数量,本例取wt的值为5,如果WT的值取为一,则是停止等待协议。如果WT的值超过取值范围的上限,则会造成严重的错误,我们之后会举例详细说明。
如图所示序号落在发送窗口内的这5个数据分组,可以连续发送,而序号落在发送窗口外的数据分组,不允许发送。
接收窗口的尺寸即为WR。对于回退n帧协议,其取值只能为一,这一点与停止等待协议是相同的。如图所示序号落在接收窗口内的数据分组,允许接收,而序号落在接收窗口外的数据分组不允许接收。
我们首先来看最简单的情况,也就是无差错的情况:
- 发送方将序号落在发送窗口内的0~4号数据分组,依次连续发送出去
- 他们经过互联网的传输,正确到达了接收方,也就是没有出现乱序和误码
- 接收方按序接收他们。每接收一个接收窗口就向前滑动一个位置,并给发送方发送帧对所接收分组的确认分组。
- 0~4号确认分组,经过互联网的传输,正确到达了发送方,每接收一个发送窗口就向前滑动一个位置,这样就有新的序号落入了发送窗口,发送方可以将收到确认的数据分组,从缓存中删除了
- 而接收方可以择机将已接收的数据分组交付上层处理。
接下来我们来看累积确认的概念,使用回退N帧协议的接收方可以采用累积确认的方式,也就是说接收方不一定要对收到的数据分组逐个发送确认,而是可以在收到几个数据分组后,对按序到达的最后一个数据分组发送确认,ackn表示序号为n及以前的所有数据分组都已正确接收了。
我们来举例说明累计确认。发送方将序号落在发送窗口内的0~4号数据分组,依次连续发送出去,他们经过互联网的传输,正确到达了接收方按序接收他们。当接收完0号和1号数据分组后,给发送方发送了一个累积确认ack1,当接收完2~4号数据分组后,又给发送方发送了一个累计确认ack4,假设ack1在传输过程中丢失了,而ack4正确到达了发送方,发送方接收ack4后就知道了,序号为4及之前的数据分组已被接收方正确接收了,于是将发送窗口向前滑动5个位置,这样就有新的序号落入了发送窗口,发送方可以将收到确认的数据分组从缓存中删除了,而接收方可以择机将已接收的数据分组交付上层处理。
从本例可以看出,使用累计确认的其中一个优点,就是即使确认分组丢失,发送方也可能不必重传。例如本例ack1丢失了,但并没有造成一号数据分组的超时重传
使用累计确认还有其他好处。比如可以减小接收方的开销,减少对网络资源的占用等。当然了使用累计确认也有缺点,那就是不能向发送方及时反映出接收方已经正确接收的、数据分组的信息。
接下来我们来看出现差错的情况,发送方将序号落在发送窗口内的这5个数据分组,依次连续发送出去,他们经过互联网的传输到达了接收方,假设他们在传输过程中受到了干扰,其中5号数据分组出现了误码,接收方通过数据分组中的检错码发现了错误,于是丢弃该数据分组。而后续到达的这4个数据分组的序号与接收窗口中的序号不匹配,接收方同样也不能接受他们,将他们丢弃,并对之前按序接收的最后一个数据分组进行确认,也就是发送ack4,每丢弃一个数据分组,就发送一个ack4,这4个ack4经过互联网的传输到达了接收方,发送方之前就接收过ack4,当收到这些重复的ack4时,就知道了之前所发送的数据分组出现了差错,于是可以不等超时计时器超时就立刻开始重传。
至于收到几个重复确认,就立刻重传,由具体实现来决定。在本例中,假设收到这4个重复的确认,并不会触发发送方立刻重传。一段时间后,超时计时器出现超时,发送方将发送窗口内已发送过的这些数据分组全部重传。在本例中,尽管序号为6701的数据分组,之前已经正确的到达接收方,但由于5号数据分组误码不被接受,他们也受到牵连而不被接受。
发送方还要重传这些数据分组,这就是所谓的go back-n也就是回退n帧。可见当通信线路质量不好时,回推N帧协议的信道利用率并不比停止等待协议高。
接下来我们来看看,如果发送窗口的尺寸,WT超过其取值范围的上限会出现什么情况?
对于本例,采用三个比特给分组编序号,wt的最大值为2的三次-1,也就是7,我们故意超过该上限将WT取值为8,发送方将序号落在发送窗口内的0~7号这8个数据分组依次连续发送出去,他们经过互联网的传输,正确到达了接收方,接收方按序正确接收他们号,给发送方发回累计确认ack7。
假设ack7在传输过程中丢失了,这将导致发送方的超时重传重传的0~7号数据分组到达接收方。现在问题来了,接收方根据当前接收窗口内的序号,会对这8个数据分组按序接收,但是接收方之前已经接收过这8个数据分组了,现在是在重复接收,也就是说接收方无法分辨新旧分组,进而会产生分组重复这种传输差错,因此发送窗口的尺寸不能超过其上限。
接下来我们对回退n帧协议的工作原理进行一下小结。发送窗口尺寸wt的取值范围是大于1,小于等于2的n次-1,其中 n是构成分组序号的比特数量,若wt等于1则变回了停止等待协议,若WT>2的n次-1,则会造成接收方无法分辨新旧数据分组的问题。
接收方的接收窗口尺寸WR只能等于1,因此接收方只能按序接收数据分组,发送方可在未收到接收方确认分组的情况下,将序号落在发送窗口内的多个数据分组全部发送出去,接收方只接受序号落在接收窗口内,且无误码的数据分组,并且将接收窗口向前滑动一个位置。与此同时,给发送方发回相应的确认分组。
为了减少开销,接收方不一定每收到一个按需到达且无误码的数据分组,就给发送方发回一个确认分组,而是可以在连续收到好几个按需到达,且无误码的数据分组后,才针对最后一个数据分组发送确认分组,这要成为累计确认,或者可以在自己有数据分组要发送时,才对之前按序接收,无码的数据分组进行捎带确认。
接收方收到未按需到达的数据分组,除丢弃外,还要对最近按序接收的数据分组进行确认。
发送方只有收到对已发送数据分组的确认时,发送窗口才能向前相应滑动。发送方收到多个重复确认时,可在重传计时器超时前尽早开始重传,由具体实现决定,
发送方发送窗口内,某个已发送的数据分组产生超时重发时,其后续在发送窗口内且已发送的数据分组也必须全部重传,这就是回退n帧协议名称的由来。
接下来我们来做一个有关回退n帧协议的练习,这是计算机专业考研全国统考计算机网络部分2009年的提35
答案是选项c大家都选对了吗?题目所给发送方只收到023号帧的确认,这就表明接收方正确接收了0~3号帧,并帧对他们中的每一个发送了确认帧,只不过帧对一号帧的确认帧丢失了,这是题目中的陷阱,但又没有相应的选项,所以迷惑性并不是很大。截止到计时器超时,发送方只收到了帧对023号帧的确认,而发送方之前已经发送了0~7号帧,因此应该从4号帧开始重传,即重传之前已经发送过的4567号帧,共计重传4个帧。
我们再来画个示意图,以便更容易理解该题。假设这是帧可用的序号,这是发送窗口,发送方将序号落在发送窗口内的0~7号数据帧依次发送出去,当收到帧对0号数据帧的确认帧ack零时,发送窗口向前移动一个位置。若收到帧对1号数据帧的确认帧ack一时发送窗口也会向前移动一个位置,只不过 ack1在传输过程中丢失了,当收到帧对2号数据帧的确认帧ack2,发送窗口向前移动两个位置,将序号1和2全部移出发送窗口。
当收到帧对三号数据帧的确认帧ack3,发送窗口向前移动一个位置,之后发送方出现了超时,将发送窗口内已发送但未收到确认的4567号数据帧依次重传,
本节课的内容小结如下,回退N帧协议在流水线传输的基础上,利用发送窗口来限制发送方连续发送数据分组的数量,是一种连续ARQ协议。在协议的工作过程中,发送窗口和接收窗口不断向前滑动,因此这类协议要称为滑动窗口协议。由于回退n帧协议的特性,当通信线路质量不好时,其信道利用率并不比停止等待协议高。下节课我们将介绍选择重传协议,他是对回退N帧协议的改进。
# 3.4.4 选择重传协议
在上节课中我们介绍了回退n帧协议,回退n帧协议的接收窗口尺寸WR只能等于1,因此接收方只能按需接收正确到达的数据分组,一个数据分组的误码,就会导致其后续多个数据分组不能被接收方按序接收而丢弃,尽管他们没有误码,这必然会造成发送方对这些数据分组的超时重传,显然这是对通信资源的极大浪费。
为了进一步提高性能,可设法只重传出现误码的数据分组。因此接收窗口的尺寸w不应再等于一,而应大于1,以便接收方先收下失序到达,但无误码,并且序号落在接受窗口内的那些数据分组,等到所缺分组收齐后,再一并送交上层。这就是本节课所要介绍的选择重传协议。需要注意的是选择重传协议,为了使发送方仅重传出现差错的数据分组,接收方不能再采用累积确认,而需要对每个正确接收到的数据分组进行逐一确认。
下面我们来举例说明,选择重传协议的工作原理。假设采用三个比特给分组编序号,因此序号的取值范围是0~7,如图所示这是发送方的分组序号,这是接收方的分组序号。
当序号增加到7是,下一个序号又从0开始,发送窗口的尺寸,wt的取值范围是大于1,小于等于2的3次方-1次。其中的三是构成分组序号的比特数量,本例取wt的值为4,如图所示序号落在发送窗口内的这4个数据分组可以连续发送,而序号落在发送窗口外的数据分组不允许发送。
接收窗口的尺寸WR的取值,一般情况下可以发送窗口的尺寸WT的取值相同,在本例中其值为4,如图所示序号落在接收窗口内的这4个数据分组允许接收,而序号落在接收窗口外的数据分组不允许接收
发送方将序号落在发送窗口内的这4个数据分组,依次连续发送出去,他们经过互联网的传输陆续到达接收方,但其中的2号数据分组丢失了,只要序号落入接收窗口内,且无误码的数据分组,接收方都会接收。接收方接收0号和1号数据分组,并发送0号和1号确认分组,接收窗口向前滑动两个位置,这样就有4和5这两个新的序号落入接收窗口,接收方接收3号数据分组,并发送3号确认分组,但接收窗口不能向前滑动,因为3号数据分组是未按需到达的数据分组,这些确认分组经过互联网的传输,陆续到达发送方,每按序收到1个确认分组,发送窗口就向前滑动1个位置
发送方接收0号和1号确认分组,发送窗口向前滑动两个位置,这样就有4和5这两个新的序号落入发送窗口,发送方将序号落入发送窗口的4号和5号数据分组发送出去,发送方现在可以将已经收到确认的0号和1号数据分组从发送缓存中删除了,而接收方可择机将以按需接收的0号和1号数据分组交付上层处理
发送方接收三号确认分组,但发送窗口不能向前滑动,因为这是一个未按需到达的确认分组,发送方还未收到他之前的2号确认分组,不过需要记录3号数据分组已收到确认,这样该数据分组就不会超时重发。4号和5号数据分组到达接收方,接受方接受他们,并发送4号和5号确认分组,但接收窗口不能向前滑动,因为他们是未按需到达的数据分组,接收方还未收到他们之前的2号数据分组。
假设在4号和5号确认分组的传输过程中,发送方帧对2号数据分组的重传计时器超时了,发送方重传23号数据分组,4号和5号确认分组陆续到达发送方,发送方接收他们,但发送窗口不能向前滑动,因为他们是未按时到达的确认分组,发送方还未收到他们之前的2号确认分组,不过需要记录4号和5号数据分组已收到确认,这样他们就不会超时重发。
发送方之前重传的二号数据分组到达接收方,接收方接收该数据分组,并发送2号确认分组,接受窗口现在可以向前滑动4个位置,这样就有6701这4个新的序号落入接收窗口。
2号确认分组,经过互联网的传输,到达发送方,发送方接收该确认分组,发送窗口现在可以向前滑动4个位置,这样就有6701这4个新的序号落入发送窗口,发送方现在就可以继续将这4个序号的数据分组依次发送出去了。
接下来我们再来讨论一下,选择重传协议的发送窗口和接收窗口的尺寸问题。发送方的发送窗口尺寸wt必须满足大于1小于等于2的n减一次,其中n是构成分组序号的比特数量。若wt等于1则与停止等待协议相同,若wt>2的n减一次,则会造成接收方无法分辨新旧数据分组的问题。
接收方的接收窗口尺寸,WR必须满足大于一,小于等于wt。若WR等于1则与回退n帧协议相同,若WR大于wt,则没有意义。
下面我们就来看看,如果发送窗口和接收窗口的尺寸超过了他们的取值范围,会出现什么样的情况?我们还是采用三个比特给分组编序号,即序号0~7,发送窗口的尺寸,wt取最大值,接收窗口的尺寸WR也取最大值,也就是wt等于WR=2的3-1次=4。假设我们故意将发送窗口尺寸WT设置为5,相应的将接收窗口尺寸wr也设置为5,看看会出现什么情况。
发送方将序号落入发送窗口内的0~4号这5个数据分组依次发送出去,他们经过互联网的传输,依次到达接收方,接收方接收他们,并发送0~4号确认分组,接收窗口向前滑动5个位置,这样就有56701这5个新的序号落入接收窗口
这些确认分组经过互联网的传输,陆续到达发送方,但其中的0号确认分组丢失了,发送方接收1~4号确认分组,并记录1~4号数据分组已收到确认,发送窗口不能向前移动。
一段时间后,0号数据分组的重传计时器超时了,发送方重传0号数据分组,该数据分组经过互联网的传输到达接收方,其序号0落在接收窗口内,接收方会接收它,但是接收方先前已经正确接收过该数据分组了,如果现在还要接收,那就会出现分组重复这种传输差错。也就是说如果发送窗口和接收窗口的尺寸超过了取值范围,就会使接收方无法分辨新旧数据分组,进而出现分组重复这种传输差错。
接下来我们对选择重传协议的工作原理进行一下小结,这是我们刚刚举例说明过的,发送窗口和接收窗口的尺寸问题,就不再赘述了。发送方可在未收到接收方确认分组的情况下,将序号落在发送窗口内的多个数据分组全部发送出去,接收方可接收未按需到达,但没有误码,并且序号落在接收窗口内的数据分组。
为了使发送方仅重传出现差错的分组,接收方不能再采用累计确认,而需要对每个正确接收到的数据分组进行逐一确认。
接收方只有在按序接收数据分组后,接收窗口才能向前相应滑动。
发送方只有按序收到,对已发送数据分组的确认分组时,发送窗口才能向前相应滑动。
若收到未按需到达的确认分组,应对其进行记录,以防止其相应数据分组的超时重发,但发送窗口不能向前滑动。
接下来我们来做一个有关选择重传协议的练习。这是计算机专业考研全国统考计算机网络部分2011年的题35
答案是选项b,与回退n帧协议不同,选择重穿协议,不支持累计确认,接收方每接收一个数据帧,就会发回相应的确认帧,题目所给收到一号帧的确认,而0号和2号帧依次超时,因此需要重传0号和2号帧。至于发送方已发送的三号数据帧,题目并未给出它的任何其他线索,因此无需考虑3号帧。
我们再来画个示意图,以便更容易理解该题。假设这是帧可用的序号,这是发送窗口,发送方将序号落在发送窗口内的0~3号数据帧依次发送出去之后,收到了1号帧的确认,而0号和2号帧的重传计时器超时,因此需要重传的就是0号和2号这两个帧。
本节课的内容小结如下