0、前言

本文大多数图片都来自于 B站UP主：湖科大教书匠 的教学视频，对高军老师及其团队制作出这么优质的课程表示感谢。本文的撰写目的不是为了应试，且受限于个人水平，可能和标准答案有所出入，请自行甄别，以考纲教材为准，不要被本文误导！

1、概述

1.1、数据链路层在计算机网络体系中的位置

1.2、对 MAC 地址的理解

MAC 地址并不是针对主机（或路由器）而言的，而是针对网卡（或路由器的接口）而言的，每一张网卡都有一个MAC地址：

• 一台主机一般有以太网卡（有线网卡，Ethernet）和无线网卡（WLAN，Wireless LAN），在 Windows 系统上可以通过 ipconfig /all 进行查看
  
• 路由器的每一个接口可以认为是一张网卡（暂时这么认为），下图是通过 Packet Tracer 查看 Router1941 的配置项
  

1.3、认识网卡（网络适配器）

• 核心芯片：其中有 数据缓冲区，用于缓冲发送或接收到的数据
• PCI 接口：Linux 系统中可以通过 lspci 来查看 PCI 设备，可以认为是 ls pci 的组合命令。
  曾在个人笔记本上安装 CentOS 7、Kali Linux、Ubuntu等，但无论怎么重装，都出现 WiFi 不可用的问题，也就是无线网卡的问题。在寻找解决方案的过程中，会遇到一些文章中提到 lspci | grep net 来查看网卡
• EEPROM：可编程电可擦除只读芯片，存储 MAC 地址

除了物理网卡，还要一些虚拟网卡，例如：

• 在 Linux 系统上使用 ip address 可以查看到有一张名为 lo 的网卡，这就是用于本地回环测试¹的网卡
• 在使用 VMWare 等虚拟机软件后，可以看到操作系统中会多出一些 VMnet8、VMnet1 这些用于和虚拟机通信的虚拟网卡

---

---

二、数据链路层的机制（理论）

数据链路层要解决的问题：

1. 封装成帧和透明传输
2. 差错检测（误码检测）
3. 可靠传输（非必须）

2.1、封装成帧和透明传输

2.1.1、封装成帧

要考虑的问题是：上层传递过来的数据最终以 bit 流（面向比特的链路） 或 byte 流（面向字节的链路），需要一种机制使得接收方能够区分数据的开始和数据结束。

方式一：插入帧定界符
PPP 协议采用该方案，存在缺陷的原理如下：

1. 约定起始符号和终止符号（可以是同一个，记为 FLAG，PPP 协议中该值是 0x7E，二进制形式为 01111110）
2. 遇到第一个 FLAG 认为是数据开始，遇到第二个 FLAG 认为是数据结束

方式二：采用帧间间隔
以太网协议采用该方案，原理如下：

1. 插入前导码（同步+起始符的功能）
2. 传输完一个帧后，等待一个帧间间隔（28us）后再传输下一个帧。

相当于采用 NULL 来作为终止符，即一段时间不传输数据，来接收方来确定帧结束

2.1.2、透明传输（完善的帧定界符方案）

帧定界符方案存在一个问题：如果上层传递过来的数据中存在 FLAG 这个值，那么就会发生误判，如下图所示

透明传输要解决的正是这个问题：让数据荷载中可以包含任意数据。上层不需要关系底层细节，即透明。

相似问题：

• 如何在一个字符串中包含 " 符号？

基于字节的解决方案：使用转义字符（ESC，PPP协议中该值为 0x7D）

综上所述，使用透明传输需要发送方和接收方都对数据进行额外的处理（开销），具体过程如下：

1. 发送方发送数据时，扫描帧的数据荷载部分，对其中的 FLAG、ESC 都进行转义（细节），即在前面插入 1B 的 ESC 字符
2. 接收方接收数据时，扫描帧的数据荷载部分，当发现 ESC 时，就不对下一个字节的数据进行判断，直接提取即可。当需要判断的时候发现 FLAG，那么说明数据结束。

基于比特的解决方案：改造数据荷载，让数据荷载中不出现 FLAG（01111110） 这个序列，且接收方能够还原
FLAG 中间出现连续 6 位 1，因此只需要遍历数据荷载中的每一比特，当发现 5 个连续比特位为 1 时，再其后插入 1 位 0，即 5110。

1. 4110、3110、2110、1110、0110 这些方案都是可行的，都可以保证数据荷载中不会出现 FLAG 这个序列。之所以选择 5110，是因为它的开销最小，假如采用 0110，那么相当于在原来数据的基础上扩充了一倍的数据长度，那么 1500 B 的数据荷载就需要分成两次进行发送，增加了开销。
2. PPP 协议中发送除了插入转义字符外，还会将其后的数据（待转义的字节数据，即 FLAG 和 ESC）和 0x20 进行异或。接收方在提取该字符时，会再和 0x20 进行异或来还原。这本质上也是保证数据荷载中不会出现 FLAG 字符，和基于比特的解决方案在本质上异曲同工，但个人这里有点疑惑，因为感觉这个步骤是可以没有的，不理解为什么 PPP 协议要这么做？

2.2、差错检测

2.2.1、奇偶校验

奇校验：添加一个比特位，使得数据中比特 1 的总数为奇数
偶校验：添加一个比特位，使得数据中比特 1 的总数为偶数

2.2.2、CRC 循环冗余校验

以太网（Ethernet）、PPP 协议中均采用该方式进行差错检测，且以太网中如果出现帧错误，会直接丢弃帧，而不会重传。

帧错误的情况

• MAC 帧的长度不是 8k bit（其中 k = 1,2,…）。即字节流
• MAC 帧长度不在 [64, 1518] 之间，其中小于 64B 的帧表示该帧是因发生碰撞而异常终止的无效帧
• FCS 帧检测错误

FCS 的计算过程

1. 发送方和接收方约定生成多项式，例如，G(X) = X^4 + X^2 + X + 1
   

2. 发送方：数据对齐、模二除法（异或）
   若生成多项式 是 n 阶多项式，则在待发送数据后面补 n-1 个 0。最后得到的余数即为 FCS（帧检验序列，n-1 位）
   

3. 接收方：模二除法（异或）
   接收数据后，用约定的生成多项式进行模二除法，如果最后能够整除，则认为没有出现错误，否则一定出现错误。

2.2.3、海明码（纠错码）

以太网（Ethernet）并没有使用，成本太高，效率低。

原理：TODO

2.3、可靠传输

• 不可靠传输：发现帧出现错误，直接丢弃，其它什么也不做
• 可靠传输：需要提供一系列机制，来实现发送方发送什么，接收方最终就能够收到什么

一般情况下，有线链路的误码率比较低，为了减小开销，只需要提供不可靠传输，可靠性由上层进行保证，例如在传输层使用 TCP 协议；而无线链路容易受到干扰，误码率比较高，因此需要在数据链路层提供可靠传输。

可靠传输的开销比较大，具体是否使用可靠传输取决于应用的需求，并非所有的东西都要可靠、安全

2.3.1、传输过程中可能出现的问题

传输错误	出现场景
比特错误	传输损耗，相当于基因突变
分组丢失	路由器的缓冲队列已满
分组乱序	不同分组可能沿着不同的路径从源主机到达目的主机
分组重复	主机或路由器都有可能因为超时重发

2.3.2、实现可靠传输所需的机制

确认机制

超时重传机制

序号机制

2.3.3、用于实现可靠传输的滑动窗口协议（SW、GBN、SR）

滑动窗口协议要求：

1. 分组使用 n 个比特位进行编号
2. 发送窗口大小（$W_T$） + 接收窗口大小（$W_R$）$\le$ $2^n$
3. 发送窗口大小（$W_T$）$\ge$ 接收窗口大小（$W_R$）$\ge$ 1

对 $W_T+W_R\le 2^n$ 的解释：

1. 假设 $n$ 为 3，发送窗口大小 $W_T$ 为 5，接收窗口大小 $W_R$ 为 4
2. 接收方顺利且依次接收到发送方发送的分组0、分组1、分组2、分组3、分组4
3. 接收方此时的接收窗口内的值分别为[5][6][7][0]
4. 不幸的是，接收方返回的确认报文全部丢失，这种情况下会触发发送方的超时重传
5. 接收方再次接收到重传的分组0，并错误地将其认为是新的分组。在没有滑动窗口和的限制条件下，接收方无法识别是重传的分组还是新的分组。

三种协议的差异：

协议	发送窗口大小	接收窗口大小	确认机制	信道利用率
停止-等待协议（SW）	$1$	$1$	逐帧确认	见图示
回退 N 帧协议（GBN）	$2^n-1$	$1$	累积确认	见图示
选择重传协议（SR）	$2^{n-1}$	$2^{n-1}$	逐帧确认	见图示

其中，n 表示使用 n 个比特位来标识 PDU （帧/分组/报文）的序号

信道利用率

一般认为，确认分组的长度远小于数据分组，因此 $T_A$ 的长度可以忽略不计。所以在停止等待协议（SW）中，信道利用率（U）表示为

$$U=\frac{T_D}{T_D+RTT}=\frac{1}{1+\frac{RTT}{T_D}}$$

无线局域网的覆盖半径不超过 100 米，因此其 RTT 可以忽略不计，所以在无线局域网中反而使用最简单的停止等待协议。

图a：停止-等待协议（SW）

图b：后退 N 帧协议（GBN）

---

---

三、相关协议

3.1、以太网协议（802.3标准）

3.1.1、MAC 帧

长的数据载荷，控制字段的占比低，相当于提高了数据的发送效率（正常情况）。但帧比特位的增加也意味着帧发生错误的概率增加了，且出错后的重传开销也增加，需要发送更多的数据。（异常情况）

短的数据荷载，控制字段的占比高，相当于降低了数据的发送效率（正常情况）。但帧比特位的减少也意味着帧发生错误的概率降低了，且出错后的重传开销也降低，只需要发送很少的数据。（异常情况）

此外，帧不能过短还与CSMA/CD（载波监听多址接入碰撞检测）、信道利用率有关

3.1.2、MAC 地址

MAC 地址是一个 48 bit 的数字，假设自左向右地址依次增大 （注意是假设），如下图所示

其中，bits[0] 表示单播（0）或多播（1）地址，bits[1] 表示全球管理（0）或本地管理（1）。

蛋疼的点：MAC 地址的表示逻辑和 IP 地址的表示逻辑并不统一。 原因在于，MAC 地址在表示的时候，是以字节为单位进行表示的，左边是字节低位，右边是字节高位。因此在表示上，上面的比特数组变成了下面的形式

3.2、PPP 协议

3.2.1、PPP帧

其中的标志字段就是帧定界符，固定为 0x7E
地址字段和控制字段目前都没有什么用，属于预留字段

3.2.2、PPP 协议的应用场景

• 用户通过 PPP 协议接入 ISP（因特网服务提供商）

3.3、无线局域网协议（802.11标准，TODO）

四、交换机（网桥）

4.1、交换机结构

4.2、自学习算法

目的：

自动建立 MAC 地址和交换机端口的映射表

自学习算法流程：

1. 交换机从某个端口接收到某个 MAC 帧，从中提取出 源 MAC 地址（src），将其与接收端口进行映射，登记到 mac-address-table 中
2. 交换机从 MAC 帧中提取出 目的 MAC 地址（dest），并在 mac-address-table 中进行查找：
   • 如果能找到对应的 dest，那么就从除接收端口外的、相应的交换机端口转发 （明确转发）
   • 如果能找到对应的 dest，且待转发的端口和 src 对应的端口相同，那么就直接丢弃 （丢弃）
   • 如果不能够找到对应的 dest，那么就从除接收端口外的其它端口转发 （盲目转发）

• 帧如果错误，直接丢弃
• 广播帧不需要查表
• mac-address-table 相当于设置了自动过期时间的缓存数据库（Redis，过期键）

在 Windows 系统上可以通过 arp -a 命令查看各个网卡的 mac-address-table

4.3、生成树协议（STP，TODO）

五、局域网（LAN）的实现

5.1、以太网（Ethernet）

5.1.1、共享式以太网（CSMA/CD 协议）

CSMA/CD 协议并不能够避免碰撞的发生，而是针对发生碰撞后如何处理。根本原因是因为信号的传输有延迟，主机 C 监听到信道空闲，并不是真的表示信道空闲。

最小帧长和争用期

CSMA/CD（载波监听多址接入碰撞检测）要求在任意帧（最小帧）传输完之前，能够检测到是否发生碰撞，因此需要满足如下公式：

$$最小帧长=争用期（端到端往返时延）\times 链路传输速率（10Mb/s）$$
$$链路长度=端到端传播时延（半个争用期）\times 数据传播速率（近似光速）$$

规定最小帧长为 64B，因此争用期为 51.2us

这里是规定最小帧长得到争用期的值，或是规定争用期得到最小帧长。个人理解偏向前者，最小帧长最终会影响到网络的链路长度，可能考虑到链路长度最终确定最小帧长为 64 B（糊里糊涂胡说八道胡言乱语ing…）

退避算法

信道利用率

其中，$T_0$ 表示传输时延，而 $\tau$ 表示传播时延

5.1.2、交换式以太网

5.2、无线局域网（Wireless LAN）

六、虚拟局域网（VLAN）

6.1、需求背景

这里高老师的视频中提到 VLAN 是为了分隔广播域，而路由器是能够实现相同的功能的，但是路由器的成本更高，所以才有了虚拟局域网技术。但在后面的实验中就能够发现，使用 VLAN 来分隔广播域会产生一些 “副作用”，被分隔的两个虚拟局域网 VLAN2 和 VLAN3 之间不能进行通信（注意不是 VLAN1）。基于这个区别，抛开事实不谈，个人更愿意相信 VLAN 被设计出来是出于对网络安全的考虑，而分隔广播域只是网络隔离带来的一个副产品。

6.2、实现原理

端口有两种类型：

• Access（专用）
• Trunk（通用）

VID 用于标识创建的虚拟局域网（VLAN），默认情况下 VID = 1

帧转发流程：

1. 从交换机端口接收到报文后，会在交换机内部执行 “打标签” 的操作，即添加上端口所属 VLAN 的 VID
2. 该帧只会从 （a）相同 VID 的 Access 类型端口 或 （b）任意 VID 的 Trunk 类型端口 转发出去（支持单播、多播）
3. 根据发送端口的类型来决定是否执行 “去标签” 的操作（粗糙来说，Trunk 类型端口不去标签，案例一说明该现象）

案例一：主机 C 发送 VLAN2 的广播帧

如果在 交换机1 的 端口5 上执行去标签操作，当报文发送到 交换机2 时，会被误认为其属于 VLAN1，因此 Trunk 类型端口不执行去标签、打标签操作。

案例二：主机 A 发送 VLAN1 的广播帧

蛋疼的点：如下所示，Trunk 类型端口又执行了去标签和打标签。再次抛开事实不谈，个人觉得 Trunk 类型端口完全可以没有 VID，这里不能理解为什么要这么设计？强行解释的话，去标签后在链路上传输的数据量更少，但又能少多少呢，还增加了和 Trunk 类型端口判断 VID 是否相等的计算开销呢。

6.3、使用Packet Tracer软件进行实验

1. 构建网络拓扑结构
   

2. 通过 show interface status 查看接口状态
   其中 Vlan 表示接口所属的 VID（虚拟局域网唯一标识），默认情况下所有接口均属于 VLAN1
   

3. 创建 VLAN，即指定 VID 和 name

   • vlan 10：创建一个 VLAN，其中 VID = 10
   • name VLAN10：为该 VID = 10 的 VLAN 命名为 VLAN10（这里是执行上面命令后进入，所以不需要指定 VID）

4. 通过 show vlan brief 查看目前创建的 VLAN
   

5. 先进入到某个接口的配置模式，通过 switchport mode trunk 为接口分配所属类型（Trunk），默认是 Access 类型

6. 通过 switchport access vlan 10 为接口分配所属的 VLAN 的 VID

7. 配置完成后再次查看 VLAN
   

七、待解决的问题

1. 查看虚拟网卡 VMnet1，发现其 MAC 地址为 00-50-56-C0-00-01，为什么 bits[1] 是 0 而不是 1 呢？
2. CRC 检测的数学原理是什么？是100%正确的吗？FCS 错误，一定错误这是容易理解的。但 FCS 检验正确，但实际发生错误，是否存在这种可能性呢？

---

1. 目的 IP 地址为 127.x.y.z 的都称为回环地址，不仅仅是 127.0.0.1，这只是该 A 类地址中最小的一个。而 localhost 常在 host 文件中被解析为 127.0.0.1 而已。 ↩︎