1. 1. DHCP 与 DNS
    1. 1.1. 🧱 前言
    2. 1.2. 🔧 第一部分：搭建网络拓扑
      1. 1.2.1. 🔧 网络结构说明：
      2. 1.2.2. 🎯 实验目标：
        1. 1.2.2.1. ✅ 1. DHCP 部分
        2. 1.2.2.2. ✅ 2. DNS 部分
    3. 1.3. 🧭 概述：从“黑盒”到“熟悉的服务”
      1. 1.3.1. 🧠 为什么说这是“服务”而不是“设备”？
    4. 1.4. 🧩 DHCP 服务
      1. 1.4.1. 🔍 DHCP 是什么？
      2. 1.4.2. 📌 DHCP 的作用：
      3. 1.4.3. ⚙️ DHCP 服务器配置
        1. 1.4.3.1. ⚠️ 补充说明：
      4. 1.4.4. 📶 DHCP 流程演示
        1. 1.4.4.1. 🟡 第一步：DHCP Discover（发现）
        2. 1.4.4.2. 🟢 第二步：DHCP Offer（提供）
        3. 1.4.4.3. 🟠 第三步：DHCP Request（请求）
        4. 1.4.4.4. 🔵 第四步：DHCP ACK（确认）
        5. 1.4.4.5. 📬 最终，PC2 拿到的完整网络配置信息包括：
    5. 1.5. 🌐 DNS 服务
      1. 1.5.1. 🔍 DNS 是什么？
        1. 1.5.1.1. 🧩 DNS 的基本流程：
      2. 1.5.2. ⚙️ DNS 服务器配置
      3. 1.5.3. 🛣 访问流程演示
        1. 1.5.3.1. ✅ 第一步：DNS 查询请求
        2. 1.5.3.2. ✅ 第二步：DNS 服务器响应
        3. 1.5.3.3. ✅ 第三步：PC2 发送 HTTP 请求
        4. 1.5.3.4. ✅ 第四步：Web 服务器响应请求
        5. 1.5.3.5. 📦 总结这个访问过程：
    6. 1.6. ❓ 我们生活中的网络现象，背后藏着哪些 DHCP 和 DNS 原理？
      1. 1.6.1. 📌 1. 为什么在搭建局域网时，需要手动分配 IP？
        1. 1.6.1.1. ✅ 原因分析：
        2. 1.6.1.2. 🧱 举个例子：
        3. 1.6.1.3. 🔌 为什么不自动获取？
      2. 1.6.2. 📌 2. 为什么有时候我们能打开微信、QQ，却打不开网页？
        1. 1.6.2.1. ✅ 背后原因：很可能是 DNS 配置有误 或 DNS 服务器无法访问
        2. 1.6.2.2. ✅ 如何验证：
      3. 1.6.3. 📌 3. 为什么在个人建站时，需要分别购买 服务器 和 域名？
        1. 1.6.3.1. ✅ 原因解析：
        2. 1.6.3.2. ✅ 建站的典型流程：
    7. 1.7. 🧠 总结

DHCP 与 DNS

Linux

DHCP 与 DNS

🧱 前言

我们每天都在使用网络，却很少真正意识到背后是如何运作的：

  • 当把网线插到电脑上、或者手机连上 Wi-Fi，没填任何东西，系统就自动获取了 IP 地址、网关、DNS 服务器，直接就能上网。这到底是怎么做到的？
  • 又或者，当在浏览器里输入 www.baidu.com，电脑怎么就知道应该去联系哪台服务器？毕竟互联网通信靠的是 IP 地址而不是域名。

这些看似“自动”的事情，其实都离不开两个关键的网络服务：DHCP（动态主机配置协议） 和 DNS（域名系统）。

本篇博客将从零搭建一个小型的模拟网络，通过 Cisco Packet Tracer 工具，直观地理解：

  • DHCP 是如何自动给设备分配 IP 地址、网关和 DNS 的？
  • DNS 是如何将我们输入的网址解析成对应的 IP 地址？
  • 从一台 PC 启动开始，到成功访问一台 Web 服务器，中间到底经历了哪些步骤？

🔧 第一部分：搭建网络拓扑

使用 Cisco Packet Tracer 搭建一个小型的局域网络环境，来模拟现实中“客户端如何通过 DHCP 自动获取网络配置，并通过 DNS 解析域名访问 Web 服务”的全过程。下面是本次实验的网络拓扑结构图，和 B 站 湖科大教书匠 老师视频中的一致：

image-20250420162229467

🔧 网络结构说明：

设备类型 设备名称 IP 配置 作用
Web 服务器 Server0 192.168.1.1/24网关：192.168.1.254域名：www.dhcpstest.com 提供网页内容
DNS 服务器 Server2 192.168.0.253/24 维护域名 → IP 的解析记录
DHCP 服务器 Server1 192.168.0.252/24 动态分配 IP、网关、DNS 等参数
路由器 Router1 Gi0/0：192.168.0.254/24Gi0/1：192.168.1.254/24 连接两个子网，作为默认网关
交换机 Switch 无 IP 用于连接各个设备，实现局域网通信
客户端 PC2 / PC3 DHCP 自动获取 IP 模拟普通终端用户

🎯 实验目标：

我们的最终目标是让 PC2 通过访问域名 www.dhcpstest.com 成功连接到 Web 服务器 Server0，这个过程中涉及两个关键网络服务：

✅ 1. DHCP 部分

  • PC2 开机后自动获取 IP、子网掩码、网关、DNS 等配置参数
  • 无需手动配置，完全由 DHCP 服务器 Server1 提供

✅ 2. DNS 部分

  • PC2 向 DNS 服务器 Server2 发送查询请求，解析 www.dhcpstest.com
  • DNS 返回 Web Server 的真实 IP（192.168.1.1）
  • PC2 根据返回 IP 发起访问请求，网页正常加载

对于路由器网口的 IP 和子网掩码的设置，可以参考上一篇博客的内容：网络世界的邻居和陌生人：网段通信。

🧭 概述：从“黑盒”到“熟悉的服务”

在正式介绍 DHCP 和 DNS 之前，我们先来消除对这两个词的“技术恐惧感”或“概念模糊”。在初学网络时很容易会产生这样的疑问：

💭 “DHCP 和 DNS 到底是什么？是协议？是设备？还是某种看不见的神秘机制？”

✅ 其实，它们的本质很简单：DHCP 和 DNS 都是运行在服务器上的一种“网络服务”——它们像平时写的 Web 后端接口一样，等待请求、返回响应。

我们可以用 Web 开发中的 Flask 做类比：

  • Flask 是一个 Web 框架，我们在上面写不同的接口，绑定到不同的 URL
  • 比如 /login 提供登录功能，/data 提供数据读取功能
  • 后端程序监听某个端口，等待请求，一旦有客户端访问，就返回对应的响应

同样的，DHCP 和 DNS 服务器也是在网络中监听特定的端口，等待客户端的请求，并返回相应的数据：

服务类型 协议 端口号 作用说明
DHCP UDP 67（服务器监听） 68（客户端监听） 分配 IP、网关、DNS 等配置参数
DNS UDP（常用） TCP（当响应数据大于512字节时） 53 将域名解析为 IP 地址，完成地址映射

可以这样理解：

  • DHCP 是 “/get-network-config” 的接口，客户端说：“我需要一个 IP”，服务器返回配置
  • DNS 是 “/resolve-domain” 的接口，客户端说：“我需要这个域名的 IP”，服务器返回映射结果

🧠 为什么说这是“服务”而不是“设备”？

  • 提供 DHCP 或 DNS 服务的设备可以是服务器、路由器、甚至某些智能交换机
  • 它们的核心能力不在于硬件本身，而在于是否开启了相应的服务模块
  • 在我们的网络结构示例中，我们就是在 Server1 和 Server2 上“打开了” DHCP 与 DNS 服务
  • 在现实中，家庭路由器、企业服务器、云服务（如阿里云、Cloudflare）也都在运行这些服务

所以总结来说，DHCP 和 DNS 并不神秘，它们本质上就是一种“监听请求、返回响应”的服务接口，和我们平常用的 Flask、FastAPI 类似——只是协议不一样、应用场景不同。

🧩 DHCP 服务

🔍 DHCP 是什么？

在计算机网络中，每一台设备（例如电脑、手机、打印机、工控设备）都需要有一个唯一的 IP 地址，才能在局域网或互联网中进行通信。

如果每次都手动给设备配置 IP，那不仅耗时费力，而且容易出错（比如重复 IP、掩码设置错误）。这时候，DHCP（Dynamic Host Configuration Protocol，动态主机配置协议） 就发挥了巨大的作用。

📌 DHCP 的作用：

DHCP 是一种自动化协议，它能在设备接入网络时，自动分配 IP 地址、子网掩码、默认网关、DNS 服务器等信息，让设备“开机即联网”，无须人工干预。

你可以把它理解为：“网络中的自动分配中心”，设备来了，它就发一个号牌（IP 地址）+ 指南（网络配置）给你，告诉你怎么上网、找网关、问 DNS。

⚙️ DHCP 服务器配置

image-20250420170654649

在完成了网络拓扑的搭建之后，我们需要为网络中的客户端设备（例如 PC2 和 PC3）配置一个 DHCP 服务器，以便它们能自动获取 IP 地址、网关和 DNS 等网络信息。如上图所示，我们在 Server1 上启用了 DHCP 服务，并配置了一个名为 serverPool 的地址池（IP 地址池），主要需要配置的字段包括：

字段名称 示例值 作用说明
Default Gateway 192.168.0.254 分配给客户端的默认网关（用于出网）
DNS Server 192.168.0.253 分配给客户端的 DNS 服务器地址（用于域名解析）
Start IP Address 192.168.0.1 DHCP 地址池起始地址，DHCP 从这个 IP 开始分配
Subnet Mask 255.255.255.0 分配给客户端的子网掩码，用于定义网段范围
Maximum Number of Users 252 DHCP 可分配的最大主机数，从起始地址开始向后分配（注意避开 .0 和 .255）

通过这样的配置，DHCP 服务器会在客户端请求时，自动为它们分配如下信息：

  • IP 地址：从 192.168.0.1 开始顺序分配（如 PC2 获得 192.168.0.1，PC3 获得 192.168.0.2）
  • 子网掩码：255.255.255.0
  • 默认网关：192.168.0.254（即路由器）
  • DNS 服务器：192.168.0.253（即 Server2）

这使得客户端不需要手动配置任何网络参数，即可接入局域网、正常通信并访问 DNS 域名解析服务。

⚠️ 补充说明：

  • 为什么 Start IP 不用 .0？ 因为 .0 是网络地址，不能分配给主机；同理 .255 是广播地址，也不能用。
  • 地址池范围设置要注意避开静态 IP 比如你的 DNS 是 .253，网关是 .254，这些已经固定的 IP 就不应被 DHCP 分配，因此我们从 .1 开始、最大用户设置为 252。

📶 DHCP 流程演示

DHCP 的通信流程可以用一个非常经典的缩写来表示 —— DORA：

步骤 名称 发起方 类型 描述
D Discover 客户端 广播 客户端开机后发送广播，寻找 DHCP 服务器：“谁能给我分配 IP？”
O Offer 服务器 广播/单播 DHCP 服务器响应，提供一个 IP 地址和其他配置信息：“我可以给你这个地址！”
R Request 客户端 广播 客户端确认使用这个 IP 地址，请求服务器预留：“我想用你提供的这个 IP”
A Acknowledgement（ACK） 服务器 单播 DHCP 服务器确认：“OK，这个 IP 就是你的了！” 分配完成，设备成功上线

当我们在 Packet Tracer 中启动 PC2，并在它的设置中选择 DHCP 自动获取 IP，一连串的网络通信就悄然开始了。下面是整个过程的详细分解：

dhcp

🟡 第一步：DHCP Discover（发现）

PC2 刚启动时，还没有 IP 地址，它发出一个 广播数据包（目标 MAC：FF:FF:FF:FF:FF:FF），在整个局域网中大喊：

“谁是 DHCP 服务器？我需要一个 IP 地址！”

这个广播包会从 PC2 发出，通过交换机传递到整个局域网，包括连接在同一网段的 DHCP 服务器 Server1（IP：192.168.0.252）。

🟢 第二步：DHCP Offer（提供）

DHCP 服务器收到 Discover 广播后，会从自己配置好的地址池中选出一个未被占用的 IP，比如 192.168.0.1，然后发回一个 Offer 报文，告诉 PC2：

“我可以提供你这个 IP：192.168.0.1，还有网关是 192.168.0.254，DNS 是 192.168.0.253，要不要用？”

这个包可以是广播或单播，依赖模拟设置。

🟠 第三步：DHCP Request（请求）

PC2 收到 Offer 后，并不会马上使用这个地址，而是发送另一个广播包，向整个网络确认：

“我决定使用刚刚提供的 192.168.0.1，请你们都记住这个地址是我要用的。”

这是为了防止多个 DHCP 服务器响应时产生冲突（虽然我们这里只有一个 Server1）。

🔵 第四步：DHCP ACK（确认）

DHCP 服务器最后发出 ACK 报文，正式分配该 IP，并记录下 PC2 的 MAC 地址和分配的 IP，在租期内保留给它。

“确认成功，你现在可以使用 192.168.0.1 上网了。”

📬 最终，PC2 拿到的完整网络配置信息包括：

  • IP 地址：由 DHCP 服务器分配，例如 192.168.0.1
  • 子网掩码：255.255.255.0
  • 默认网关：192.168.0.254（Router1）
  • DNS 服务器：192.168.0.253（Server2）

image-20250420184302100

🌐 DNS 服务

🔍 DNS 是什么？

我们日常使用网络时，几乎所有的访问行为都是通过“域名”来完成的：

  • 打开网页时输入的是 www.baidu.com，而不是 180.101.49.11
  • 登录邮箱、使用 App、访问云服务，也都是靠“域名”连接的

但是网络通信的底层是基于 IP 地址 的，设备之间只有在知道彼此 IP 的前提下，才能建立连接。那么问题来了：

🧠 人类记得住域名，但网络只认 IP 地址，我们该怎么办？

这时候，DNS 就登场了！DNS 是一种“分布式的命名系统”，用于在“域名”和“IP地址”之间进行映射。它是互联网的基础服务之一，类似于：

“网络世界的电话簿”，帮助你把名字查成号码。

可以把它类比为：

类比对象 DNS 中的角色
手机联系人 域名（比如 www.example.com）
电话号码 IP 地址（比如 192.168.1.1）
通讯录查询 DNS 查询

🧩 DNS 的基本流程：

当我们在浏览器输入一个网址，比如 www.dhcpstest.com 时：

  1. 浏览器首先查找系统是否已经知道该域名的 IP（本地缓存、HOSTS 文件）
  2. 如果没有，系统就向配置好的 DNS 服务器 发出查询请求
  3. DNS 服务器返回该域名对应的 IP 地址
  4. 浏览器再用这个 IP 地址去访问对应的服务器，获取网页内容

整个过程通常在 几十毫秒之内完成，用户几乎无感知。

⚙️ DNS 服务器配置

image-20250420170755346

在我们的 Packet Tracer 实验中：

  • DNS 服务器（Server2）的 IP 是：192.168.0.253
  • 我们在其中配置了一个解析记录：
    • 域名：www.dhcpstest.com
    • 对应 IP：192.168.1.1（也就是 Web 服务器 Server0）
  • 客户端 PC2 在通过 DHCP 获取配置时，也得到了这个 DNS 地址
  • 后续当 PC2 想访问 www.dhcpstest.com 时，会先向 Server2 发出 DNS 查询请求，得到 IP 后再访问 Web 服务

🛣 访问流程演示

dns

现在，PC2 已经通过 DHCP 自动获取了以下配置：

  • IP 地址：192.168.0.1
  • 子网掩码：255.255.255.0
  • 默认网关：192.168.0.254（Router1）
  • DNS 服务器：192.168.0.253（Server2）

此时，PC2 想访问 Web 网站 www.dhcpstest.com，它会经历以下完整流程：

✅ 第一步：DNS 查询请求

PC2 并不知道 www.dhcpstest.com 是谁，它只知道要访问这个域名。因此，它会向自己配置的 DNS 服务器（Server2）发起一个 DNS 查询请求：

1
我想知道：www.dhcpstest.com 对应的 IP 地址是多少？

这是一条使用 UDP 协议（端口 53） 发送的请求。

✅ 第二步：DNS 服务器响应

Server2 收到请求后，在它的记录中找到一条 A 记录（IPv4）：

1
www.dhcpstest.com → 192.168.1.1

于是它把这个结果返回给 PC2。到此，域名解析完成，PC2 已经知道要访问的 Web 服务器的 IP 地址了。

✅ 第三步：PC2 发送 HTTP 请求

PC2 发现目标 IP（192.168.1.1）不在自己的子网（192.168.0.x），因此它将 HTTP 请求转发给默认网关（Router1）处理。

  • 路由器根据路由表将数据从 192.168.0.10 发送到 192.168.1.1
  • 报文经过交换机 → 路由器 → 另一个接口进入目标网段

✅ 第四步：Web 服务器响应请求

Web 服务器 Server0 收到来自 PC2 的请求后，会返回网页内容（HTML、图片等），通过原路回传给 PC2，完成网页访问流程。

📦 总结这个访问过程：

步骤 发起者 目标 内容/作用
DNS 请求 PC2 DNS 服务器 请求解析域名对应的 IP 地址
DNS 响应 DNS PC2 返回 www.dhcpstest.com → 192.168.1.1
HTTP 请求 PC2 Web 服务器 请求网页内容
HTTP 响应 Web PC2 返回网页数据

💡 这里不展示三次握手等 TCP 建连过程，仅聚焦 DNS 与应用层访问流程。

❓ 我们生活中的网络现象，背后藏着哪些 DHCP 和 DNS 原理？

通过前面对 DHCP 和 DNS 原理的理解，我们已经搭建起一个小型网络，模拟了一台 PC 自动获取 IP 并访问一个域名的全过程。那么在现实生活中，我们也经常会遇到一些网络相关的问题和操作，它们其实都能用这两个协议背后的机制来解释。

📌 1. 为什么在搭建局域网时，需要手动分配 IP？

在我们自己搭建一个小型局域网时，比如用一台交换机把几台设备或电脑连接起来，这种网络结构是非常常见的：

  • 多用于设备调试、内网联机、物联网测试
  • 没有路由器、也没有外网，网络中不存在 DHCP 服务器

✅ 原因分析：

在这样的网络结构中，没有任何设备负责动态分配 IP 地址，所以每台主机如果都设置为 “自动获取 IP（DHCP）”，它们就会：

  • 无法获取有效 IP（通常会自动分配 169.254.x.x 这种“私有保命地址”）
  • 彼此之间无法通信，无法构成真正的局域网

这时候我们就必须 手动设置每台设备的 IP 地址，确保：

  • 所有设备在 同一个网段（如 192.168.1.x）
  • 子网掩码一致（通常是 255.255.255.0）
  • IP 地址不重复（否则会冲突）

🧱 举个例子：

如果你用交换机连接了 3 台电脑（或工控设备）：

  • 电脑A：192.168.1.10
  • 电脑B：192.168.1.11
  • 电脑C：192.168.1.12

这时候他们就能正常通信，比如用 ping 测试，或者共享文件、传感器数据等。

🔌 为什么不自动获取？

因为 DHCP 是一个网络服务，必须有“服务器”端来提供，而交换机本身不具备 DHCP 功能（除非是带管理功能的三层交换机），普通局域网中必须靠手动设置。

📌 2. 为什么有时候我们能打开微信、QQ，却打不开网页？

相信很多人都遇到过这样的情况：

Wi-Fi 是连接着的，QQ、微信能正常聊天，但打开浏览器访问网页却提示“无法访问网站”或“DNS 服务器未响应”。

✅ 背后原因：很可能是 DNS 配置有误 或 DNS 服务器无法访问

  • 浏览器访问网站时，必须通过 DNS 将域名（如 www.baidu.com）解析成 IP 地址。
  • 如果 DNS 没配置好、服务器宕机、被防火墙拦截，浏览器就无法获得 IP，自然打不开网页。
  • 但微信、QQ 等应用可能内置了 IP 地址列表、或使用自己的 DNS 解析通道（如 DoH、HTTPDNS），所以它们不依赖操作系统配置的 DNS，也就不会受影响。

✅ 如何验证：

你可以在命令行中使用以下命令判断是否 DNS 故障：

1
2
3
ping www.baidu.com       # 如果失败，提示“找不到主机”，说明 DNS 问题
ping 180.101.49.11       # 百度的某个真实 IP，如果通了，说明网络本身没问题
nslookup www.baidu.com   # 检查 DNS 是否能正常解析域名

📌 3. 为什么在个人建站时，需要分别购买 服务器 和 域名？

很多初学者会有这样的疑问：

明明我已经买了服务器，为什么还要另外买个域名？而且两边还要“绑定”，这是什么操作？

✅ 原因解析：

  • 服务器 提供网站的内容和服务，比如网页文件、数据库、API。
  • 域名 是为了让人方便记住服务器地址，本质上是一个“别名”。
  • 全世界并没有“自动知道”你的域名对应哪个服务器，必须通过 DNS 系统去“登记和解析”。
  • 实际上，域名和服务器是完全分离的两个概念，域名的解析过程完全由 DNS 系统控制，和 Web 服务器本身并没有直接关系。

✅ 建站的典型流程：

  1. 购买服务器 我们可能在阿里云、腾讯云、Vultr、AWS 等平台上买了一台云服务器，开通之后你会拿到一个公网 IP（比如 123.456.78.90）

  2. 购买域名 在阿里云、Namecheap、GoDaddy 等域名服务商那里购买一个好记的域名，比如 mycoolsite.com

  3. 域名解析配置 在域名服务商后台添加一条记录，将 www.mycoolsite.com 指向你的服务器公网 IP

  4. 等待解析生效 + 测试访问 等 DNS 生效后，在任何浏览器输入 www.mycoolsite.com，DNS 系统就会帮你把这个名字翻译成服务器 IP 地址，然后通过 HTTP 访问你的网站。

🧠 总结

通过本篇博客，我们从零搭建了一个完整的网络实验环境，深入理解了 DHCP 与 DNS 两项网络服务在实际通信中的作用。我们不仅：

  • 学习了 DHCP 如何动态分配 IP、网关、DNS 等配置信息；
  • 观察了 DNS 如何将一个人类可读的域名，转化为设备可识别的 IP；
  • 更通过对日常网络现象的解析，把抽象的协议和真实世界联系起来；

网络从来不只是电缆与信号，它是秩序、协作和规则的集合。而 DHCP 与 DNS，正是这个秩序中最早向新设备伸出的那双手。