🎯 你正在阅读「网络原理续命手册」系列文章 🎯


🔥 弹简特 个人主页

❄️ 个人专栏直通车：

• 🔌 接口测试从入门到跑路
• ☕ 一个后端的 JavaEE 续命指南
• 🛜 网络原理续命手册
• ☕ Java项目-轻聊
• ☕ Java项目-企悦抽

✨ 靠热爱去书写自己，靠勇敢去书写生活！

---

🌟 博主简介:

---

一、前言

上一期我们介绍了网络层的 IP 协议，以及它的核心功能——地址管理和路由选择。在简要介绍完网络层之后，本期我们来浅浅地了解一下数据链路层的相关知识，并补充介绍应用层的 DNS 协议。

二、数据链路层

1、数据链路层的作用

那么，数据链路层的作用是什么呢？

数据链路层负责处理两个相邻节点之间的数据转发。

可以把它理解为：网络层规划"数据最终要去哪台机器"，而数据链路层负责"当前这一跳，数据该从哪块网卡发到哪块网卡"。

---

2、核心协议：以太网与 802.11

在数据链路层中，最核心的协议是以太网协议。"以太网"并不是一种具体的网络，而是一套技术标准；它既包含数据链路层的内容，也包含部分物理层的内容，例如：规定了网络拓扑结构、访问控制方式、传输速率等。

• 如果通过有线上网，走的是以太网协议；
• 如果通过 WiFi 上网，走的是 802.11 协议。

---

3、以太网数据帧格式

以太网在传输数据时，会把上层报文封装成数据帧。标准格式遵循 RFC 894，一帧数据由固定头部、可变长度载荷和尾部校验三部分组成：

---

3.1 帧结构总览

字段	长度	说明
目的地址	6 字节	接收方网卡的 MAC 地址
源地址	6 字节	发送方网卡的 MAC 地址
类型	2 字节	标识载荷数据的协议类型
数据	46 ~ 1500 字节	上层协议报文（载荷）
CRC	4 字节	循环冗余校验，用于差错检测

其中，数据部分长度必须在 46 ~ 1500 字节之间：最小 46 字节是以太网规定的最小载荷，最大 1500 字节即为 MTU（最大传输单元）。

3.2 三种常见载荷类型

类型字段决定了数据部分封装的是哪种上层协议。常见取值如下：

类型值	协议	数据部分构成
0x0800	IPv4	IP 数据报，长度 46 ~ 1500 字节
0x0806	ARP	ARP 请求/应答（28 字节）+ PAD 填充（18 字节）
0x8035	RARP	RARP 请求/应答（28 字节）+ PAD 填充（18 字节）

为什么 ARP / RARP 需要 PAD 填充？
ARP 和 RARP 报文本身只有 28 字节，达不到以太网最小载荷 46 字节的要求，因此需要在末尾追加 18 字节的 PAD（Padding）填充，使总长度满足规范（28 + 18 = 46）。

---

4、以太网数据帧各字段说明

1. 源地址与目的地址（MAC 地址）

源地址和目的地址指的是网卡的硬件地址（也叫 MAC 地址），长度为 48 位，在网卡出厂时就已经固化。

此处目的地址和源地址都是 MAC 地址。MAC 地址不是 IP 地址，它用 6 个字节表示，也叫物理地址。正因为 MAC 地址有 6 个字节，可表示的地址数量非常庞大，因此通常可以做到全球唯一，并在设备出厂时直接写入。

开发中也经常借助 MAC 地址作为设备身份标识，例如：

• 路由器根据 MAC 地址做 DHCP 地址分配；
• 企业内网根据 MAC 地址做设备准入控制；
• 将用户账号与特定设备绑定，防止账号在陌生机器上登录。

---

1.1 IP 地址和 MAC 地址有什么区别？

我们已经有了 IP 地址这一套地址体系，为什么还需要 MAC 地址？理论上保留一套地址体系就够了，但这里却存在两套。

其实背景是这样的：IP 地址和 MAC 地址分别由两个团队独立研发，最终双方达成共识——两套地址都保留下来，各自承担不同的职责：IP 地址用于网络层，MAC 地址专门供数据链路层使用。

---

那么当前IP和mac地址共存的情况下，IP和mac地址是怎么各自协同工作的呢？

1.2 IP 与 MAC 如何协同工作？

这里换一个更贴近计算机场景的类比：当你在浏览器里访问 www.example.com 时，数据是如何一步步到达服务器的？

• IP 地址在网络层使用，关注的是整个网络路径上的转发过程——从你家电脑，到家庭路由器，再到运营商网关，最终到达目标 Web 服务器；
• MAC 地址在数据链路层使用，关注的是转发的细节，尤其是两个相邻设备之间的转发——每一跳只关心"下一台设备是谁"。

网络层负责做路径规划，决定数据包要经过哪些节点：

数据链路层负责研究每一跳该怎么走——每一段的源 MAC 和目的 MAC 都会变化，但 IP 地址通常保持不变：

具体的发送过程如下。区别在于：IP 地址关注的是起点和终点；而源 MAC 地址和目的 MAC 地址对应的是相邻两个节点：

---

2. 类型字段、MTU 与 ARP

回到上图，类型字段描述的是载荷部分封装了哪种上层协议。类型值不同，数据部分的格式也不同：

• 0x0800（IPv4）：数据部分直接承载 IP 数据报，长度可达 1500 字节，是日常业务流量最常见的类型；
• 0x0806（ARP） 和 0x8035（RARP）：数据部分较短，需 PAD 填充至 46 字节，是对以太网的补充，起辅助作用。

对于 IP 协议的 IP 数据报，最大可达 64 KB；但在数据链路层，MTU 限制为 1500 字节。因此，IP 数据报之所以需要拆包和组包，很多时候正是因为数据链路层的这一限制。

---

2.1 转发表与 ARP 协议

那上述的ARP和RARP是对以太网的补充起一个辅助作用：
数据链路层还有一件重要的事：决定当前这份数据从哪个接口发出去。IP 层通过路由表决定数据走 LAN 口还是 WAN 口；而在数据链路层，设备会维护一种叫转发表的数据结构——这是硬件层面的表，不是软件层面的。

ARP 协议并不负责传输实际的业务数据，它更像是一个辅助型协议。它的核心作用，是根据已知的 IP 地址，找到对应的 MAC 地址。

为什么需要通过 IP 找 MAC？

我们在编写代码、配置网络时，使用的都是 IP 地址；路由器也是根据 IP 地址查询路由表，完成网络层的转发。但到了数据链路层，设备之间的通信必须依靠 MAC 地址，发送以太网帧时也必须填写目标 MAC 地址。因此，在发送数据前，需要先根据下一跳节点的 IP，找到它对应的 MAC 地址——这个过程就由 ARP 协议完成。

ARP 的基本原理：

主机或路由器会通过广播的方式发送 ARP 请求报文，询问某个 IP 地址对应的 MAC 地址是什么。网络中所有设备都会收到这个请求，只有 IP 匹配的设备会回复一个 ARP 响应报文。发送方收到响应后，会将 IP 与 MAC 的对应关系缓存下来，形成一张类似哈希表的 ARP 缓存表，方便后续直接使用。

---

三、应用层补充：DNS 协议

1、DNS 是什么？

DNS 即域名解析协议。我们日常所说的网址，本质上就是域名，例如 www.example.com。你在 IDE 或终端里敲下这个域名、按下回车，背后发生的核心逻辑，是与目标服务器建立通信；而网络设备之间的通信，最终依靠的是服务器的 IP 地址。

虽然直接输入 IP 地址也能访问目标服务器，但 IP 地址是一串抽象的数字组合，记忆和使用起来十分不便。因此，人们设计了一串具有描述性、通俗易懂的字符串来替代 IP 地址——这就是域名。

需要注意的是，域名仅为人类记忆和使用提供便利，计算机底层进行网络通信时，仍然只能识别 IP 地址。所以，必须有一套机制能自动将我们输入的域名转换为计算机可识别的 IP 地址。这个"域名转 IP"的核心过程，正是由 DNS 协议完成的——DNS 不仅是一套协议，更是一套完整的域名解析系统。

引入域名还有一个显著优势：当服务器需要迁移时，只需修改域名与 IP 地址的对应关系，无需让用户记忆新的 IP 地址，极大降低了服务器迁移的操作成本和使用门槛。

---

2、DNS 的演进：从 hosts 文件到 DNS 服务器

可能有朋友会好奇：DNS 系统最初是如何实现域名与 IP 映射的？

其实，DNS 最初并非一套独立的服务器系统，而是通过 hosts 文件来记录域名与 IP 地址的对应关系。但随着网络设备和域名数量的增多，hosts 文件的维护工作变得愈发繁琐，难以满足大规模网络的需求。

为了解决这一问题，人们将 hosts 文件中记录的域名与 IP 映射关系提取出来，单独部署到专门的服务器上，这类服务器就被称为 DNS 服务器。此后，用户访问某个网站时，会先向 DNS 服务器发起查询请求，获取域名对应的 IP 地址，再通过该 IP 地址访问目标服务器，完成整个网络请求流程。

---

3、DNS 的分级存储机制

这里补充 DNS 的核心特性之一：DNS 域名采用分级存储的方式。这种分级结构能高效管理全球海量域名，也是 DNS 服务器能快速响应查询请求的关键。

我们以常见的 www.example.com 为例，结合分级逻辑详细说明：

DNS 域名的分级从顶层到下层依次递减，对应不同层级的 DNS 服务器，各级服务器各司其职、存储对应层级的域名信息，具体如下：

1. 最顶层（根 DNS 服务器）：作为域名分级的最高层级，根服务器不直接存储具体域名与 IP 的映射，而是存储全球所有一级域名（又称顶级域名，如 .com、.cn、.org 等），以及每个一级域名所对应的二级域名服务器的地址，为后续查询指引方向。

2. 一级域名服务器（如 .com 服务器）：负责存储自身管辖范围内的所有二级域名（如 example.com、github.com 等），同时记录每个二级域名所对应的三级域名服务器的地址，承接根服务器的查询请求，并向下指引。

3. 二级域名服务器（如 example.com 服务器）：负责存储自身管辖范围内的三级域名（如 www.example.com、api.example.com 等），以及三级域名对应的目标服务器 IP 地址（或更低层级服务器地址），完成最终的域名与 IP 映射查询。

结合示例 www.example.com 来看，其分级结构为：三级域名（www）→ 二级域名（example）→ 一级域名（com）→ 根域名。查询时，会从根服务器开始，依次向下查询一级、二级域名服务器，最终找到 www.example.com 对应的 IP 地址——这一过程完全依托分级存储机制实现高效跳转。

完整的 DNS 查询流程如下：

---

3、hosts 文件的现状

这里补充一点：虽然 hosts 文件早已不再用于大规模网络的域名解析，但它的功能依然保留，且域名解析优先级高于 DNS 服务器。目前，hosts 文件的主要用途是程序测试——例如在本地开发 Web 项目时，可通过修改 hosts 文件将 dev.myapp.com 绑定到 127.0.0.1，实现本地访问测试，而无需修改 DNS 服务器配置。

---

4、DNS 如何应对海量并发查询？

看到这里，可能有朋友会产生疑问：全世界的网络设备和域名数量极其庞大，如果用户每次发起网络请求，都需要向 DNS 服务器查询域名对应的 IP，DNS 服务器必将承担海量的并发请求，很容易出现崩溃的情况。针对这一问题，行业内主要有两种解决方案：

第一种是缓存机制。 用户的电脑在首次访问某个域名（如 www.example.com）时，会向 DNS 服务器发起查询请求，获取对应的 IP 地址；同时，电脑会将这个"域名-IP"的对应关系缓存起来。后续再次访问该域名时，无需重新向 DNS 服务器发起请求，直接调用本地缓存的 IP 地址即可，大幅减少 DNS 服务器的请求压力。

第二种是多 DNS 服务器部署。 全球范围内并非只有一台 DNS 服务器，而是存在多台存储原始"域名-IP"映射数据的根服务器。各大网络运营商会搭建 DNS 镜像服务器，将根服务器中的数据同步到本地镜像服务器中。这样一来，全世界各地的用户发起 DNS 查询请求时，会优先访问本地的 DNS 镜像服务器，分散了根服务器的并发压力。即便某一台 DNS 服务器出现故障，也不会影响整体的域名解析服务，有效避免了 DNS 服务器因并发量过大而崩溃的问题。

---

最后，如果这篇文章对你有帮助，欢迎点赞、收藏，并关注一下

本期我们顺带了解了 DNS 这一应用层协议，但应用层的内容远不止于此。下一篇，我们将正式走进应用层，系统介绍这一层级的核心职责与常见协议——比如日常上网离不开的 HTTP / HTTPS，以及它们如何基于下层传输层完成一次完整的 Web 请求与响应。