计算机网络——数据链路层(流量传输与可靠传输机制)

我们今天来了解流量传输与可靠传输机制。

流量传输与可靠传输机制

流量控制和可靠传输机制是计算机网络中确保数据有效且高效传输的重要组成部分,特别是在数据链路层和传输层中得到了广泛的应用。

流量控制

流量控制主要关注的是在网络通信中防止发送方过快地向接收方发送数据而导致接收方无法及时处理的问题。其目的是根据接收方的实际接收能力和缓冲区大小调整发送方的发送速率,确保接收方能够完整接收并处理每个数据帧,而不至于因为接收过快而导致数据丢失或拥塞。流量控制的具体实现方法包括使用滑动窗口协议、基于速率的控制(如TCP的慢启动、拥塞避免算法)、确认和控制信号等方式。

可靠传输机制

可靠传输则是保证在网络中传输的数据能准确无误地到达接收方,即使网络存在各种不可靠因素(如丢包、乱序、重复等)。这一机制通常通过以下手段来实现:

  • 确认机制:接收方向发送方发送确认信息(ACK),表示已正确接收特定的数据帧或数据段。
  • 自动重传请求(ARQ):当发送方未收到针对某帧的确认时,会重新发送该帧,确保数据最终送达。
  • 停止-等待协议:每次只发送一个帧,等待接收方的确认,然后再发送下一个帧。
  • 后退N帧协议(GBN):允许发送方维持一个发送窗口,可以连续发送多个帧,但如果发生冲突或错误,接收方要求发送方从出错的某一帧开始重传之后的所有帧。
  • 选择重传协议(SR):接收方可以接收并存储失序到达但无误的帧,仅要求发送方重传缺失的帧。

通过上述机制结合序列号、校验和、超时重传等技术,可以在数据链路层和传输层提供不同程度的可靠传输服务。在TCP/IP模型中,传输层的TCP协议就是一个典型的实施了可靠传输机制的例子,而在数据链路层,像HDLC、PPP等协议也支持ARQ机制来提供链路层的可靠性保障

停止-等待协议

停止-等待协议(Stop-and-Wait Protocol)是一种非常基础且简单的数据链路层协议,主要用于确保网络中数据传输的可靠性。它的核心原理如下:

  1. 逐帧发送:发送方每次只发送一个数据帧(分组),然后停止发送新的数据帧,进入等待状态。
  2. 确认机制:发送方等待接收方对刚刚发出的数据帧的确认(ACK)。确认帧包含对所确认数据帧的序号信息。
  3. 超时重传:如果发送方在预定的时间间隔内(即超时时间内)没有收到确认帧,它会认为刚才发送的数据帧可能已经丢失或出现错误,于是重新发送那个数据帧。
  4. 顺序传输:由于发送窗口大小为1,这意味着只有当前发送的数据帧被确认之后,下一分组才能发送,从而保证了数据帧的有序传输。
  5. 效率较低:由于每次只能发送一个数据帧并在等待确认后才能发送下一个,这种协议的带宽利用率相对较低,特别是在高延迟网络环境下。

优点:

  • 简单易实现;
  • 能够确保数据的可靠传输,每一个数据帧都能被确认或重传。

缺点:

  • 低吞吐量,因为需要等待确认,所以信道利用效率不高;
  • 易受网络延迟影响,若网络延迟较大,可能会导致不必要的重传和传输效率下降;
  • 对于丢包率较高的网络环境表现不佳,因为频繁的超时会导致大量的重传。

停止-等待协议是计算机网络教学中用于解释可靠传输原理的一个理想化模型,实际网络中更多采用滑动窗口协议来提高传输效率,如后退N帧ARQ(Go-Back-N)和选择重传ARQ(Selective Repeat ARQ)等更复杂的协议。

无差错情况

在停止-等待协议中,接收端处理数据帧的过程虽然不涉及明确的状态名称,但我们可以描述接收端在无差错情况下的行为步骤:

  1. 等待接收状态
  • 接收端随时准备接收来自发送端的数据帧。
  1. 接收状态
  • 当接收到一个数据帧时,接收端会立即进行差错检测(如CRC校验)。
  • 若数据帧经过校验没有发现任何错误,则接收端认为该帧是正确的。
  1. 发送确认状态
  • 对于正确接收的数据帧,接收端立即将确认信息(ACK)打包成确认帧,并将其发送回发送端。
  • 确认帧中通常会包含对应收到的数据帧的序号,以便发送端知道哪个帧已被正确接收。
  1. 等待下一帧状态
  • 发送确认帧后,接收端又回到等待接收状态,准备接收下一个按序排列的数据帧。
    在这里插入图片描述在这里插入图片描述在这里插入图片描述

在整个过程中,接收端不会积累多个未确认的数据帧,因为停止-等待协议不允许发送端在未收到前一个数据帧的确认之前发送新的数据帧。因此,在无差错情况下,接收端的流程相对简单且直接。

接收并检测到差错状态

在停止-等待协议中,除了正常无差错情况下的接收端状态外,还有两种典型异常情况下的状态:

当接收端接收到一个数据帧,但在进行差错检测时发现了错误(例如奇偶校验、CRC校验失败等)。
此时接收端会丢弃这个错误的数据帧,并不向发送端发送确认。
因为停止-等待协议假设的是无反馈即代表出错,所以即使接收端不专门发送否定确认(NAK),发送端也会因为超时未收到确认而重传该帧。
在这里插入图片描述

确认丢失或迟到状态

在发送端正确发送数据帧且接收端也成功接收并发送了确认帧的情况下,可能出现确认帧在网络中丢失或延迟到达发送端。
发送端由于未收到预期的确认,在设定的超时时间内将误以为数据帧出现问题,从而触发重传状态,重新发送相同的数据帧。
当迟到的确认帧后来到达时,发送端通常会忽略这个迟到的确认,因为它已经因为超时而进行了重传。
在这里插入图片描述在这里插入图片描述

总而言之,谁迟到了,就不管谁。成功过的,再发也不管。

停等协议的效率分析

停等协议(Stop-and-Wait Protocol)的效率可以从以下几个方面进行分析:

  1. 传输效率(Throughput)
  • 停等协议的传输效率指的是在单位时间内成功传输的有效数据量与总的传输能力之比。由于每次发送一个数据帧后必须等待接收方的确认才能发送下一个帧,加上可能存在的确认帧传输时间和可能的重传等待时间,实际有效的数据传输时间占比很低,尤其是在高延迟或高丢包率的网络环境下,其效率更低。
  • 传输效率可以用数学公式表达:η = (1/(2τ_p + τ_t)) × 数据传输速率,其中τ_p是传播时延,τ_t是确认帧往返时延(RTT),数据传输速率是指单位时间内能传输的最大数据量。
  1. 信道利用率
  • 信道利用率是指发送方在单位时间内有效发送数据的时间占整个发送周期的比例。在停等协议中,由于每发送一个帧都需要等待确认,因此信道利用率较低,尤其是当传播时延远大于帧传输时间时,效率受到显著影响。
  1. 延迟
  • 停等协议中的延迟主要包括传播时延、发送时延、确认时延以及重传时延。由于每次传输都需要等待确认,因此总体延迟较高。
  1. 吞吐量
  • 吞吐量是指在一定时间内成功通过信道传输的数据总量。在停等协议中,由于其严格的“一次一帧”策略,吞吐量受限于RTT时间,且容易受到丢包和重传的影响,导致吞吐量不稳定且平均值较低。
  1. 可靠性
  • 尽管停等协议的效率不高,但它确保了数据传输的可靠性,每一个数据帧都有确认过程,而且能够在检测到丢失或错误时立即重传。
  1. 适应性
  • 停等协议不适用于高速网络环境,因其低效率和高延迟特性,更适合于低速、稳定且对延迟敏感但数据量较小的网络环境。
    在这里插入图片描述在这里插入图片描述

总的来说,停等协议的主要优势在于其实现简单,能够提供可靠的数据传输,但其缺点是效率低下和延迟较高,不适合高吞吐量和大数据量的通信需求。在实践中,为了提高效率和吞吐量,往往采用更为复杂的滑动窗口协议,如后退N帧ARQ(Go-Back-N)和选择重传ARQ(Selective Repeat ARQ)等。

后退N帧协议(Go-Back-N,简称GBN)

后退N帧协议(Go-Back-N,简称GBN)是一种在数据链路层使用的基于滑动窗口的流量控制和差错控制机制。相对于停止-等待协议,GBN提高了传输效率,允许发送方一次性发送多个数据帧而不必等待每个帧的确认后再发送下一个帧。以下是后退N帧协议的主要特点和工作原理:

  1. 窗口机制
  • 发送方维护一个发送窗口,允许同时有多个未确认的帧在传输途中。窗口的大小由协议参数确定,窗口内的帧可以连续发送出去。
  • 接收方的接收窗口一般固定为1,意味着接收方仅允许按序接收并确认下一个期待的帧。
  1. 帧编号
  • 使用循环或非循环的帧序号系统来标识每个帧,序号长度决定了窗口最大可容纳的未确认帧数量。
  1. 重传策略
  • 当接收方检测到错误或接收到失序的帧时,只会简单地丢弃该帧及后续的帧,而不做任何缓存。
  • 如果发送方在一个帧发送出去后在规定时间内没有收到相应的确认,或者收到了一个携带了重复序号的确认,它会假设从最后一个未确认帧开始直到当前窗口末尾的所有帧都已经丢失或出现错误,并重新发送这些帧。
  1. 效率提升
  • 相较于停等协议,后退N帧协议减少了因等待确认造成的空闲时间,从而提高了信道利用率和网络吞吐量。
  1. 潜在问题
  • 如果窗口过大,可能会造成网络拥塞,增加重传的可能性。
  • 若连续多个帧发生丢失,发送方需重传大量帧,这会带来较大的开销。
  1. 序号范围限制
  • 为了避免序号空间溢出问题,发送窗口的大小应小于2^n - 1,其中n为帧序号位数,确保在重传期间不会与新生成的帧序号冲突。
    在这里插入图片描述
    在这里插入图片描述

形象解释

假设你和你的朋友正在进行一场特殊的传球游戏,你们之间有一条很长的隧道,只能通过投掷篮球的方式来传递信息。你的目标是将一系列编号的篮球准确无误地传递给对方。

  1. 发送窗口
  • 你手中有一个篮子,里面最多可以放5个篮球(这相当于发送窗口的大小为5),每个篮球都写上了唯一的数字标签(即帧编号)。
  1. 连续投递
  • 你不需要等到前一个篮球被接收到并返回确认信息就可以继续投掷下一个篮球。也就是说,你依次将篮球1、2、3、4、5快速连续地投出去。
  1. 接收顺序
  • 你的朋友只能按照篮球的编号顺序接球,如果篮球2被石头砸中偏离了轨道(即数据帧在传输过程中出现了错误或丢失),他就无法接住篮球2,但篮球3、4、5还是顺利通过了隧道到达他那里。
  1. 反馈与差错处理
  • 朋友接球后,立即向你反馈他接收到的最新篮球编号。由于篮球2未被接收到,他只能告诉你:“我接到了篮球1”。
  1. 后退N帧重传
  • 听到这个反馈后,你了解到篮球2可能丢失或损坏了,这时你采取行动,把篮球篮子里从篮球2开始往后的所有篮球(即篮球2、3、4)都取回来(在数据链路层表现为缓存中这些未确认帧的重传队列)。
  • 之后,你重新开始投掷篮球,首先投掷的就是篮球2,然后是篮球3、4,最后是篮球5(如果篮球5还未被确认的话)。
    在这里插入图片描述

在这个游戏中,即便篮球2到篮球4都出现了问题,你也无需逐一排查哪些篮球有问题,而是直接“后退N帧”,将篮球2之后的所有篮球全部重新投一次。这样一来,既提高了传递速度,又能确保信息最终能够完整无误地传达给对方。

GBN协议重点

后退N帧协议(GBN,Go-Back-N)的重点要点概括如下:

  1. 滑动窗口机制
  • GBN协议采用了滑动窗口技术来提高网络传输效率,发送方可以根据窗口大小一次性发送多个未确认的数据帧,窗口大小限制了未确认帧的数量。
  1. 帧编号
  • 数据帧带有序列号,接收方按照序列号的顺序接收帧,只有按序到达的数据帧才会被确认。
  1. 接收窗口
  • 接收方维持一个窗口,窗口大小通常为1,仅允许按序接收下一个预期的帧,对乱序或重复的帧不予确认或暂存。
  1. 发送窗口
  • 发送方的窗口大小可以大于1,允许发送多个连续编号的帧而不等待确认。一旦接收到某个旧序号的确认,窗口会向前滑动,允许发送更多的帧。
  1. 重传策略
  • 如果发送方在一定时间内(通常是超时时间后)没有收到某个帧的确认,或者收到了一个低于当前发送窗口边缘的确认(表明中间有帧丢失或未确认),发送方会回退到未确认的最老帧,然后重传从该帧开始直到窗口边缘的所有帧。
  1. 确认策略
  • GBN协议采用累积确认的方式,接收方只需确认连续接收序列中的最高序号帧,表示该序号之前的帧都已经正确接收。
  1. 性能
  • GBN协议相较于停等协议提升了网络利用率和吞吐量,但在高丢包率或长时延网络条件下,重传代价较大,可能导致效率降低。
  1. 局限性
  • 当网络条件较差导致连续多个帧丢失时,GBN协议可能引发冗余重传,且无法很好地适应高带宽、高丢包率的网络环境。
    在这里插入图片描述在这里插入图片描述

总结来说,后退N帧协议通过滑动窗口技术和确认重传机制在保证数据传输可靠性的同时提高了网络效率,但也要注意其在窗口大小选取上的平衡,以避免资源浪费和降低网络性能。

选择重传协议(Selective Repeat,简称SR)

选择重传协议(Selective Repeat,简称SR)是一种比后退N帧协议(GBN)更为精细的错误恢复和流控机制,在数据链路层用于提供可靠的数据传输服务。以下是选择重传协议的重点特点:

  1. 滑动窗口
  • 发送方同样使用滑动窗口来管理待发送、已发送但未确认以及可以发送的数据帧,但与GBN不同,SR允许接收方接收并暂存部分乱序到达的帧
  1. 帧编号
  • 每个发送的数据帧都有一个唯一的序号,接收方可以根据序号来识别和处理帧。
  1. 接收窗口
  • 接收方保持一个动态的接收窗口,窗口内的序号范围内的帧会被接收并暂存,即使它们到达的顺序不完全按序。
  1. 确认策略
  • 接收方对接收到的每个正确的、按序到达的帧分别发送确认。即使是乱序到达的帧,只要其序号在接收窗口范围内,也会被接收并单独确认。
  1. 重传策略
  • 发送方仅重传那些未收到确认的帧,而不是像GBN那样重传从某个点开始的所有后续帧。这意味着SR能够精确地定位并重传丢失或出错的个别帧,从而减少不必要的重传。
  1. 性能优化
  • 由于SR协议只重传丢失的帧,所以在网络条件较好时,其性能优于GBN,降低了不必要的带宽消耗和延迟。
    在这里插入图片描述

形象解释

设想你和一位朋友在玩一个快递游戏,你们之间的任务是传递一系列带有编号的包裹(这些包裹就代表着数据帧)。与传统的逐个传递并等待确认不同,你们决定采取一种更灵活的方式提高效率。

  1. 包裹编号
  • 每个包裹上都有一个独特的序列号,从1开始依次递增。
  1. 发送方的储物架
  • 你有一个储物架(相当于发送方的滑动窗口),可以同时放置几个包裹准备发出。例如,如果你的窗口大小是5,你就可以同时发出包裹1到5。
  1. 发送与接收
  • 你按照序列号顺序送出包裹,但并不等待每个包裹被确认后再发送下一个。这样,即使某些包裹还在路上,你也可以继续发出更多的包裹。
  1. 接收方的储物柜
  • 你的朋友有个储物柜(接收方的接收窗口),它可以接受并储存一定数量的包裹,即使这些包裹不是严格按序到达的。比如,如果接收窗口足够大,即使先收到了包裹5,也可以暂时保管起来,等待包裹3和4的到来。
  1. 确认机制
  • 一旦你的朋友按序收到一个包裹,比如他收到了包裹2,他就会立即给你发送一个确认消息,告知你包裹2已经安全到达。而对于暂时无法按序接收的包裹(比如先收到的包裹5),他也会记住这个包裹的存在,但不会确认,直到所有前面的包裹都到位。
  1. 重传策略
  • 你持续关注朋友的确认消息,如果某个包裹(比如包裹3)在一段时间内没有收到确认,你就知道那个包裹可能丢失了。这时候,你只需要单独重新发送这个编号为3的包裹,而不是像后退N帧那样重传从编号3开始的所有后续包裹。
  1. 性能与挑战
  • 选择重传协议相比后退N帧协议更有效地利用了带宽,因为它减少了不必要的重传。然而,这也带来了更高的实现复杂度,因为你和你的朋友都需要额外的空间来储存和管理那些已经发送但尚未确认或需要重传的包裹,并且需要跟踪每个包裹的确切状态。

总的来说,选择重传协议就是一种精心设计的传输策略,它允许并行发送多个数据帧,只对出错或丢失的帧进行精准重传,从而提高了数据传输效率,同时保持了传输的可靠性。

然而,SR协议的实现更为复杂,因为它需要在接收端维护每个帧的状态,并且在发送端需要更复杂的逻辑来跟踪哪些帧需要重传。此外,SR协议的窗口大小需要仔细设置,以避免因确认丢失而引起的不确定性和可能的死锁问题。

GBN和SR中,滑动窗口的移动时机

在后退N帧协议(GBN)和选择重传协议(SR)中,滑动窗口的移动时机有所不同:

后退N帧协议(GBN)

  • 在GBN协议中,发送方的滑动窗口开始移动是在接收到接收方对窗口内最早未确认帧的累积确认时。也就是说,当接收方确认了窗口内最小序号的帧,发送方就可以将窗口向前滑动,窗口的新边界将指向未确认帧中的下一个帧序号。

选择重传协议(SR)

  • 在选择重传协议(SR)中,发送方的滑动窗口可以更灵活地移动。每接收到一个确认帧,发送方就可以移动窗口以反映被确认的帧。即使窗口内还有其他未确认的帧,只要收到某个帧的单独确认,窗口就可以针对那个被确认帧的位置进行微调,向前移动相应的步长,使得窗口内的未确认帧序列向前推进。

总结来说,两者的主要区别在于:

  • GBN协议的窗口移动是基于累积确认,只有当收到的确认序号覆盖了窗口内最早的未确认帧时,窗口整体向前移动。
  • SR协议的窗口移动更为精细,可以针对每个被单独确认的帧来移动窗口边界,不必等待所有未确认帧都被确认。

在这里插入图片描述在这里插入图片描述

最近更新

  1. TCP协议是安全的吗?

    2024-04-02 11:50:03       18 阅读
  2. 阿里云服务器执行yum,一直下载docker-ce-stable失败

    2024-04-02 11:50:03       19 阅读
  3. 【Python教程】压缩PDF文件大小

    2024-04-02 11:50:03       18 阅读
  4. 通过文章id递归查询所有评论(xml)

    2024-04-02 11:50:03       20 阅读

热门阅读

  1. Hadoop系列总结

    2024-04-02 11:50:03       18 阅读
  2. openGL创建平面、立方体、圆柱体、斜面和棱柱Demo

    2024-04-02 11:50:03       16 阅读
  3. redis-Hash

    2024-04-02 11:50:03       16 阅读
  4. 【Vmware】 debian 12 安装教程

    2024-04-02 11:50:03       22 阅读
  5. C 练习实例96 - 字符串中的子串

    2024-04-02 11:50:03       16 阅读
  6. 计算机断层扫描采集软件

    2024-04-02 11:50:03       15 阅读
  7. vector容器(二)

    2024-04-02 11:50:03       16 阅读
  8. QT(6.5) cmake构建C++编程,多线程

    2024-04-02 11:50:03       17 阅读
  9. C++ hex转uint,uint 互相转换,uint转byte

    2024-04-02 11:50:03       18 阅读