一、数据链路层 功能
"数据链路层" 功能 :
① 可靠性服务 : “数据链路层” 在 物理层 提供的服务的基础上 , 提供可靠性服务 ;
② 服务内容 : 将 网络层 下发的数据 , 可靠地 传输给 相邻节点的 网络层 ;
③ 逻辑上无差错链路 : “数据链路层” 加强了 物理层 传输 比特流 的能力 , 物理层传输可能出错 , 数据链路层可以将 物理连接 改造成 逻辑上无差错 的数据链路 ;
"数据链路层" 功能 列举 :
① 为网络层 提供服务
无确认无连接服务
有确认无连接服务
有确认有连接服务
② 链路管理 , 面向连接的服务中 , 建立连接 , 维持连接 , 释放连接 ;
③ 将 数据报 组成 数据帧
④ 流量控制 , 主要是 限制 发送方的数据率 ;
⑤ 差错控制 , 帧错误处理 ( 重发 ) , 位错误处理 ( 纠正 ) ;
参考博客 : 【计算机网络】数据链路层 : 概述 ( 基本概念 | 功能 | 为 “网络层“ 提供的服务 )
二、封装成帧 ★
1 . 数据帧透明传输需求 :
① 数据帧封装 : 数据帧 添加 帧首部 , 和 帧尾部 ; 帧首部 和 帧尾部 之间的部分就是实际的数据 ;
② 传输 文本文件 : 数据帧 的数据 是 文本文件组成时 , 数据都是 ASCII 码 , 键盘上传输的任何字符 , 都 可以透明传输 ;
③ 传输 非文本文件 : 如果传输的文件是 非 文本文件 , 如 图像 , 音频 , 视频 等 , 此时 文件中的数据可能是任意值 , 就有可能与 帧尾部 或 帧首部 相同 , 此时就需要 采用 字符填充法实现 透明传输 ;
2 . 字符填充法 :
① 数据的随机性 : 原始数据中 , 存在 与 帧首部 , 帧尾部 相同的数据 ;
② 发送端填充转义字符 : 在这些 数据中的 帧首部 / 帧尾部 相同的数据前 , 填充一个转义字符 , 告诉接收端 , 转义字符后的后续数据作为帧数据 , 不当做 帧首部 / 帧尾部 使用 ;
③ 接收端接收数据 : 接收端 接收到的数据中有 转义字符 + 帧首部 / 尾部 样式的信息时 , 将转义字符后的数据当做帧数据 ; 当接收到 单独的 帧首部 / 尾部 时 ( 没有转义字符 ) , 才将其当做数据帧的首部 / 尾部 ;
3 . 零比特填充法 :
① “数据帧” 首部尾部设定 : 数据帧首部尾部 都设定成 01111110 0111111001111110 , 解决 数据中出现 01111110 0111111001111110 数据的情况 , 实现透明传输 ;
② 发送端 : 扫描发送数据 , 发现有连续的 5 55 个 1 11 , 就在后面加上一个 0 00 ; 这样 帧数据 永远不会出现 6 66 个 1 11 的数据 ;
③ 接收端 : 扫描接收数据 , 发现有连续的 5 55 个 1 11 , 就将后面的 0 00 删除 ; 对应 发送端的操作 ;
这样在比特流中可以传输任意比特组合 , 不会引起 数据帧 边界判定错误的问题 , 实现了透明传输 ;
参考博客 : 【计算机网络】数据链路层 : 封装数据帧 ( 附加信息 | 帧长度 | 透明传输 | 字符计数法 | 字符填充法 | 零比特填充法 | 违规编码法 )
三、流量控制 和 可靠传输 ★★
1、停止等待协议 ★
1 . 停止等待协议
停止-等待 协议 解决的问题 :
可靠传输 : 解决 由于 物理线路 , 设备故障 , 路由错误 等各种问题导致的 丢包问题 ;
流量控制 : 实现 发送端 与 接收端 的 流量控制 ;
停止-等待 协议 讨论场景 : 只考虑 一方为发送方 , 一方为接收方 ; 相当于 单工通信场景 ;
停止-等待 协议内容 : 发送方 每 发送完一个 数据帧 ( 分组 / 数据报 ) , 就停止发送 , 等待接收端确认 , 接收到 接收端 确认信息后 , 再发送下一个分组数据 ;
停止-等待 协议 应用场景 :
无差错情况
有差错情况
2 . 信道利用率 :
"停止-等待协议" 性能分析 :
优点 : 简单
缺点 : 信道利用率 低 ;
信道利用率 :
U = T D T D + R T T + T A U = \cfrac{T_D}{T_D + RTT + T_A}
U=
T
D
+RTT+T
A
T
D
U UU 是信道利用率 ;
T D T_DT
D
是发送方发送延迟 , 即发送方用了多长时间将数据帧发送完毕 ;
R T T RTTRTT 是往返时延 ;
T A T_AT
A
是接收方 发送 A C K ACKACK 确认帧 的时延 ;
"停止-等待协议" 信道利用率很低 , 大部分事件都在 传输的延迟上 , 用于发送接收的时间很少 ;
3 . 停止等待协议 信道利用率 计算示例 :
信道传输速率 4000b/s , 单向传播时延 30ms , 使 “停止-等待” 协议 信道利用率达到 80% , 数据帧长度至少是多少 ? ??
信道利用率公式为 :
U = T D T D + R T T + T A U = \cfrac{T_D}{T_D + RTT + T_A}
U=
T
D
+RTT+T
A
T
D
先把数据单位收拾下 , 传输速率 4000 比特 / 秒 , 单向传播时延 0.03 秒 , RTT 是 0.06 秒 ; 设 数据帧长度是 L LL 比特 ; 这里没有给出 ACK 发送延迟 , 当做 0 00 ;
L 4000 L 4000 + 0.06 + 0 = 0.8 \cfrac{\dfrac{L}{4000}}{\dfrac{L}{4000} + 0.06 + 0} = 0.8
4000
L
+0.06+0
4000
L
=0.8
分子分母都乘以 4000 40004000 ;
L L + 240 = 0.8 \cfrac{L}{L+ 240} = 0.8
L+240
L
=0.8
L = 0.8 L + 192 L= 0.8 L + 192L=0.8L+192
0.2 L = 192 0.2L= 1920.2L=192
L = 960 L= 960L=960 单位是 比特 ;
数据帧的长度至少是 960 960960 比特 ;
参考博客 : 【计算机网络】数据链路层 : 停止-等待协议 ( 无差错情况 | 有差错情况 | 帧丢失 | 帧出错 | ACK 确认帧丢失 | ACK 确认帧延迟 | 信道利用率公式 | 信道利用率计算 )★
2、后退 N 帧 ( GBN ) 协议 ★
"停止-等待" 协议 弊端 : 信道利用率低 , 发送完一帧后等待 , 这个时候信道完全是空闲的 ;
为了提高信道利用率 , 发送端 发送完一帧后 , 不用等待 接收端的 ACK 确认帧 , 立刻发送 第二帧 , 第三帧 , 这样信道的利用率就提高了 ;
相应协议也要做一些更改 :
① 增加 发送方 的 帧 序号范围 ;
② 发送方 缓存 多个 帧分组 ; 连续发送 N NN 帧 , 其中某一帧 可能需要重传 , 但不知道哪一帧需要重传 , 这里 需要将这 N NN 帧全部缓存下来 ;
这里有引出了两个在 “停止-等待” 协议基础上 , 改进的两个协议 :
后退 N NN 帧协议 ( GBN )
选择重传协议 ( SR )
2 . 后退 N 帧协议 重点 ★
发送方 累计确认 机制 : 收到 ACK N NN , 就表示 N NN 号帧及之前的帧 , 全部正确 ;
接收方 按序接收 : 接收方 只能 按照顺序接收 , 人如果中间有帧丢失 , 那么后续帧全部丢弃 ;
接收方 确认帧 : 接收方 如果 收到错误帧 , 失序帧 , 那么查找最近成功接收的正确的帧的最大的 , 按序到达的帧 序号是多少 , 发送该帧对应的 ACK 确认帧 ;
发送窗口 : n nn 是帧序号编码长度 , 发送窗口大小 最大是 2 n − 1 2^n - 12
n
−1 , 最小 1 11 ;
3 . 后退 N 帧协议 计算示例 :
数据链路层 采用 后退 N NN 帧协议 , 发送方 发送了 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 0,1,2,3,4,5,6,70,1,2,3,4,5,6,7 编号的数据帧 , 当计时器超时时 , 只接收到了 0 , 2 , 3 0 , 2, 30,2,3 帧的确认帧 , 发送方需要重发的帧数时 4 , 5 , 6 , 7 4,5,6,74,5,6,7 帧 ;
计时器超时 , 发送方 发送 已发送 , 但是没有被 确认 的帧 ;
确认机制 是 累计确认 的 , 发送方 接收到了 3 33 确认帧 , 说明 3 33 之前的帧已经成功接收了 , 虽然没有收到 1 11 确认帧 , 但是该帧已经默认接收成功 ;
重发 没有被确认的帧 , 即 4 , 5 , 6 , 7 4,5,6,74,5,6,7 帧 ;
参考博客 : 【计算机网络】数据链路层 : 后退 N 帧协议 GBN ( 滑动窗口 | 发送窗口长度 | “发送方“ 累计确认、超时机制 | “接收方“ 按序接收、确认帧发送机制 | 计算示例 )★
