当前位置：首页 > news >正文

【计网笔记】数据链路层

news 2025/7/5 18:01:14

向上网络层接口

向下物理层接口

封装成帧

字节计数法

字节填充的标志字节法

比特填充的标志比特法

物理层编码例外法

差错检测

数据链路层协议

停-等式协议

自动重传ARQ协议/带重传机制的肯定确认PAR协议

双向传输的捎带确认

滑动窗口协议

链路利用率

最大数据传输速率

滑动窗口协议实例

1位滑动窗口协议

回退N帧GBN协议

发送窗口长度选择

选择重传SR协议

发送与接收窗口长度选择

向上提供透明接口
向下将比特流拆分为若干个帧，为每个帧计算校验和
- 接收端基于校验和检查帧内的比特差错

向上网络层接口

无确认的无连接服务
- 以太网
- 无需逻辑连接
- 双方无需确认
有确认的无连接服务
- IEEE802.11（WiFi）
- 无需逻辑连接
- 接收方确认收到帧
- 发送方如果超时未确认，就重新发送帧
有确认的面向连接服务
- 需逻辑连接
- 每一帧都被编号
- 每个帧确认收到，只被收到一次，所有帧按顺序收到

向下物理层接口

封装成帧

字节计数法

帧头放入该帧（包括帧头）的字节长度

稳定性差，很少使用

字节填充的标志字节法

用一些特殊字符FLAG表示帧的开始和结束

如果特殊字符在数据中出现
- 发送方的数据链路层在来自网络层的数据前面插入转义字符ESC
- 接收方的数据链路层删除转义字符再交给网络层
如果转义字符在数据中出现，就转义转义字符

帧长取决于数据字段内容
- 最好情况下增加2字节
- 最坏情况下翻倍

PPP使用

比特填充的标志比特法

开始和结束都用约定的比特模式标记：01111110（0x7E）

如果在数据字段识别到了连续的5个1，就立刻插入一个0

帧长取决于数据字段内容
- 最好情况下增加2字节
- 最坏情况下增加12.5%（每个字节+1bit）

USB使用

物理层编码例外法

利用物理层编码准备的标记信号来标识帧的开始和结束

4B/5B码的16个信号标识

以太网和WiFi使用

在帧前插入一个前导码
- 这个码不会在物理层编码的数据字段中出现
- 标识帧的开始
前导码后是帧长度字段
- 计算帧的结束处

【2022-912】链路层成帧的方法不包括（A）
A. 偏移量法

B. 物理层编码违例法

C. 带位填充首尾字节标记法

D. 字符计数法

差错检测

纠错码：Hamming码
检错码：循环冗余校验CRC

【计组笔记】存储器

【2021-912】对于CRC产生式G(x)=x^2+x+1，下面信息正确的是（C）

A. 11101010

B. 11001111

C. 10001011

D. 11100011

数据链路层协议

停-等式协议

信道不出错
单向数据流量
- 信道在每个时刻都是单向的
- 帧仍然是可以双向传输的
  - 确认帧不算数据帧

发送方每发送一帧都需要等待接收方发送的确认帧，确认后才发下一帧

发送方只会收到确认帧
- 因假设信道不出错

自动重传ARQ协议/带重传机制的肯定确认PAR协议

信道可能出错
- 帧内比特出错
- 整个帧丢失
单向数据流量

把帧加上0-1记号

发送方把帧按发送次序轮流标记为0或1
接收方接收到标记位符合的（正确）帧才收下并发送确认帧，否则丢弃帧并等待
- 如果标记为0的帧传输中丢失，发送方超时重传
- 如果标记为0的帧抵达接收方并被接收，上传给网络层
  - 接收方下一个期望收到标记为1的帧
  - 确认帧丢失
  - 发送方超时重传标记为0的帧
  - 标记为0的帧到达接收方，接收方拒绝该帧，并再次发送对标记为0的帧的确认

双向传输的捎带确认

接收方在接收帧的不久后就要发给发送方数据，对上一个帧的确认可以搭载在发过去的数据帧上

设置计时器
- 时间结束前有网络层请求就捎带确认
- 时间结束就发送单独的确认帧

滑动窗口协议

信道可能出错
全双工通信

帧序号0~MAX_SEQ
- MAX_SEQ一般形如2^n-1（用n位存）
窗口上/下边界：应该被最后/先发送的帧
- 换言之，窗口是自下而上移动的
- 一旦从网络层收到新帧，上边界上移
- 一旦从接收方收到确认帧，下边界上移

链路利用率

$utilization\ rate = \dfrac{nT_s}{T_s+2BD+T_a}$

n为发出的数据帧数量
Ts为数据帧处理时间=数据帧位数/信道带宽
Ta为确认帧处理时间=确认帧位数/信道带宽
BD为传播时延
- 数据帧去途需要1BD，确认帧返途需要1BD
- 只有整个帧都被收到了才会发出确认帧，有1帧的延迟

最大数据传输速率

$max\ data\ transfer\ rate = \min\{\dfrac{bits\ in \ the\ window}{T_s+2BD+T_a},bandwidth\}$

窗口内位数=单帧位数×窗口大小

滑动窗口协议实例

1位滑动窗口协议

与ARQ类似

回退N帧GBN协议

发送窗口尺寸为w>1
- w=1时退化为停-等协议
- 利用管道化实现帧连续发送
接收窗口尺寸为1

发送方在窗口填满前如果收到确认帧，就可以前移窗口，达到多帧在途

如果接收到的帧就是预期的帧且没出错，就收下并交给网络层，发送对这个帧的确认帧ACK，接收窗口向上移动
如果接收到的帧不是预期的帧或出错，与没收到帧处理相同，不发送确认帧
- 接收方的出错帧将超时重传，出错帧的后续帧即使顺利送到，但也因无确认帧而超时重传
- 累计确认：当第n号帧的确认到达时，第n号帧及其之前的帧都会被确认
  - 此时发送窗口的下边界变为n+1

发送窗口长度选择

发送窗口的长度和最大在途数据帧数相同（超时计时器不太短）

发送窗口的长度必须大于MAX_SEQ+1

否则由于标号的循环性，会不知道接收到的确认帧是来自当前循环的标号还是上个循环的标号

最大在途帧数由传播时延决定，传播时延由带宽、单向传送时间、帧所含的位数决定

要使得信道充分利用，w=2BD+1

选择重传SR协议

发送窗口尺寸为w>1
接收窗口尺寸为v>1
- v=1时退化为GBN
- 接收窗口是缓存区，大小始终不变

接收方缓存丢失帧后续的几个帧，避免大量回退

如果接收到的帧标号在接收窗口下边界，就收下并交给网络层，发送对这个帧的确认帧ACK，接收窗口向上移动
如果接收到的帧标号在接收窗口内但不是下边界，就收下并缓存
- 此时意味着接收窗口下边界的帧丢失了
- 接收方发送一个针对接收窗口下边界的否定确认帧NAK
  - 或者发送一个接收窗口下边界前一个编号的确认帧
- 发送方针对NAK重发帧或超时重传
发送方的发送窗口下边界如果被确认，下边界上移
累计确认