3.4、可靠传输
3.4.1、基本概念
使用差错检测技术\color{red}差错检测技术差错检测技术(例如循环冗余校验 CRC
),接收方的数据链路层就可检测出帧在传输过程中是否产生了误码\color{red}误码误码(比特错误)。
数据链路层向上层提供的服务类型
- 不可靠传输服务\color{red}不可靠传输服务不可靠传输服务:仅仅丢弃有误码的帧\color{red}仅仅丢弃有误码的帧仅仅丢弃有误码的帧,其他什么也不做;
- 可靠传输服务\color{red}可靠传输服务可靠传输服务:想办法实现发送端发送什么,接收端就收到什么\color{red}发送端发送什么,接收端就收到什么发送端发送什么,接收端就收到什么。
例如:
- 接收方可以发送给发送发一个通知帧,告诉它:“之前发送的帧产生了误码,请重发”。
- 发送方收到通知后,重发之前产生了误码的那个帧即可
若通知帧也出现了误码,又会怎么样呢?
一般情况下,有线链路\color{red}有线链路有线链路的误码率比较低,为了减小开销,并不要求数据链路层\color{red}不要求数据链路层不要求数据链路层向上提供可靠\color{red}可靠可靠传输服务。即使出现了误码,可靠传输的问题由其上层处理。
无线链路\color{red}无线链路无线链路易受干扰,误码率比较高,因此要求数据链路层\color{red}要求数据链路层要求数据链路层必须向上层提供可靠\color{red}可靠可靠传输服务。
比特差错\color{red}比特差错比特差错只是传输差错中的一种。
从整个计算机网络体系结构来看,传输差错还包括分组丢失\color{red}分组丢失分组丢失、分组失序\color{red}分组失序分组失序以及分组重复\color{red}分组重复分组重复。
分组丢失、分组失序以及分组重复这些传输差错,一般不会出现在数据链路层,而会出现在其上层。
可靠传输服务并不仅局限于数据链路层\color{red}可靠传输服务并不仅局限于数据链路层可靠传输服务并不仅局限于数据链路层,其他各层均可选择实现可靠传输。
例如:
可靠传输的实现比较复杂,开销也比较大,是否使用可靠传输取决于应用需求。
3.4.1.1、分组丢失
主机 H6
给主机 H2
发送的分组到达了路由器 R5
。
由于此时 R5
的输入队列快满了。
R5
根据自己的分组丢弃策略将该分组丢弃
3.4.1.2、分组失序
主机 H6
给主机 H2
发送了 333 个分组。
它们并未按照发送顺序依次到达 H2
。(最先发送的分组未必最先到达)
3.4.1.3、分组重复
主机 H6
给主机 H2
发送的分组。由于某些原因在网路中滞留了,没有及时到达 H2
这可能造成了 H6
给 H2
的超时重发,重发的分组到达了 H2
。一段时间后,滞留在网络中的那个分组又到达了 H2
这又会造成分组重复的传输差错
注意:
- 以下三种可靠传输实现机制的基本原理并不仅限于数据链路层,
- 可以应用到计算机网络体系结构的各层协议中。
3.4.2、停止-等待协议 SW
每发送一个数据分组就进行停止等待
3.4.2.1、误码情况
若收发双方基于互联网进行通信,而不是局限在一条点对点的数据链路。
-
发送方给接收方发送数据分组,接收方收到后对其进行差错检测。
-
若没有误码,则接受该分组,并给发送方发送确认分组,简称为
ACK
-
发送方收到对所发送方数据分组的确认分组后,才能发送下一个数据分组。
-
假设这个数据分组在传输过程中出现了误码.
-
接收方收到后对其进行差错检测。发现了误码,则丢弃该数据分组
-
并给发送发发送否认分组(
NAK
) -
发送方收到所发送数据分组的否认分组后,就知道了之前自己所发送的数据分组出现了差错而被接收方拒绝
-
于是立刻重传该数据分组
-
因此,发送方每发送一个数据分组后,并不能立刻将该数据分组从
缓存
中删除,只有在收到针对该数据分组的确认分组后,才能将其从缓存中删除
3.4.2.2、数据丢失情况
发送方发送的数据分组丢失
3.4.2.3、确认/否认丢失情况
接收方发送的确认或否认分组就也有可能丢失
接收方丢弃重复的数据分组,并给发送方发送针对该数据分组的确认分组。
以免发送方对该数据分组的再次超时重传
3.4.2.4、确认分组迟到情况
由于某些原因,该确认分组迟到了
,这必然会导致发送方对 000 号数据分组的超时重传
在重传的 000 号分组的传输过程中,发送方收到了迟到的确认分组,于是发送 111 号分组
发送方如何知道这是一个对 000号分组的重复确认
。
若不采取其他措施,发送会误认为这是对 111 号数据分组的确认。
若对确认分组也进行编号,就可以使发送方避免这种误判
因此,若只在数据链路层实现停止-等待协议,可以不用给确认分组编号
3.4.2.5、注意事项
-
接收端检测到数据分组有误码时,将其丢弃并等待发送方的超时重传。
- 但对于误码率较高的点对点链路,为使发送方尽早重传\color{red}尽早重传尽早重传,也可给发送方发送NAK分组\color{red}也可给发送方发送 NAK 分组也可给发送方发送NAK分组
-
为了让接收方能够判断所收到的数据分组是否是重复的,需要给数据分组编号\color{red}数据分组编号数据分组编号。
- 由于停止-等待协议的停等特性,只需1个比特编号\color{red}只需 1 个比特编号只需1个比特编号就够了,即编号 000 和 111 。
-
为了让发送方能够判断所收到的
ACK
分组是否是重复
的,需要给 ACK分组编号\color{red}ACK 分组编号ACK分组编号,所用比特数量与数据分组编号所用比特数量一样\color{red}与数据分组编号所用比特数量一样与数据分组编号所用比特数量一样。- 数据链路一般不会出现
ACK
分组迟到的情况,因此在数据链路层实现停止−等待协议可以不用给ACK分组编号\color{red}数据链路层实现停止-等待协议可以不用给ACK分组编号数据链路层实现停止−等待协议可以不用给ACK分组编号。
- 数据链路一般不会出现
-
超时计时器设置的重传时间\color{red}重传时间重传时间应仔细选择。
-
一般可将重传时间选为 略大于“从发送方到接收方的平均往返时间”。\color{red}略大于“从发送方到接收方的平均往返时间”。略大于“从发送方到接收方的平均往返时间”。
-
在
数据链路层
点对点的往返时间比较确定,重传时间比较好设定。 -
然而在
运输层
,由于端到端往返时间非常不确定,设置合适的重传时间有时并不容易。
-
3.4.2.6、信道利用率
TDT_DTD :发送方发送数据分组所耗费的发送时延 TD
(仅仅在 TDT_DTD 内才用来传送有用的数据,也就是数据分组)
RTTRTTRTT:收发双方之间的往返时间 RTTRTTRTT
TAT_ATA:接受方发送确认分组所耗费的发送时延 TAT_ATA
此处忽略了就收方对数据分组的处理时延,以及发送方对确认分组的处理时延
当往返时延RTT远大于数据帧发送时延TD时(例如使用卫星链路),信道利用率非常低。\color{red}当往返时延RTT远大于数据帧发送时延T_D时(例如使用卫星链路),信道利用率非常低。当往返时延RTT远大于数据帧发送时延TD时(例如使用卫星链路),信道利用率非常低。
若出现重传
,则对于传送有用的数据信息来说,信道利用率还要降低。
为了克服停止-等待协议信道利用率很低的缺点,就产生了另外两种协议
- 即后退N帧协议
GBN
和 选择重传协议SR
。
3.4.2.7、习题
解析:
3.4.3、回退 N 帧协议 GBN
此协议在流水线传输的基础上,利用发送窗口
来限制
发送方可连续发送数据分组的个数
收发双发各自的分组序号,当序号增加到 777 时,下一个序号又从 000 开始。
发送方维持一个发送窗口,序号落在发送窗口内的数据分组可被连续发送,而不必等收到接受方的相应确认分组后再发送
1<WT≤23−11 < W_T \le 2^3 - 11<WT≤23−1 :其中的 333 是构成分组序号的比特数量。
- 若 WT=1W_T = 1WT=1,则是停止-等待协议
- 若 WTW_TWT 超过取值范围的上限,则会造成严重的错误
对于回退 NNN 帧协议, WRW_RWR 只能为 111
3.4.3.1、无差错情况
发送方将序号落在发送窗口内的 0−40 - 40−4 号数据分组,依次连续发送出去
他们经过互联网的传输正确到达了接收方。
接收方按序接受他们,每接收一个,接收窗口就向前滑动一个位置,并给发送方发送针对所接受分组的确认分组
发送方每接收一个,发送窗口就向前滑动一个位置
- 这样就有新的序号落入了发送窗口。发送方可以将确认的数据分组从缓存中删除了。
而接收方可以择机将已接受的数据分组交付上层处理
3.4.3.2、累计确认
发送方将序号落在发送窗口内的 0−40 - 40−4 号数据分组,依次连续发送出去。
他们经过互联网的传输正确到达了接收方。
接收方按序接受他们:
- 当接收完 000 号和 111 号数据分组后,给发送方发送了一个累计确认
ACK1
。 - 当接收完 2−42 - 42−4 号数据分组后,给发送方发送了一个累计确认
ACK4
。
假设 ACK1
再传输过程中丢失了,ACK4
正确到达了发送方。
发送方接受 ACK4
后就知道了序号为 444 及之前的数据分组已被接收方正确接收了。
- 于是将发送窗口向前滑动 555 个位置
- 这样就有新的序号落入了发送窗口。发送方可以将确认的数据分组从缓存中删除了。
而接收方可以择机将已接受的数据分组交付上层处理
例如:
- 本例中
ACK1
丢失了,但并没有造成 111 号数据分组的超时重传。
使用累计确认还有其他好处
- 例如:可以减少接收方的开销,减少对网络资源的占用
缺点
- 不能向发送方
及时反应
出接收方已经正确接收的数据分组信息
3.4.3.3、有差错情况
发送方将序号落在发送窗口内的这 555 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。
假设他们再传输过程中受到了干扰,其中 555 号数据分组出现了误码
-
接收方通过数据分组中的检错码发现了错误,于是丢弃该数据分组
-
而后序到达的这 444 个数据分组的序号与接受窗口的序号不匹配
-
接收方同样也不能接受他们,将他们
丢弃
。 -
接收方并对之前按序接受的最后一个数据分组进行确认,(也就是发送
ACK4
) -
每丢弃一个数据分组,就发送一个
ACK4
。 -
这 444 个
ACK4
经过互联网的传输到达了发送方
假设收到这 444 个重复的确认并不会
触发发送方立刻重传。
一段时间后,超时计时器出现超时,发送方将发送窗口内已发送过的这些数据分组全部重传。
发送方将序号落在发送窗口内的这 0−70 -70−7 这 888 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。
接收方按序正确接受他们后,给发送方发回累积确认 ACK7
假设 ACK7
在传输过程中丢失了,这将导致发送方的超时重传。
- 重传的 0−70 -70−7 号数据分组到达接收方。
- 进而会产生分组重复这种传输差错。
因此,发送窗口的尺寸不能超过其上限
3.4.3.4、小结
3.4.3.5、习题
解析:
3.4.4、选择重传协议 SR
3.4.4.1、工作原理
收发双发各自的分组序号,当序号增加到 777 时,下一个序号又从 000 开始。
发送方维持一个发送窗口,序号落在发送窗口内的数据分组可被连续发送,而不必等收到接受方的相应确认分组后再发送
说明:
- 若每个序号 等于 一个数据分组,那么发送方将在发送窗口的序号直接发送出去,不需要找的过程
- 若这是分组序号表,那么发送方找到对应的数据分组发送出去
1<WT≤23−11 < W_T \le 2^3 - 11<WT≤23−1 :其中的 333 是构成分组序号的比特数量。
- 若 WT=1W_T = 1WT=1,则是停止-等待协议
- 若 WTW_TWT 超过取值范围的上限,则会造成严重的错误
发送方将序号落在发送窗口内的这 444 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。
但是其中的 222 号数据分组丢失了,只要序号落入接收窗口内且无误码的数据分组,接收方都会接受
-
接收方接受 000 号和 111 号数据分组,并发送 000 号和 111 号确认分组。
-
接受窗口向前滑动两个位置,这样就有 444 和 555 这两个新的序号进入接收窗口。
-
接收方接受 333 号数据分组,并发送 333 号确认分组,但接受窗口不能向前滑动
- 因为 333 号数据分组是
未按序
到达的数据分组。
- 因为 333 号数据分组是
这些确认分组经过互联网的传输到达了发送方。
- 发送方每按序收到一个确认分组,发送窗口就向前滑动一个位置。
- 发送方接受 000 号和 111 号确认分组,发送窗口向前滑动两个位置。
- 这样就有 444 和 555 这两个新的序号落入发送窗口。
- 发送方将序号落入发送窗口的 444 号和 555 号数据分组发送出去。
- 发送方现在可以将已经收到确认的 000 号和 111 号数据分组从发送缓存中删除了
而接收方可以择机将已接受的 000 号和 111 号数据分组交付上层处理
发送方接受 333 号数据分组,但是发送窗口不能向前滑动。
- 因为这是一个未按序到达的确认分组
- 发送方还未收到它之前的 222 号确认分组。
- 需要记录 333 号数据分组已收到确认。这样该数据分组就不会超时重发
444 号和 555 号分组到达接收方。接收方并接受他们,并发送444 号和 555 号确认分组
但是接受窗口不能向前滑动。
- 因为这是一个未按序到达的数据分组,接收方还未收到它们之前的 222 号数据分组。
假设在 444 号和 555 号确认分组的传输过程中,发送方针对 222 号数据分组的重传计时器超时
了。
发送方重传 222 号数据分组。
444 号和 555 号确认分组陆续到达发送方。
发送方接受他们,但是发送窗口不能向前滑动
- 因为它们是未按序到达的确认分组,发送方还未收到它们之前的 222 号确认分组。
- 需要记录 444 号和 555 号数据分组已收到确认,这样它们就不会超时重发。
发送方之前重传的 222 号数据分组到达接受方
- 接收方接受该数据分组,并发送 222 号确认分组。
- 接收窗口现在可以向前滑动 444 个位置,这样就有 6,7,0,16,7,0,16,7,0,1 这四个新的序号落入接收窗口。
222 号确认分组经过互联网的传输到达发送方。
发送方接受该确认分组,
- 发送窗口现在可以向前滑动 444 个位置,这样就有 6,7,0,16,7,0,16,7,0,1 这四个新的序号落入发送窗口。
- 发送方现在就可以继续将这四个序号的数据分组依次发送出去了。
3.4.4.2、尺寸问题
若发送窗口和接收窗口的尺寸超过了他们的取值范围
发送方将序号落在发送窗口内的 0−40-40−4 这 555 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。
- 接收方接受他们,并发送 0−40-40−4 号确认分组
- 接受窗口向前滑动 555 个位置,这样就有 5,6,7,0,15,6,7,0,15,6,7,0,1 这五个新的序号落入发送窗口。
这些确认分组经过互联网的传输到达了发送方。
- 但其中的 000 号确认分组丢失了
- 发送方接受 1−41-41−4 号确认分组,并记录 1−41-41−4 号数据分组已收到确认。
- 发送窗口不能向前移动
一段时间后,000 号数据分组的重传计时器超时了。
- 发送方重传 000 号数据分组
该数据分组经过互联网的传输到达了接收方。
-
其序号 000 落在接受窗口内,接收方会接受它
-
但是,接收方先前已经正确接收过该数据分组了。
如果现在还要接受,那就会出现
分组重复
这种传输差错。 -
接收方无法分辨新、旧数据分组
3.4.4.3、小结
3.4.4.4、习题
解析: