【计算机网络篇】数据链路层(4.2)可靠传输的实现机制

文章目录

🍔可靠传输的实现机制

⭐停止 - 等待协议

如下图所示,收发双方基于因特网进行通信,而不是局限在一条点对点的数据链路。纵坐标是时间

发送方给接收方发送一个数据分组,接收方对其进行差错检测,并向发送方发送确认分组

发送方收到接收方的确认分组后,才能发送下一个数据分组


发送方给接收方发送一个数据分组,但是数据分组丢失了

如下图所示,我们来展示一下解决上述情况的方法

但是,上面的这种停止 - 等待协议,仍然不能完全实现可靠传输,比如下面的情况

🗒️注意

🔎停止 - 等待协议的信道利用率

发送方发送完一个数据分组后就停止发送,并等待接收方对该数据分组的确认,当收到确认分组后,可以发送下一个数据分组,如此反复进行

TD:发送方发送数据分组所耗费的发送时延

RTT:信号在收发双方之间往返传播所耗费的时间

TA:接收方发送确认分组所耗费的数据时延

TD+RTT+TA:是使用停止等待协议的发送方,从发送一个数据分组开始,到可以发送下一个数据分组为止所经历的时间


由于仅仅是在时间TD内才用来传送有用的数据,也就是数据分组,因此,信道利用率U可以使用下面的公式进行计算

上述推导没有考虑超时重传的情况

若出现超时重传,对于传送有用的数据信息来说,信道利用率还要降低。

在往返时间RTT相对较大的情况下,为了提高信道利用率,收发双方不适合采用停止-等待协议,而可以选择使用回退N帧(GBN)协议或选择重传(SR)协议。

🗃️练习题

⭐回退N帧协议

TD:数据分组的发送时延

RTT:信号在收发双方之间的往返传播时延

由于确认分组一般很短,所以发送时延一般可以忽略(所以没有在图中画出)


如果发送方在未收到接收方发来确认分组的时候,可以连续发送多个数据分组,而不必每发送完一个数据分组,就停下来等待接收方的确认分组,则这种来实现传输方式可以显著提高信道利用率

注意:在使用流水线传输方式时,发送方不能无限制地连续发送数据分组,否则可能会导致网络中的路由器或接收方来不及处理这些数据分组,进而导致数据分组的丢失,这实际上是对网络资源的浪费。
回退N帧协议采用流水线传输方式,并且利用发送窗口来限制发送方连续发送数据分组的数量,这属于连续ARQ协议。


发送方

接收方


🎈回退N帧协议的基本工作流程

🔎无传输差错的情况

发送方将序号落入发送窗口内的0~4号数据分组,依次连续发送出去,他们经过因特网的传输,正确到达了接收方(也就是没有出现乱序和误码)

接收方按序接受它们,每接收一个,接收窗口就向前滑动一个位置,并给发送方发送针对数据分组的确认分组

0~4号确认分组经过因特网的传输,正确到达了发送方,发送方每按序接收一个确认分组,发送窗口就向前滑动一个位置,这样就有新的序号落入了发送窗口

发送方可以将收到确认的数据分组从发送缓存中删除了,而接收方应当从接收缓存中尽快取走已正确接收到的数据分组

从上面的例子可以看出,在无传输差错的情况下,回退N帧协议的信道利用率比停止-等待协议的信道利用率有显著提高。提高的程度取决于发送窗口的大小。

🔎超时重传的情况

发送方将序号落入发送窗口内的0~4号数据分组,依次连续发送出去,它们经过因特网的传输,按序到达了接收方,然而,二号数据分组在传输过程中产生了误码

接收方按序接收0号和1号数据分组,接收窗口向前滑动2个位置,并给发送方发送0号确认分组和1号确认分组

接收方通过2号数据分组中的检错码,检测出了2号数据分组中有误码,因此将其丢弃,接收窗口不能向前滑动,由于3和4号数据分组的序号未落入接收窗口

因此,接收方将它们丢弃,接收窗口不能向前滑动。

另外,接收方每收到一个未按序到达的数据分组(也就是序号未落入接收窗口的数据分组),除将其丢弃外,还给发送方发送针对最近已按序接收的数据分组的确认分组


对于本例,最近已按序接收的是1号数据分组,而接收方丢弃了无法按序接收的3号和4号数据分组。因此,接收方会发送2个针对1号数据分组的重复确认

发送方收到0号和1号确认分组,就将发送窗口向前滑动2个位置,这样就有新的序号5和6落入发送窗口

发送方现在可以将5号和6号的数据分组依次发送出去

发送方收到针对1号数据分组的2个重复确认,发送方就知道了 接收方并未按序正确接收2号数据分组,而有2个序号未落入接收窗口的数据分组也不能接收 因此被丢弃

接收方收到5号和6号数据分组,由于它们的序号未落入接收窗口

因此接收方将它们丢弃,接收窗口不能向前滑动

并且还会给发送方发送2个针对1号数据分组的重复确认。发送方又收到了针对1号数据分组的2个重复确认

至此,发送方已经收到了针对1号数据分组的4个重复确认,发送方就知道了接收方并未按序正确接收2号数据分组。到目前为止,已有4个序号未落入接收窗口的数据分组被接收方丢弃了。发送方此时可以立即重传2号数据分组,也就是在2号数据分组的重传计时器超时前,就提早进行重传。

需要说明的是,发送方收到几个重复确认后就立即开始重传,可由具体实现决定


为了简单起见,对于本例,我们假设发送方收到4个重复确认时仍然不会立刻重传,当2号数据分组发生超时,发送方就将序号落入发送窗口内的超时的 2号数据分组,和其后已发送的3~6号数据分组全部重传

尽管发送方之前已发送的3 ~ 6号数据分组到达接收方的时候并未出现误码,但是接收方只能接收序号落入接收窗口内的数据分组。因此,一旦2号数据分组出现误码被接收方丢弃,其后连续发送的3 ~ 6号数据分组都要被重传,这就是回退N帧协议名称的由来

即:一旦出错,就需要退回去重传已发送过的N个数据分组

从本例可以看出:一个数据分组的差错就可能引起大量数据分组的重传。

在信道质量较差(容易出现误码)的情况下,回退N帧协议的信道利用率并不比停止-等待协议的信道利用率高。


🗃️练习

🌹小结

⭐选择重传协议

回退N帧协议在无数据分组差错的情况下,其信道利用率比停止---等待协议要高出不少,但是,一个数据分组的差错,就可能引起大量数据分组的重传,而这些重传的数据分组,原本已经正确到达接收方,但由于序号未落入接收窗口内而被接收方丢弃。显然,这些数据分组的重传是对通信资源的严重浪费

为了进一步提高信道利用率,可以设法只重传出现差错的数据分组,这就需要接收窗口WR的尺寸>1,以便先收下失序,但是正确到达接收方且序号落入接收窗口WR内的数据分组,等到所缺数据分组收集齐后,再一并送交上层,这就是选择重传协议

为了使发送方仅重传出现差错的数据分组,接收方不再采用累积确认,而需要对每一个正确接收的数据分组进行逐一确认。

🎈选择重传协议的基本工作流程

本例假设采用3个比特给分组编序号,则序号范围是0 ~ (2^3−1)

发送方将序号落入发送窗口内的0~3号数据分组连续发送给接收方,其中,0号数据分组在传输过程中出现误码

接收方将其丢弃,接收方将失序但是正确到达接收方且序号落入接收窗口内的1 ~ 3号数据分组进行缓存,并给发送方发送相应的1 ~ 3号确认分组,缓存的1 ~ 3号数据分组暂时不能交付给上层,由于还未收到序号落入接收窗口内的0号数据分组,因此,接收窗口不能向前滑动

发送方收到失序的1 ~ 3号确认分组后,并不能向前滑动发送窗口,但要记录1 ~ 3号数据分组已被确认(这里的失序是指:没有收到0号数据分组,就收到了1 ~ 3号确认分组,因此,只有0号数据分组被超时重传)

0号数据分组正确到达接收方,接收方正确接收序号落入接收窗口内的0号数据分组,并给发送方发送0号确认分组,接收方现在可以将接收窗口向前滑动4个位置,这样,序号4 ~ 7落入接收窗口内,0号确认分组正确到达发送方

发送方收到0号确认分组后,将发送窗口向前滑动4个位置,这样,序号4 ~ 7就落入发送窗口内,这样,发送方就可以将序号落入发送窗口内的4 ~ 7号数据分组连续发送出去,而接收方也在等待接收序号落入接收窗口内的4 ~ 7号数据分组

发送方可将发送缓存中 序号已被移除发送窗口 的数据分组删除了,而接收方应尽快将接收缓存中序号已被移出接收窗口的数据分组取走

🗃️练习
相关推荐
正在走向自律26 分钟前
阿里云ESC服务器一次性全部迁移到另一个ESC
服务器·阿里云·云计算
gywl1 小时前
openEuler VM虚拟机操作(期末考试)
linux·服务器·网络·windows·http·centos
WTT00111 小时前
2024楚慧杯WP
大数据·运维·网络·安全·web安全·ctf
了一li2 小时前
Qt中的QProcess与Boost.Interprocess:实现多进程编程
服务器·数据库·qt
杨德杰2 小时前
QT网络(一):主机信息查询
网络·qt
日记跟新中2 小时前
Ubuntu20.04 修改root密码
linux·运维·服务器
唐小旭2 小时前
服务器建立-错误:pyenv环境建立后python版本不对
运维·服务器·python
明 庭2 小时前
Ubuntu下通过Docker部署NGINX服务器
服务器·ubuntu·docker
BUG 4042 小时前
Linux——Shell
linux·运维·服务器