计网--数据链路层

JaFox

已于 2023-10-21 21:05:34 修改

阅读量923

点赞数

分类专栏： CourseLearning 文章标签：网络网络协议

于 2022-10-15 09:56:32 首次发布

本文链接：https://blog.csdn.net/m0_52422297/article/details/127331507

版权

CourseLearning 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

概述

概念

在这里插入图片描述

可以看成是在4段不同的链路上的通信组成的。
链路+一些通信协议来控制这些数据的传输==>传输

该层的三个重要问题(基本问题)

在这里插入图片描述

发送前形成检错码，放在帧尾，如↑的帧尾是4字节的帧检验序列FCS字段，要写入该字段的内容就是检错码。
在这里插入图片描述

接收方主机收到有误码的帧后，不接受该帧，将其丢弃。
若：①数据链路层向上提供不可靠传输服务，丢弃就丢弃了②提供可靠，则还需其他措施确保接收方主机还可以重新接收到被丢弃的这个帧的正确副本。

其他问题

除了这三个，还有其他的问题：
在这里插入图片描述
当总线上多合主机同时使用总线来传输帧时，传输信号会产生碰撞，这是采用广播信道的共享或局域网不可避免的。
以太网的解决方式

封装成帧

概念

在这里插入图片描述

接收方的该层如何提取一个个帧【识别"帧"的方法】≠透明传输里的"转义字符"

有帧定界标志【方法一】

在这里插入图片描述

↑两个“标志”字段的作用就是帧定界。
在这里插入图片描述

没有帧定界标志–前导码【方法二】

用前导码。
在这里插入图片描述
8字节前导码（“前7个字节”作用：式接收方的时钟同步；“后1字节”：表明后面紧跟着的就是MAC帧）。
另外，以太网规定了：【帧间间隔】

注意，帧间间隔还有其他作用。

透明传输问题

👇有好几种情况：

面向字节的物理链路–加“转义字符”

在这里插入图片描述
帧头帧尾简化为flag（帧定界标志）。
如果在上层交付的协议数据单元中，怡好也包含了这特定数值–>接收方不能正确接收该帧。

如果数据链路层不采取其他措施来避免接收方对帧是否结束的误判，就不能称为透明传输，也就是说，数据链路层对上层交付的协议数据单元有限制。解决方法[发送帧前，对帧的数据部分进行扫描，每出现一个帧定界符，就在其前面插入一个转义字符]↑（几乎必须解决，不然数据链路层没意义）
在这里插入图片描述
再考虑这种情况：
在上层交付的协议数据单元中，既包含了帧定界符，又包含了转义字符–>解决方法一样↓

说明：转义字符是一种特殊的控制字符，1个字节，十进制值为27，而并不是E、S以及C这3个字符。

面向比特的物理链路–比特填充

在这里插入图片描述
为简单起见：

帧的数据部分。
在发送前，可以采用零比特填无充法，每5个连续的比特1后面就插入1个比特0。这样就确保了帧定界在整个帧中的唯一性，也就可以实现透明传输。
接收方的数据链路层，从物理层交付的比特流中提取帧时，将帧的数据部分中的每5个连续的比特1后面的那个比特0剔除、即可。

题

在这里插入图片描述
提醒：

小结

在这里插入图片描述

差错检测–【不纠错】

概念

在这里插入图片描述

奇偶校验

在这里插入图片描述

👆一般不用这种方法。

循环冗余校验CRC

在这里插入图片描述
将冗余码添加到待发送数据的后面一起发送。

需要注意的是👆字幕。最低次项即常数1那一项。

题

在这里插入图片描述
蓝-红-绿。
红色：G(x)的最高次数
做除法：内部是异或运算。
商的上位：1/0表示够除/不够除【位数】。

检查 -->余数得为0
在这里插入图片描述

小结

需要注意的是：
在这里插入图片描述

可靠传输

基本概念

在这里插入图片描述

提供可靠传输服务：接收方可以给发送方发送一个通知帧。

需要说明的是：

👆将帧的称呼改成了分组：这意味着传输错不仅仅局限于数据链路层的比特差错。

分组失序。

分组重复。

小结：
在这里插入图片描述

实现机制–停止-等待协议SW

停止等待，就是指发送方发送后要停下来等待接收方发来确认分组。

放眼整个体系结构

在这里插入图片描述

DATA误码、DATA丢失

在这里插入图片描述
因此发送方每发送完一个数据分组后，并不能立刻将该数据分组从缓存中删除，只有在收到针对该数据分组的确认分组后，才能将其从缓存中删除。看来发送方每发送完一个数据分组后，就停止发送下一个数据分组，等待来自接收方的确认分组或否认分组。

点对点通道不太可能出现“丢失”，但对于多个网络通过多个路由器互联的复杂互联网环境而言经常出现。

ACK丢失

在这里插入图片描述

重复ACK–该层不会出现此情况

在这里插入图片描述
👆出现重复确认，若不采取其他措施，将“字幕”。

注意：（第四幅图的最下面的DATA0）该数据分组与之前序号为0的那个数据分组不是同一个数据分组。

需要说明的是，对于数据链路层的点对点信道往返时间比较固定，不会出现确认迟到的情况（即👆最后一幅图），因此如果只在数据链路层实现停止等待协议，可以不用给确认分组编号。

小结–停止等待协议的一些注意事项

在这里插入图片描述

信道利用率

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

在这里插入图片描述
举例说明👇

题

在这里插入图片描述
注意单位，比如这里的ms。

小结

在这里插入图片描述
顺便提一下，像停止等待协议这种通过确认和重传机制实现的可靠传输协议，常称为自动请求重传协议，ARQ意思是重传的请求是自动进行的，因为不需要接收方显示的请求，发送方重传某个出错的分组。【意思应该就是，“重传”不是接收方显示地请求说“我需要你重传”】

实现机制–回退N帧协议GBN

在这里插入图片描述
由上节课的知识引入👇

该协议在流水线传输的基础上，利用发送窗口来限制发送方和连续发送分组的个数。

举例说明

在这里插入图片描述
发送方要维持一个发送窗口，序号落在发送窗口内的数据分组可被连续发送，而不必等收到接收方的相应确认分组后再发送。
其中的3是构成分组序号的比特数量。
如果W_t取1，则是停止等待协议；如果wt的值超过取值范围的上限，则会造成严重的错误(之后举例）。
W_R取值只能为1，对于回退n帧协议[这一点与停止等待协议是相同的]。

无差错情况

在这里插入图片描述
接收方：按序接收，每接收一个，接收窗口就向前滑动一个位置，并给发送方发送针对所接收分组的确认分组。
发送方：（确认分组正确到达）每接收一个，发送窗口就向前滑动一个位置，这样就有新的序号落入了发送窗口。
发送方可以将收到确认的数据分组从缓存中删除了，而接收方可以择机将已接收的数据分组交付上层处理。
在这里插入图片描述

累积确认

在这里插入图片描述
就算ack1丢了，发送方也知道4及4之前的都接受了。

TODO：可以补充其他的优缺点。

有差错情况

在这里插入图片描述

👆同样不接受，丢弃。（误码的单个分组：丢弃[然后导致后面的分组序号不匹配也被丢弃]。序号不对的一批分组：丢弃。）

👆丢弃几个(不算因误码已经丢掉的)，发送几个前面的确认分组，这里是四个ACK4。（这里不必纠结于个数。）
在这里插入图片描述

补充：Wt取值超范围👇

在这里插入图片描述
第一次发送的ACK7丢失了……

实现机制–选择重传协议SR

引入（由GBN）

在这里插入图片描述

概念

在这里插入图片描述
W_R的取值，一般情况下可与发送窗口的尺寸W_T的取值相同。
（“序号落在发送/接收窗口内/外”）

依次连续发送出去，2丢失。
接收方：只要序号落入接收窗口内，都接收。

接收方：
（1）接收 0号和1号数据分组，并发送 0号和1号确认分组，接收窗口向前滑动两个位置。

（这样就有四和五这两个新的序号，落入接收窗口）
（2）接收 3号数据分组，并发送 3号确认分组，但接收窗口不能向前滑动
（因为3号数据分组，是未按序到达的数据分组）

在这里插入图片描述
发送方：
（1）每按序收到一个确认分组，发送窗口就向前滑动一个位置（发送方接收0号和1号确认分组，发送窗口向前滑动两个位置）

（两个新的落入发送窗口，发送方将序号落入发送窗口的数据分组发送出去）
（现在可以将已经收到确认的0号和1号数据分组从发送缓存中删除了；而接收方可择机将以按序接收的0号和1号数据分组，交付上层处理）

（2）接收3号确认分组，但发送窗口不能向前滑动。不过需要记录👇3号数据分组已收到确认，这样该数据分组就不会超时重发

（因为这是一个为按序到达的确认分组）

4号5号到达，接收，但接收窗口不能向前滑动，因为他们是未按序到达的数据分组。

假设ACK4、ACK5传输过程中，2的超时。

（注意，接收ACK，不向前滑动，因未按序到达的，不过需要记录）
ACK2发过去，收到，之后就正常了。

窗口尺寸问题