
使用
差
错
检
测
技
术
\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}可靠传输服务并不仅局限于数据链路层 可靠传输服务并不仅局限于数据链路层,其他各层均可选择实现可靠传输。
例如:

可靠传输的实现比较复杂,开销也比较大,是否使用可靠传输取决于应用需求。
主机 H6 给主机 H2 发送的分组到达了路由器 R5。
由于此时 R5 的输入队列快满了。
R5 根据自己的分组丢弃策略将该分组丢弃

主机 H6 给主机 H2 发送了
3
3
3 个分组。
它们并未按照发送顺序依次到达 H2。(最先发送的分组未必最先到达)

主机 H6 给主机 H2 发送的分组。由于某些原因在网路中滞留了,没有及时到达 H2
这可能造成了 H6 给 H2 的超时重发,重发的分组到达了 H2。一段时间后,滞留在网络中的那个分组又到达了 H2
这又会造成分组重复的传输差错

注意:
每发送一个数据分组就进行停止等待
若收发双方基于互联网进行通信,而不是局限在一条点对点的数据链路。
发送方给接收方发送数据分组,接收方收到后对其进行差错检测。
若没有误码,则接受该分组,并给发送方发送确认分组,简称为 ACK
发送方收到对所发送方数据分组的确认分组后,才能发送下一个数据分组。
假设这个数据分组在传输过程中出现了误码.
接收方收到后对其进行差错检测。发现了误码,则丢弃该数据分组
并给发送发发送否认分组(NAK)
发送方收到所发送数据分组的否认分组后,就知道了之前自己所发送的数据分组出现了差错而被接收方拒绝
于是立刻重传该数据分组
因此,发送方每发送一个数据分组后,并不能立刻将该数据分组从缓存中删除,只有在收到针对该数据分组的确认分组后,才能将其从缓存中删除

发送方发送的数据分组丢失

接收方发送的确认或否认分组就也有可能丢失

接收方丢弃重复的数据分组,并给发送方发送针对该数据分组的确认分组。
以免发送方对该数据分组的再次超时重传

由于某些原因,该确认分组迟到了,这必然会导致发送方对
0
0
0 号数据分组的超时重传
在重传的 0 0 0 号分组的传输过程中,发送方收到了迟到的确认分组,于是发送 1 1 1 号分组

发送方如何知道这是一个对
0
0
0号分组的重复确认。
若不采取其他措施,发送会误认为这是对 1 1 1 号数据分组的确认。
若对确认分组也进行编号,就可以使发送方避免这种误判

因此,若只在数据链路层实现停止-等待协议,可以不用给确认分组编号
接收端检测到数据分组有误码时,将其丢弃并等待发送方的超时重传。
为了让接收方能够判断所收到的数据分组是否是重复的,需要给 数 据 分 组 编 号 \color{red}数据分组编号 数据分组编号。
为了让发送方能够判断所收到的 ACK 分组是否是重复的,需要给
A
C
K
分
组
编
号
\color{red}ACK 分组编号
ACK分组编号,所用比特数量
与
数
据
分
组
编
号
所
用
比
特
数
量
一
样
\color{red}与数据分组编号所用比特数量一样
与数据分组编号所用比特数量一样。
ACK 分组迟到的情况,因此在
数
据
链
路
层
实
现
停
止
−
等
待
协
议
可
以
不
用
给
A
C
K
分
组
编
号
\color{red}数据链路层实现停止-等待协议可以不用给ACK分组编号
数据链路层实现停止−等待协议可以不用给ACK分组编号。超时计时器设置的 重 传 时 间 \color{red}重传时间 重传时间应仔细选择。
一般可将重传时间选为 略 大 于 “ 从 发 送 方 到 接 收 方 的 平 均 往 返 时 间 ” 。 \color{red}略大于“从发送方到接收方的平均往返时间”。 略大于“从发送方到接收方的平均往返时间”。
在数据链路层点对点的往返时间比较确定,重传时间比较好设定。
然而在运输层,由于端到端往返时间非常不确定,设置合适的重传时间有时并不容易。

T
D
T_D
TD :发送方发送数据分组所耗费的发送时延 TD(仅仅在
T
D
T_D
TD 内才用来传送有用的数据,也就是数据分组)
R T T RTT RTT:收发双方之间的往返时间 R T T RTT RTT
T A T_A TA:接受方发送确认分组所耗费的发送时延 T A T_A TA
此处忽略了就收方对数据分组的处理时延,以及发送方对确认分组的处理时延

当 往 返 时 延 R T T 远 大 于 数 据 帧 发 送 时 延 T D 时 ( 例 如 使 用 卫 星 链 路 ) , 信 道 利 用 率 非 常 低 。 \color{red}当往返时延RTT远大于数据帧发送时延T_D时(例如使用卫星链路),信道利用率非常低。 当往返时延RTT远大于数据帧发送时延TD时(例如使用卫星链路),信道利用率非常低。
若出现重传,则对于传送有用的数据信息来说,信道利用率还要降低。
为了克服停止-等待协议信道利用率很低的缺点,就产生了另外两种协议
GBN 和 选择重传协议 SR。
解析:


此协议在流水线传输的基础上,利用发送窗口来限制发送方可连续发送数据分组的个数
收发双发各自的分组序号,当序号增加到 7 7 7 时,下一个序号又从 0 0 0 开始。
发送方维持一个发送窗口,序号落在发送窗口内的数据分组可被连续发送,而不必等收到接受方的相应确认分组后再发送

1 < W T ≤ 2 3 − 1 1 < W_T \le 2^3 - 1 1<WT≤23−1 :其中的 3 3 3 是构成分组序号的比特数量。
对于回退 N N N 帧协议, W R W_R WR 只能为 1 1 1
发送方将序号落在发送窗口内的 0 − 4 0 - 4 0−4 号数据分组,依次连续发送出去
他们经过互联网的传输正确到达了接收方。
接收方按序接受他们,每接收一个,接收窗口就向前滑动一个位置,并给发送方发送针对所接受分组的确认分组

发送方每接收一个,发送窗口就向前滑动一个位置
而接收方可以择机将已接受的数据分组交付上层处理

发送方将序号落在发送窗口内的 0 − 4 0 - 4 0−4 号数据分组,依次连续发送出去。
他们经过互联网的传输正确到达了接收方。
接收方按序接受他们:
ACK1 。ACK4。假设 ACK1 再传输过程中丢失了,ACK4 正确到达了发送方。
发送方接受 ACK4 后就知道了序号为
4
4
4 及之前的数据分组已被接收方正确接收了。
而接收方可以择机将已接受的数据分组交付上层处理

例如:
ACK1 丢失了,但并没有造成
1
1
1 号数据分组的超时重传。使用累计确认还有其他好处
缺点
及时反应出接收方已经正确接收的数据分组信息发送方将序号落在发送窗口内的这 5 5 5 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。
假设他们再传输过程中受到了干扰,其中 5 5 5 号数据分组出现了误码
接收方通过数据分组中的检错码发现了错误,于是丢弃该数据分组
而后序到达的这 4 4 4 个数据分组的序号与接受窗口的序号不匹配

接收方同样也不能接受他们,将他们丢弃。
接收方并对之前按序接受的最后一个数据分组进行确认,(也就是发送 ACK4 )
每丢弃一个数据分组,就发送一个 ACK4。
这
4
4
4 个 ACK4 经过互联网的传输到达了发送方

假设收到这
4
4
4 个重复的确认并不会触发发送方立刻重传。
一段时间后,超时计时器出现超时,发送方将发送窗口内已发送过的这些数据分组全部重传。


发送方将序号落在发送窗口内的这 0 − 7 0 -7 0−7 这 8 8 8 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。
接收方按序正确接受他们后,给发送方发回累积确认 ACK7
假设 ACK7 在传输过程中丢失了,这将导致发送方的超时重传。

因此,发送窗口的尺寸不能超过其上限



解析:


收发双发各自的分组序号,当序号增加到 7 7 7 时,下一个序号又从 0 0 0 开始。
发送方维持一个发送窗口,序号落在发送窗口内的数据分组可被连续发送,而不必等收到接受方的相应确认分组后再发送
说明:

1 < W T ≤ 2 3 − 1 1 < W_T \le 2^3 - 1 1<WT≤23−1 :其中的 3 3 3 是构成分组序号的比特数量。
发送方将序号落在发送窗口内的这 4 4 4 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。
但是其中的
2
2
2 号数据分组丢失了,只要序号落入接收窗口内且无误码的数据分组,接收方都会接受
接收方接受 0 0 0 号和 1 1 1 号数据分组,并发送 0 0 0 号和 1 1 1 号确认分组。
接受窗口向前滑动两个位置,这样就有 4 4 4 和 5 5 5 这两个新的序号进入接收窗口。
接收方接受 3 3 3 号数据分组,并发送 3 3 3 号确认分组,但接受窗口不能向前滑动
未按序到达的数据分组。
这些确认分组经过互联网的传输到达了发送方。
而接收方可以择机将已接受的
0
0
0 号和
1
1
1 号数据分组交付上层处理

发送方接受 3 3 3 号数据分组,但是发送窗口不能向前滑动。
4 4 4 号和 5 5 5 号分组到达接收方。接收方并接受他们,并发送 4 4 4 号和 5 5 5 号确认分组
但是接受窗口不能向前滑动。

假设在
4
4
4 号和
5
5
5 号确认分组的传输过程中,发送方针对
2
2
2 号数据分组的重传计时器超时了。
发送方重传 2 2 2 号数据分组。

4 4 4 号和 5 5 5 号确认分组陆续到达发送方。
发送方接受他们,但是发送窗口不能向前滑动
发送方之前重传的 2 2 2 号数据分组到达接受方

2 2 2 号确认分组经过互联网的传输到达发送方。
发送方接受该确认分组,


若发送窗口和接收窗口的尺寸超过了他们的取值范围

发送方将序号落在发送窗口内的 0 − 4 0-4 0−4 这 5 5 5 个数据分组依次连续发送出去
他们经过互联网的传输到达了接收方。

这些确认分组经过互联网的传输到达了发送方。

一段时间后, 0 0 0 号数据分组的重传计时器超时了。
该数据分组经过互联网的传输到达了接收方。
其序号 0 0 0 落在接受窗口内,接收方会接受它
但是,接收方先前已经正确接收过该数据分组了。
如果现在还要接受,那就会出现分组重复这种传输差错。
接收方无法分辨新、旧数据分组



解析:
