一、实验目的

了解动态主机配置协议DHCP的作用。
掌握在服务器上配置DHCP的方法。
观察DHCP的基本工作过程。

二、实验步骤

1. 构建网络拓扑

在本步骤中，我们将利用 Cisco Packet Tracer 搭建起本次实验所需的完整物理链路。为了保证后续 DHCP 抓包实验数据的绝对严谨性，请在连线时严格对齐硬件接口。

拓扑设备选型

请在 Packet Tracer 左下角的设备组件区选择并拖入以下网络设备：

  • 路由器（Router）：选择 1941 型号路由器一台，命名为 Router0（路由器0）。

  • 交换机（Switch）：选择 2960 型号 24 口二层交换机两台，分别命名为 Switch0（交换机0）和 Switch1（交换机1）。

  • 终端设备（End Devices）：

    • 左侧局域网（DHCP 服务区）：拖入两台 PC（PC0、PC1）以及一台服务器（Server0）。

    • 右侧局域网（静态隔离对比区）：拖入两台 PC（PC2、PC3）。

物理介质连线规划

我们统一选择 铜缆直通线（Copper Straight-Through） 进行物理连接。请务必按照以下确定的接口进行精准连线：

起始设备与接口 终止设备与接口 链路所属区域与作用
Server0 FastEthernet0 Switch0 FastEthernet0/1 左侧：DHCP 服务器接入端口
PC1 FastEthernet0 Switch0 FastEthernet0/2 左侧：旁观终端 1 接入端口
PC0 FastEthernet0 Switch0 FastEthernet0/3 左侧：目标请求终端 接入端口
Router0 GigabitEthernet0/0 Switch0 FastEthernet0/4 左侧：VLAN内网关互联链路
Router0 GigabitEthernet0/1 Switch1 FastEthernet0/1 右侧：网关延伸至右侧交换机链路
PC2 FastEthernet0 Switch1 FastEthernet0/2 右侧：静态终端 2 接入端口
PC3 FastEthernet0 Switch1 FastEthernet0/3 右侧：静态终端 3 接入端口

避坑指南：人为加速生成树收敛进程

当用直通线将设备连接到交换机时，你会发现交换机端的指示灯呈现闪烁的琥珀色（黄色），此时接口处于阻塞状态，无法传输任何数据。这是因为二层交换机默认开启了生成树协议（STP）进行防环路检测，整个收敛过程需要消耗大约 30 秒的时间。

高效操作：在实验中为了不盲目等待，我们可以点击 Packet Tracer 左下角物理/模拟切换栏上方的 “加速（Fast Forward Time）” 按钮（快捷键 Alt + D）连续点击数次，即可强行使生成树协议跃过等待期，让所有琥珀色指示灯瞬间变成绿色，链路进入转发状态。

2. 查看并标注路由器相关接口名称（接口号）

Packet Tracer 默认的接口标签显示功能并不完美。当拓扑中的线缆变多时，系统自动弹出的接口名称往往会相互重叠，遮挡住链路状态指示灯、传输媒体甚至设备本身，使得整个网络拓扑的信息看起来极其凌乱，非常不利于工程文档的阅读。

为了保持拓扑图的整洁与专业，推荐使用以下“先看、后注、再隐藏”的工程规范进行接口标注：

规范操作三步法

  • 第一步：开启全局接口显示（临时查看）

    点击菜单栏的 Options → Preferences，在弹出的窗口中勾选 Always Show Port Labels in Logical Workspace。此时，拓扑图中所有的接口编号（如 Fa0/1、Gig0/0 等）都会强行显示出来。

  • 第二步：使用注释工具人工标注（精准锁定）

    按下快捷键 N 或点击右侧工具栏的 Place Note（添加注释工具）。在 Router0 连接左侧交换机的线缆旁点击，手动输入文字：Gig0/0；在连接右侧交换机的线缆旁手动输入：Gig0/1。同理，将交换机侧的关键活跃端口（Fa0/1、Fa0/3、Fa0/4 等）也以注释形式漂亮地贴在线缆旁边。

  • 第三步：关闭全局接口显示（还原本质）

    再次回到 Options → Preferences 窗口，取消勾选 Always Show Port Labels in Logical Workspace。

此时，系统自带的杂乱标签全部隐去，拓扑图上只留下了你刚刚亲手标注的、大小适中且绝不遮挡视线的接口注释信息。这种清晰的拓扑管理习惯，能让你在后续切换到 Simulation 模式进行微观解封装分析时，一眼就能锁定制定的物理接口，不再看错行。

3. 标注 IP 地址、子网掩码以及默认网关的 IP 地址

在进行具体的网络设备配置之前，在拓扑图上清晰地标注出各网段、接口以及终端的 IP 地址规划，是网络工程中极其优秀的行业规范。这相当于在动工前先画好一张无误的“施工图纸”，能有效避免后续配置时因频繁看错地址而导致实验失败。

建议使用右侧工具栏的 Place Note（添加注释工具，快捷键 N），在拓扑图的对应位置贴上以下网络参数的字面标注：

全网网络参数规划蓝图

  • 左侧子网（DHCP 动态服务区）：

    • 网段网络号：192.168.0.0/24

    • 路由器网关接口 Gig0/0：192.168.0.254 / 255.255.255.0

    • DHCP 服务器 Server0（静态配置）：192.168.0.252 / 255.255.255.0，网关：192.168.0.254

    • 终端 PC0、PC1：无需预先标注固定 IP，可标注“DHCP 动态获取”。

  • 右侧子网（静态隔离对比区）：

    • 网段网络号：192.168.1.0/24

    • 路由器网关接口 Gig0/1：192.168.1.254 / 255.255.255.0

    • 终端 PC2（静态配置）：192.168.1.1 / 255.255.255.0，网关：192.168.1.254

    • 终端 PC3（静态配置）：192.168.1.2 / 255.255.255.0，网关：192.168.1.254

4. 配置 IP 地址、子网掩码以及默认网关的 IP 地址

本步骤分为两部分：首先通过图形界面（GUI）为网络中所有需要固定身份的静态终端与服务器输入 IP 参数，随后通过命令行（CLI）集中激活并配置核心路由器 Router0 的双侧网关接口。

Part 1：配置静态终端与服务器的 IP 参数

为了让网络的基础通信环境正常运转，我们首先需要为 Server0、PC2、PC3 手工写入静态网络参数。

以服务器 Server0 为例：

点击拓扑图中的 Server0 图标，在弹出的窗口中选择 Desktop（桌面） 选项卡。点击第一项 IP Configuration（IP 配置）。勾选 Static（静态） 模式，并严格填入以下参数：IP Address: 192.168.0.252；Subnet Mask: 255.255.255.0；Default Gateway: 192.168.0.254（预留给左侧路由器的网关接口 IP）。配置完毕后直接点击右上角 X 号关闭面板，系统会自动保存。

同理，请按照相同步骤点击右侧局域网的 PC2 和 PC3，为它们手工配置好静态 IP 地址：

  • PC2: IP 192.168.1.1 / 掩码 255.255.255.0 / 网关 192.168.1.254

  • PC3: IP 192.168.1.2 / 掩码 255.255.255.0 / 网关 192.168.1.254

特别说明：在本阶段，左侧的 PC0 和 PC1 故意完全不进行任何手工 IP 配置（保持默认的空状态）。我们正是要通过接下来的 DHCP 服务配置，让它们从盲目的 0.0.0.0 状态自动、动态地获取到合法的网络身份。

Part 2：利用 CLI 命令行配置路由器接口

终端的静态身份确立后，我们来到网络的中枢设备。点击拓扑图中的 Router0，切换到 CLI 选项卡。如果屏幕上出现初始化询问提示 Would you like to enter the initial configuration dialog? [yes/no]:，输入 no 并回车，随后连续按回车进入用户执行模式。

请严格依次输入以下配置命令，统一激活网关：

Router> enable                                      // 从用户模式进入特权执行模式
Router# configure terminal                          // 从特权执行模式进入全局配置模式

! --- 配置连接左侧子网（192.168.0.0/24）的接口 ---
Router(config)# interface GigabitEthernet0/0        // 进入 GigabitEthernet 0/0 接口配置模式
Router(config-if)# ip address 192.168.0.254 255.255.255.0  // 为该接口配置 IP 地址和子网掩码（作为左侧网关）
Router(config-if)# no shutdown                      // 激活/开启该物理接口（红灯变绿灯）

! --- 配置连接右侧子网（192.168.1.0/24）的接口 ---
Router(config-if)# interface GigabitEthernet0/1     // 直接切换到 GigabitEthernet 0/1 接口配置模式
Router(config-if)# ip address 192.168.1.254 255.255.255.0  // 为该接口配置 IP 地址和子网掩码（作为右侧网关）
Router(config-if)# no shutdown                      // 激活/开启该物理接口（红灯变绿灯）

! --- 退出 ---
Router(config-if)# exit                             // 退出接口配置模式，回到全局配置模式
Router(config)# exit                                // 退出全局配置模式，回到特权执行模式

避坑指南：观察“红变绿”的物理跃变

Cisco 路由器的物理接口默认处于管理性关闭状态，表现为拓扑图上的指示灯为红色。当你敲入 no shutdown 并回车的那一瞬间，拓扑图上路由器分别通往左右两侧交换机的物理指示灯会瞬间由红变绿。如果指示灯没有变绿，请立刻检查连线时是否插错了路由器的接口。

5. 在服务器上配置 DHCP 服务

为了让左侧子网的 PC0 和 PC1 能够动态获取网络参数，我们接下来在核心服务器 Server0 上配置并开启 DHCP 服务。

请点击拓扑图中的 Server0 图标，并在弹出的设备面板中，严格对照顺序（红字 1~10）进行无误配置：

DHCP 服务可视化配置十步法

  • 【1】 点击进入顶部的 服务（Services） 选项卡。

  • 【2】 在左侧的服务列表中，精准点击进入 DHCP 服务配置面板。

  • 【3】 地址池名称（Pool Name）：保持默认的 serverPool 不变。

  • 【4】 起始 IP 地址（Start IP Address）：严格输入 192.168.0.1（这是给客户端准备分配的第一个合法主机 IP）。

  • 【5】 子网掩码（Subnet Mask）：输入 255.255.255.0。

  • 【6】 最大用户数（Maximum number of Users）：手动修改为 250（代表此地址池最多允许 250 台客户端同时租用地址）。

  • 【7】 默认网关（Default Gateway）：输入 192.168.0.254（即左侧核心路由器的 Gig0/0 接口 IP，作为本网段数据跨网段流转的中枢出口）。

  • 【8】 DNS 服务器（DNS Server）：严格输入 192.168.0.253。

  • 【9】 以上参数确认无误后，点击下方的 保存（Save） 按钮，将上述配置刷入下方的地址池数据库表格中。

  • 【10】 最后，在服务状态（Service）一栏，勾选 开启（On） 状态单选框，正式点亮局域网内的 DHCP 动态寻址配置服务。

关于 DNS 参数 192.168.0.253

 请看，我们在地址池中配置的 DNS 服务器 IP 是 192.168.0.253。虽然我们目前的物理拓扑图里并没有真正连接这台 .253 的域名服务器设备，但在这里填写的宏观目的，是为了向大家展示 DHCP 协议强大的多参数打包携带能力。 当后面的客户端网卡被唤醒时，DHCP 服务器发出的确认信中，不仅会包含 IP 和掩码，还会把这个预设的 DNS 服务器参数 当作‘大礼包’一并塞给客户端，为终端设备未来跨网段进行域名解析提前做好了配置铺垫。

6. 配置相关计算机通过 DHCP 自动获取网络配置参数

当服务端的“发证池”蓄水完毕后，我们便可以切换回客户端，见证动态获取网络参数的自动化瞬间。下面以计算机 PC0 为例进行完全配置：

切换与激活步骤

首先确保 Packet Tracer 处于左下角的 Realtime（实时工作模式）。点击进入 PC0 的设备面板，切换到 Desktop（桌面）→ IP Configuration（IP 配置）。在 IP 获取配置中，将原本默认的 Static（静态） 单选框，切换勾选为 DHCP。此时，网卡会短暂闪烁一行提示 Requesting IP Address...（正在请求IP地址），仅仅 1~2 秒后，屏幕上就会弹出一行令人振奋的 DHCP request successful（DHCP 请求成功）字样！

此时，原本空白的文本框已被系统自动填满

  • IP Address: 192.168.0.1（地址池里吐出的第一个可用地址）

  • Subnet Mask: 255.255.255.0

  • Default Gateway: 192.168.0.254

  • DNS Server: 192.168.0.253

同理，请点击打开 PC1，执行完全相同的切换操作。可以观察到，PC1 同样获取成功，且拿到了地址池顺延配置的第二个合法 IP：192.168.0.2。

拓扑成果工程标注

完成上述动态获取后，为了使工程图纸实时对齐，请按下快捷键 N 切换到 Place Note（添加注释工具），将 PC0 最终获取到的 192.168.0.1 和 PC1 获取到的 192.168.0.2 分别作为字面注释，清爽地标注在两台计算机的图标下方。

至此，基础网络参数的动态部署全部闭环，全网设备已拥有了在各自网段内合法合规的 IP 身份！

7. 选择要监视的网络协议

为了在后续的模拟分析中能够“精准狙击”并看清 DHCP 报文的每一个微观交互瞬间，我们需要提前对过滤器进行净化配置。

默认情况下，Packet Tracer 会捕获网络中所有的流量（如 STP、ARP、Cisco 发现协议 CDP 等），这会导致仿真事件列表中充斥着大量冗余信封，极大地干扰我们的观察。

过滤器精细化配置步骤

确保软件右下角已从 Realtime（实时工作模式） 切换至 Simulation（模拟工作模式）。在右下角控制面板中，点击 Show All/None 按钮，将当前所有默认勾选的监视协议全部清空（此时控制面板中应无任何协议显示）。点击 Edit Filters（编辑过滤器） 按钮，在弹出的协议选择面板中，切换到 IPv4 选项卡，精准勾选 DHCP 协议，随后关闭配置小窗口。

为什么要净化过滤器？

净化过滤器的核心目的在于“排除噪声，聚焦本质”。

此时，Packet Tracer 的事件列表中将只会捕获和呈现 DHCP 协议相关的分组。网络中客观存在的其他背景流量（如交换机 STP 报文）虽然仍在后台传输，但其信封会被软件强行隐去。这能让我们在接下来的抓包分析中，心无旁骛地死磕 DHCP 的状态机演变。

8. 网络连通性测试

在正式进入微观抓包之前，我们需要切回实时模式，进行一次全网的“大点兵”——双向连通性测试。这一步是检验我们前面所有静态配置与动态获取成果的终极试金石。

测试操作方法

切换回左下角的 Realtime（实时工作模式）。点击进入 PC0 的设备面板，切换到 Desktop → Command Prompt（命令行提示符）。输入命令 ping 192.168.1.1（测试左侧动态主机 PC0 与右侧静态主机 PC2 之间的跨网段连通性）并回车。同样地，打开 PC1 的命令行提示符，输入命令 ping 192.168.1.2（测试 PC1 与 PC3 之间的连通性）并回车。

双向 Ping 测试的五大宏观目的

如果终端屏幕上成功出现了 Reply from...（收到来自对端的响应）字样，说明全网已经彻底打通。这次成功的测试在后台同时验证了以下五大核心要素：

  • 一、物理拓扑完整性：证实了全网的硬件连线、网线选型以及交换机、路由器的物理链路构建 100% 成功。

  • 二、右侧静态配置正确性：证实了右侧子网中 PC2、PC3 各自手工输入的 IP 地址、子网掩码、以及默认网关（192.168.1.254）无任何输入笔误。

  • 三、网关中枢路由合规性：证实了核心路由器 Router0 的双侧物理接口（Gig0/0 与 Gig0/1）的 IP 地址以及三层路由转发逻辑完全正常运转。

  • 四、服务端 DHCP 部署成功：证实了服务器 Server0 上的 DHCP 服务本身参数配置无误，且服务已正常“点亮”。

  • 五、客户端动态获取闭环：证实了 PC0 和 PC1 已经确确实实从 Server0 处自动拿到了合法、匹配、且能正常用于跨网段通信的 IP 地址及网关参数。

如果测试失败，请检查网络拓扑、计算机 PC2、PC3、服务器 Server0 各自的 IP 地址、子网掩码以及默认网关的 IP 地址配置、路由器 Router0 各相关接口的 IP 地址和子网掩码配置、Server0 上的 DHCP 服务配置是否正确，还要检查 PC0 和 PC1 各自是否成功通过DHCP从DHCP服务器 Server0 自动获取到了 IP 地址等网络配置参数。

如果你的 Ping 测试亮起了“Request timed out（超时）”，请立刻进行以下五步排查：
1. 查终端网卡状态：检查 PC0 和 PC1 是否真的成功切换为了 DHCP 模式？如果 IP 地址一直停留在 Requesting IP Address...（正在请求），或者获取超时最终拿到了 169.254.x.x（APIPA 私有地址），均说明 DHCP 根本没有获取成功。
2. 查服务器地址池：打开 Server0 的 DHCP 服务面板，检查 Default Gateway 是否错填成了服务器自己的 IP？正确的应该是网关 192.168.0.254。
3. 查路由器 no shutdown：去路由器的 CLI 界面看一看，两个 GigabitEthernet 接口是否都成功敲入了 no shutdown？拓扑线缆上的指示灯是否全部为绿色？
4. 查右侧静态网关：检查右侧静态主机 PC2 和 PC3 的网关一栏，是否正确填写了 192.168.1.254？漏填或错填网关会导致回包无法跨越路由器。
5. 人为加速收敛：是否忘记点击 Fast Forward Time（加速）按钮？如果交换机接口仍处于琥珀色生成树阻塞状态，数据包会在物理层被直接丢弃。

三、观察 DHCP 的基本工作过程

为了完整、精准地捕获到 DHCP 交互协议的每一个微观底层瞬间，我们首先需要在 Packet Tracer 中重置网络客户端的协议状态。

【前置准备状态：精准触发 DHCP 进程】

请严格按照以下步骤，在仿真环境中“重置并唤醒” PC0 的 DHCP 客户端服务：

  1. 清理当前状态（实时工作模式）：确保模拟器处于左下角的 Realtime（实时工作模式）。打开 PC0 的 IP 配置面板，将 IP 地址获取方式从 DHCP 手动切换回 Static（静态）。此操作将彻底清空 PC0 现有的网络参数，强制关闭并复位本地的 DHCP 状态机进程。

  2. 切换抓包环境（模拟工作模式）：在软件右下角切换到 Simulation（模拟工作模式）。此时应确保已按照步骤七的操作，在过滤器中仅勾选了 DHCP 协议。

  3. 唤醒服务并触发动作：再次打开 PC0 的 IP 配置面板，重新勾选 DHCP 选项。此时，PC0 操作系统内部的 DHCP 客户端进程正式被唤醒，并开始在后台构建寻址报文。

  4. 单步捕获信封：点击模拟控制面板上的 Capture/Forward（捕获/前进） 按钮。此时，拓扑图中 PC0 的网卡缓冲区上会立刻生成第一个待发送的数据包（淡黄色信封），正式拉开 DHCP “DORA” 拓扑交互的序幕。

DHCP 动态获取 IP 完整过程：宏观与微观的映射

第一阶段：DISCOVER —— 寻址 DHCP 服务器 (寻找阶段)

宏观目标：客户端在网络中“大喊”，寻找谁能给自己分配一个 IP 地址。

步骤一：PC0 产生并封装出 Discover 包

此时，PC0 的网卡刚启动或重新请求 IP，在 OSI 模型中，数据从第 7 层开始产生，并以自顶向下的顺序进行协议控制信息（PCI）的封装。

第 7 层：应用层（DHCP Application Layer）

  • Packet 内容：服务器: 0.0.0.0，客户端: 0.0.0.0

  • 为什么进行这一步： PC0 的 DHCP 客户端进程启动，构建初始的 DHCP Discover（发现报文）。由于此时 PC0 根本不知道网络中 DHCP 服务器的合法 IP，自己也没有分配到 IP，因此报文内部的客户端 IP（Ciaddr）和服务器 IP（Siaddr）字段全部填充为 0.0.0.0。这表明请求是盲目的、初始化状态的，需要向外寻求“谁能给我一个地址”。

第 4 层：运输层（Transport Layer）

  • Packet 内容：UDP 源端口: 68，目的端口: 67

  • 为什么进行这一步： 应用层的 DHCP 核心数据下传到运输层，由于无连接、低开销的广播需求，设备选择 UDP 协议 进行封装。

    • 源端口 68：代表这是由 DHCP 客户端（Client）发出的流量。

    • 目的端口 67：指定该数据必须交给远端目的设备的 DHCP 服务端（Server）进程来处理。

第 3 层：网际层（Network Layer）

  • Packet 内容：IP报头 源IP: 0.0.0.0，目的IP: 255.255.255.255

  • Packet 提示解析：

    1. 该端口没有IP地址：设备由于未被分配地址，网际层只能将源 IP 设为全局未知地址 0.0.0.0。

    2. 该数据包的有效载荷是一个DHCP UDP分段：接收上层传下来的 UDP 核心数据。

    3. 目的IP地址位于同一子网中...将目的IP设置为下一跳：因为不知道服务器在哪，干脆直接将目的 IP 锁定为全 1 的受限广播地址 255.255.255.255，意图让同子网内的所有设备都收到这个 IP 数据报。

第 2 层：数据链路层（Data Link Layer）

  • Packet 内容：Ethernet II报头 00E0.8F0A.5228 >> FFFF.FFFF.FFFF

  • Packet 提示解析：

    1. 下一跳IP地址为广播地址...将帧的目的MAC地址设置为广播MAC地址：网卡检查到上层（第 3 层）的目的 IP 是广播地址 255.255.255.255。在局域网内，网际层广播必须映射为链路层的硬广播，因此不需要触发 ARP 请求，直接将目的 MAC 地址填入全 F 的 FFFF.FFFF.FFFF。

    2. 源 MAC 地址 00E0.8F0A.5228：这是 PC0 网卡的物理烧录地址（Burned-In Address），用来标识这个广播是谁放出来的。

    3. 该设备将PDU封装成以太网帧：最终将其打包成标准的 Ethernet II 帧格式。

第 1 层：物理层（Physical Layer）

  • Packet 内容：(端口): FastEthernet0

  • 为什么进行这一步： 数据链路层封装完毕后的二进制比特流（Bitstream），已经送达 PC0 的百兆以太网物理接口 FastEthernet0 的缓冲区，准备转换为电信号通过双绞线发射出去。

步骤二：交换机（Switch0）接收并决定执行二层泛洪

当 PC0 发出的 DHCP Discover 广播帧顺着网线到达交换机 FastEthernet0/3 接口时，交换机开始在底层默默处理这个数据包。

入站处理：第 1 层与第 2 层（In Layers）

  • 第 1 层（物理层）：交换机的 FastEthernet0/3 接口接收到来自双绞线的物理电信号，并将其还原为二进制比特流。

  • 第 2 层（数据链路层）：

    • Packet 内容：Ethernet II报头 00E0.8F0A.5228 >> FFFF.FFFF.FFFF

    • Packet 提示解析：

      1. “在交换机的MAC表中找到帧的源MAC地址。”：交换机读取到源 MAC 地址 00E0.8F0A.5228（即 PC0 的 MAC），并将其与接收接口 Fa0/3 绑定，写入或刷新自己的 MAC 地址表。这完美体现了交换机的“源地址学习”功能。

      2. “该帧的目的MAC地址是广播。交换机对该帧进行处理。”：交换机提取出目的 MAC 地址，发现是全 F 的广播地址 FFFF.FFFF.FFFF，判定这是一个必须被全网听到的特殊帧。

      3. “该帧的目的MAC地址与接收端口的MAC地址、广播地址或一个多播地址相匹配。”：交换机的底层接收逻辑确认此广播帧是合法的，满足被接收并进一步处理的条件。

      4. “该设备将PDU从以太网帧解封装。”：交换机确认完毕，准备触发下一步的广播泛洪（Flooding）机制。

拓展说明： 在整个入站过程中，我们可以明显看到 第 3 层（网际层）及以上是完全置灰/空白的。这是因为普通的二层交换机只工作在 OSI 模型的第二层，它在转发时根本不关心、也没有能力去拆看里面的 IP 地址（0.0.0.0 或 255.255.255.255）以及 UDP 端口号。它只认第二层的 MAC 地址。

出站处理（Out Layers）—— 复制与全网泛洪

正因为目的 MAC 是广播，交换机立刻做出了它的经典决策——泛洪（Flooding）。我们在出站（Out Layers）面板中可以看到它具体的“分身”过程。

  • 第 2 层（数据链路层）： 交换机没有对原始帧的任何内容做出篡改，源 MAC 依然是 PC0，目的 MAC 依然是全 F 广播。

  • 第 1 层（物理层）：交换机在底层对该数据帧进行了高并发的“复印”，并精准排除了接收端口 FastEthernet0/3。

    • 出站端口挂载：交换机将复制好的广播帧，推送向该 VLAN 内除接收端口之外的所有活跃接口：FastEthernet0/1、FastEthernet0/2 和 FastEthernet0/4 同时发射出去。

总结交换机在这一步的作用：

交换机在此处充当了“物理范围放大器”和“二层中继者”。它通过识别二层广播 MAC（FFFF.FFFF.FFFF），确保了在同一个广播域内的 Server0 能够成功接收到来自 PC0 的 DHCP 寻址呼唤。

步骤三：Discover 广播泛洪落地，各终端设备接收处理

当这个目的 MAC 为 FFFF.FFFF.FFFF、目的 IP 为 255.255.255.255 的广播包到达网络中的各个终端时，所有设备都会接收该帧并尝试向上层解封装，但最终的命运取决于应用层的服务状态。

Router0 的处理过程（广播隔离）

虽然拓扑中显示数据包也发往了 Router0（路由器的 Gig0/0 接口），但默认情况下，路由器是隔离广播域的。 当路由器接口收到这个目的 MAC 为全 F、目的 IP 为 255.255.255.255 的广播帧时，它会接收并处理，但绝对不会将其跨网段转发到另外一个接口（Gig0/1）去。这也就是为什么右侧网段的 PC2 和 PC3 根本收不到这个寻址请求的原因。

Server0 的处理过程：成功接收并准备分配 IP

当广播包到达真正的 DHCP 服务器（Server0）时，解封装过程一路绿灯，顺利到达应用层。

  • 第 1 层到第 4 层：与 PC1 一样，Server0 逐层解封装。不同的是，到达第四层时，Server0 正在运行 DHCP 服务，并持续监听着 UDP 67 端口，因此数据被成功接收并传递给第七层。

  • 第 7 层：应用层

    • Packet 内容：DHCP Packet 服务器: 0.0.0.0，客户端: 0.0.0.0

    • Packet 提示解析：

      1. “该数据包是一个DHCP数据包。DHCP服务器对其进行处理。”

      2. “DHCP服务器接收到一个DHCP发现数据包。” （成功识别出这是 Discover 报文）。

      3. “DHCP服务器没有到此主机的现有绑定。它将在DHCP地址池中查找一个新的IP地址。” （服务器检查自己的数据库，确认之前没有给这台 MAC 地址为 00E0.8F0A.5228 的设备分配过 IP）。

      4. “DHCP服务器在地址池中发现下一个可用IP地址。”

    • 分析说明：服务器成功解析了客户端的寻址请求，并在自己的地址池（Pool）中挑选出了一个未被使用的合法 IP 地址（比如 192.168.0.1），为接下来的回复（DHCP Offer）做好了准备。

PC1 的处理过程：无服务，最终丢弃

当广播包到达同网段的其他普通计算机（如 PC1）时，我们可以看到数据包在第四层被丢弃。

  • 第 1 层到第 3 层：PC1 的网卡接收到电信号，数据链路层识别到目的 MAC 是广播地址，于是继续向网际层传递。网际层识别到目的 IP 也是广播地址，继续向运输层传递。

  • 第 4 层：运输层

    • Packet 内容：UDP 源端口: 68，目的端口: 67

    • Packet 提示解析：“在此端口上没有运行监听的服务。设备丢弃该分段。”

    • 分析说明：运输层看到了目标端口是 UDP 67。但是，PC1 是一台普通的客户机，它并没有开启 DHCP 服务端程序，因此本地没有任何进程在监听 67 端口。由于找不到对应的应用程序接收数据，PC1 只能将该数据包丢弃，解封装过程到此戛然而止。

第二阶段：OFFER —— 提供 IP 地址租用 (提议阶段)

宏观目标：DHCP 服务器听到呼唤后，从地址池中挑出一个可用 IP，向客户端发出“提议”。

步骤四：服务器（Server0）封装并发出 Offer 报文，交换机接收并决定泛洪

此时，Server0 已经构建好了包含预分配 IP 地址的 DHCP Offer 报文，并将其发送回交换机。我们从交换机的视角来看看它是如何处理这个回包的。

入站处理：从服务器接收（In Layers）

交换机首先从连接 Server0 的接口接收数据，并进行自底向上的初步解析。

  • 第 1 层：物理层（Physical Layer）

    • Packet 内容：端口 FastEthernet0/1

    • 解析：交换机的 Fa0/1 接口接收到了来自 Server0 的物理电信号，并将其转换为数据帧。

  • 第 2 层：数据链路层（Data Link Layer）

    • Packet 内容：Ethernet II报头 00D0.BCD5.2CD5 >> FFFF.FFFF.FFFF

    • Packet 提示解析：

      1. “在交换机的MAC表中找到帧的源MAC地址。”：交换机读取到源 MAC 地址 00D0.BCD5.2CD5（这是 Server0 的网卡地址），并将其与接收端口 Fa0/1 进行绑定，更新 MAC 地址表。这体现了交换机的“源地址学习”功能。

      2. “该帧的目的MAC地址是广播。交换机对该帧进行处理。”：交换机读取目的 MAC，发现依然是全 F 的广播地址 FFFF.FFFF.FFFF。

      3. “该帧的目的MAC地址与接收端口的MAC地址、广播地址或一个多播地址相匹配。” / “该设备将PDU从以太网帧解封装。”：因为是广播帧，交换机知道这个包需要被局域网内的所有设备听到，于是准备进行下一步的泛洪操作。

出站处理：交换机再次泛洪（Out Layers）

明确了这是一个广播帧后，交换机开始执行转发动作，将数据帧推向其他所有活跃接口。

  • 第 2 层：数据链路层（Data Link Layer）

    • Packet 内容：Ethernet II报头 00D0.BCD5.2CD5 >> FFFF.FFFF.FFFF

    • 解析：与之前一样，交换机作为二层透传设备，绝不会修改数据帧的源 MAC 和目的 MAC，直接原样复制。

    • Packet 提示解析：“这是一个广播帧。交换机将帧发送至同一VLAN内除接收端口之外的所有端口。” 这一句是二层交换机广播机制的核心定义。

  • 第 1 层：物理层（Physical Layer）

    • Packet 内容：(端口):FastEthernet0/2, FastEthernet0/3, FastEthernet0/4

    • 解析：交换机将复制好的数据帧，分别送往这三个接口的物理缓冲区，重新转换为电信号发送出去。这样，网络拓扑中的 PC0、PC1 以及 Router0 的对应接口都会收到这个 DHCP Offer 报文。

小结： 在这个步骤中，交换机再次完美履行了它的职责——学习源 MAC，泛洪广播帧。虽然这个 DHCP Offer 报文被广播给了同网段的所有设备，但由于报文应用层（DHCP 载荷）内部记录了最初发起请求的 PC0 的 MAC 地址（Client Hardware Address），所以接下来只有 PC0 会真正处理并接受这个 Offer，而 PC1 等其他设备在解封装后会将其忽略。

步骤五：Offer 广播泛洪落地，PC0 接收提议（PC1/路由器丢弃）

此时，交换机已经将包含 DHCP Offer（提供报文）的广播帧泛洪给了 PC0、PC1 和路由器。我们来看看终端是如何处理的：

目标主机 PC0 的处理：接收 Offer，构建 Request

真正等待这个回包的 PC0，不仅成功接收了报文，而且立刻开始构建第三步的交互：DHCP Request（请求报文）。

（1）入站处理（In Layers）—— 接收提供报文

  • 第 7 层：应用层

    • Packet 内容：DHCP Packet 服务器: 192.168.0.252, 客户端: 0.0.0.0

    • 实际数据：“DHCP客户端接收到一个DHCP提供数据包。”

    • 实际数据解析：此时 PC0 终于得知了局域网内有一台 DHCP 服务器，其 IP 地址是 192.168.0.252。但注意，此时“客户端”字段依然是 0.0.0.0，因为 PC0 只是收到了“提议”，还没有正式确认使用该 IP。

出站处理（Out Layers）—— 封装请求报文

紧接着，PC0 需要向服务器正式发送请求，索要刚才提供的那个 IP。我们来看它是如何自顶向下封装新的 PDU 的：

（1）第 7 层：应用层

  • 实际数据解析：“DHCP客户端接收到一个提供数据包，构建一个请求数据包并将其发送出去。” 这标志着 DORA 过程进入了第三阶段（Request）。

（2）第 4 层：运输层

  • Packet 内容：UDP 源端口: 68，目的端口: 67

  • 说明：依然是客户端（68）向服务端（67）发送请求。

（3）第 3 层：网际层

  • Packet 内容：IP报头 源IP: 0.0.0.0, 目的IP: 255.255.255.255

  • 实际数据：“目的IP地址位于同一子网中。该设备将目的IP地址设置为下一跳。”（即再次使用 255.255.255.255 广播）。“该数据包的有效载荷是一个DHCP UDP分段。设备将源地址设置为全零IP地址。”“该端口没有IP地址。”

  • 实际数据解析：为什么这里源 IP 还是 0.0.0.0，目的 IP 还是广播？因为 PC0 必须等到最后一步收到服务器的 ACK 确认后，才能真正将 IP 地址配置到自己的网卡上。在此之前，它依然是一个“没有合法 IP”的设备，所以只能再次通过广播发送 Request，顺便也告诉网络中可能存在的其他 DHCP 服务器：“我已经选定了 192.168.0.252 那台服务器提供的地址，你们可以把预留给我的地址收回了。”

（4）第 2 层：数据链路层

  • 实际数据解析：由于第三层决定继续使用广播 IP，所以第二层数据链路层理所当然地将目的 MAC 地址再次封装为全 F 的广播地址（FFFF.FFFF.FFFF），源 MAC 为 PC0 本机的物理地址。

旁观者 PC1 的处理：接收后在应用层丢弃

当这个 Offer 广播帧到达 PC1 时，解封装过程一路向上。因为 Offer 报文的运输层目的端口是 UDP 68（客户端端口），PC1 作为普通计算机，其系统内部正运行着 DHCP 客户端进程并持续监听该端口。 因此，数据顺利穿透 1 至 4 层，成功送达了 第七层（应用层）。PC1 的 DHCP 进程打开应用层载荷后，核对了里面的客户端硬件地址（Client MAC）与事务 ID，发现这笔由服务器（192.168.0.252）提供的 IP 提议是专门发给 PC0 的，与自己无关。基于网络协议栈的合规校验，PC1 的系统理智地将该数据包在应用层直接丢弃，不作任何回应。

（1）第 1-4 层（解封装顺利通过）： 与上一步完全丢弃 Discover 包不同，这次 PC1 的底层接收了该包。因为目的是广播 MAC 和广播 IP，且第四层目的端口是 UDP 68（PC1 作为普通电脑，其内部也运行着 DHCP 客户端进程，监听 68 端口），所以数据被成功送达了应用层

（2）第 7 层：应用层（In Layers）

  • Packet 内容：DHCP Packet 服务器: 192.168.0.252, 客户端: 0.0.0.0
  • 实际数据：“该DHCP数据包并非发往这台主机。主机将其丢弃。”“该数据包是一个DHCP数据包。DHCP客户端对其进行处理。”
  • 实际数据解析：PC1 的 DHCP 客户端进程打开了第七层的数据包，检查了里面的 DHCP 载荷（虽然截图中未详细展示载荷内部字段，但原理是它检查了客户端硬件地址 Client MAC 或事务 ID），发现这个 Offer 报文是服务器专门“提供”给 PC0 的，并不是给自己的，因此 PC1 的系统理智地将该数据包丢弃，不作回应。

第三阶段：REQUEST  —— 正式请求 IP 地址租约（选择/请求阶段）

宏观目标：客户端（PC0）正式向选中的服务器请求使用刚才提供的那个 IP，并顺便通知网络中的其他服务器“我已经名花有主了，请收回你们预留的地址”。

步骤六：PC0 发出 Request，交换机接收并决定再次泛洪

在上一步中，PC0 决定接受 Server0 提供的 IP 地址，并在本地构建了 DHCP Request 报文。现在，这个报文来到了交换机（Switch0）。

入站处理：查表与识别（In Layers）

交换机从连接 PC0 的接口接收到了数据帧，并进行二层解封装。

  • 第 1 层（物理层）：

    • Packet 内容：端口 FastEthernet0/3

    • 解析：交换机从连接 PC0 的 Fa0/3 接口接收到电信号并还原为数据帧。

  • 第 2 层（数据链路层）：

    • Packet 内容：Ethernet II报头 00E0.8F0A.5228 >> FFFF.FFFF.FFFF

    • 实际数据解析：

      1. “在交换机的MAC表中找到帧的源MAC地址。”：交换机读取到源 MAC 地址 00E0.8F0A.5228（PC0 的 MAC），并刷新其在 MAC 地址表中的老化时间。

      2. “该帧的目的MAC地址是广播... 该设备将PDU从以太网帧解封装。”：交换机发现目的 MAC 是全 F 的广播地址，确认为广播帧，准备向全网泛洪。

为什么第 3 层到第 7 层全是灰色的？ 请注意看截图，虽然这个报文内部装的是 DHCP Request（应用层数据），并且带着 0.0.0.0 和 255.255.255.255 的 IP 地址（网络层数据），但交换机的 PDU 显示里，第 3 层及以上全部置灰或空白！ 这是因为普通的二层交换机是“近视眼”，它只认识 MAC 地址。 它根本不关心、也没有能力去拆开网络层看里面的 IP 是什么。只要第 2 层的目的 MAC 告诉它是广播，它就只管闭着眼睛去复印分发。这完美体现了 OSI 模型中“下层为上层提供服务，且各层互不干涉”的设计哲学。

出站处理：原样复制与泛洪（Out Layers）

明确了这是一个广播帧后，交换机开始执行无条件的转发动作。

  • 第 2 层（数据链路层）：

    • Packet 内容：保持不变，依然是 00E0.8F0A.5228 >> FFFF.FFFF.FFFF。

    • 实际数据解析：“这是一个广播帧。交换机将帧发送至同一VLAN内除接收端口之外的所有端口。” 交换机绝不篡改数据帧头部，直接原样复制。

  • 第 1 层（物理层）：

    • Packet 内容：(端口): FastEthernet0/1, FastEthernet0/2, FastEthernet0/4

    • 解析：复印好的数据帧被分别送往这三个接口，转化为电信号。接下来，这个 Request 请求就会顺着网线，同时抵达网络中的 Server0、PC1 以及 Router0。

步骤七：Request 广播泛洪落地，服务器接收并准备 ACK

PC0 发出的 DHCP Request（请求报文）到达交换机后，再次被推向全网。

服务器（Server0）的接收与响应：绑定与确认

真正的目标 Server0 接收到请求后，完成了逻辑闭环，并开始构建最后一步的确认报文。

入站处理：正式绑定 IP 与 MAC

  • 第 4 层（运输层）：源端口 68，目的端口 67，匹配本地 DHCP 服务。

  • 第 7 层（应用层）：

    • 实际数据解析 1：“DHCP服务器接收到一个DHCP请求数据包。”（成功识别出 DHCP Request）。

    • 实际数据解析 2：“DHCP服务器将来自地址池的所请求的IP地址绑定到主机的MAC地址。”

    • 讲解要点：这是 DHCP 租约正式建立的时刻。服务器核对了 PC0 的请求，确认客户端请求的 IP 地址（例如 192.168.0.1，具体看地址池分配）有效，于是在自己的地址池数据库中，将该分配出去的 IP 与 PC0 的网卡物理地址（00E0.8F0A.5228）进行硬绑定，并记录租约期限。

出站处理：封装最终的 DHCP ACK

绑定完成后，Server0 需要向 PC0 发送最终的 DHCP ACK（确认报文）。我们来看看服务器的出站 PDU 封装：

  • 第 7 层（应用层）：封装 DHCP ACK 载荷。

  • 第 3 层（网际层）：源 IP 为服务器自己的 192.168.0.252，目的 IP 依然是受限广播地址 255.255.255.255。

  • 第 2 层（数据链路层）：

    • Packet 内容：Ethernet II报头 00D0.BCD5.2CD5 >> FFFF.FFFF.FFFF

    • 实际数据解析：“下一跳IP地址为广播地址... 该设备将PDU封装成以太网帧。”

    • 要点：这是一个非常容易被忽视的细节。为什么最后一步服务器的回包依然是广播？ 虽然从物理层面上，PC0 的网卡可以通过单播 MAC 接收数据，但在很多操作系统的 DHCP 实现中，客户端在网卡完全配置好 IP 之前，会在发出的 Request 报文中将 ‘Broadcast 标志位’置 1，明确要求服务器以广播形式回应。服务器遵从了该请求，采用全网广播发送 ACK，确保报文绝对送达。

路由器（Router0）的处理：接收但因配置不符而丢弃

从截图上看，数据包成功穿透了路由器的底层，甚至到达了应用层，但最终还是被丢弃了。

  • 第 1 层到第 4 层：顺利解封装。路由器的系统内通常也运行着 DHCP 服务进程（监听 UDP 67 端口），因此第四层顺利放行。

  • 第 7 层（应用层）：

    • 实际数据解析：“DHCP服务器没有为接收端口配置的地址池。它将数据包丢弃。”

    • 要点：“为什么路由器没有在底层丢弃报文？” 路由器本身具备充当 DHCP 服务器的能力。它打开了应用层载荷，但在检查自身配置时，发现 Gig0/0 接口并没有配置用于分配的 DHCP 地址池。既然无能为力，只能选择丢弃。

旁观终端 PC1 截然不同的命运（传输层拦截）

请特别注意！同样是旁观设备，在第二阶段 Offer 落地时，PC1 是在第七层丢弃的数据包；而在此处的第三阶段 Request 落地时，PC1 却在第四层（运输层）就亮起了红叉！

底层核心原理辨析： PC0 发出的 Request 请求，其运输层目的端口改为了 UDP 67（服务端端口）。PC1 是一台普通的客户机，本地网卡只运行着监听 UDP 68 的客户端程序，根本没有运行任何监听 67 端口的服务端进程。

当这个 Request 广播包到达 PC1 的传输层时，系统发现本地找不到任何对应的应用进程来接收这个 UDP 分段，解封装过程当场戛然而止，数据包在第四层被直接拦截并丢弃，根本连进入第七层看一眼的资格都没有！ 深刻理解这个端口与层级的跃变，是大家掌握网络体系结构的精髓所在。

第四阶段：ACK —— 确认 IP 地址租约 (确认阶段)

宏观目标：服务器最终敲定租约，将 IP 地址与客户端的 MAC 地址正式绑定，并通知客户端“你可以用了”。

步骤八：Server0 发出 ACK，交换机接收并决定最后一次泛洪

当带有最终配置信息的 DHCP ACK 数据帧从 Server0 抵达交换机时，交换机依然只工作在 OSI 模型的底层（第 1 层和第 2 层），它不需要、也无法拆开查看里面的 DHCP 载荷内容。

入站处理：接收并检查 MAC（In Layers）

交换机从连接 Server0 的物理接口读入数据，并进行二层处理。

  • 第 1 层：物理层

    • Packet 内容：端口 FastEthernet0/1

    • 解析：交换机从 Fa0/1 接口接收到了来自服务器的数据帧。

  • 第 2 层：数据链路层

    • Packet 内容：Ethernet II报头 00D0.BCD5.2CD5 >> FFFF.FFFF.FFFF

    • 实际数据解析：

      1. “在交换机的MAC表中找到帧的源MAC地址。”：交换机读取到源 MAC 地址 00D0.BCD5.2CD5（Server0 的 MAC），并重置或更新其在 MAC 地址表中的老化时间。

      2. “该帧的目的MAC地址是广播。交换机对该帧进行处理。”：交换机发现目的 MAC 依然是全 F 的广播地址。

      3. “该帧的目的MAC地址与接收端口的MAC地址、广播地址或一个多播地址相匹配。该设备将PDU从以太网帧解封装。”：确认这是一个需要向全网广播的数据帧，准备进入出站转发流程。

出站处理：最后一次泛洪转发（Out Layers）

交换机的转发逻辑非常纯粹：既然是广播帧，那就复制并发送给所有人。

  • 第 2 层：数据链路层

    • Packet 内容：Ethernet II报头 00D0.BCD5.2CD5 >> FFFF.FFFF.FFFF

    • 实际数据解析：“这是一个广播帧。交换机将帧发送至同一VLAN内除接收端口之外的所有端口。”

    • 课堂讲解要点：再次向学生强调，交换机在转发数据时，绝对不会篡改数据帧的源 MAC 和目的 MAC。它只是忠实地将这个来自服务器（00D0.BCD5.2CD5）的广播帧（FFFF.FFFF.FFFF）原样复制。

  • 第 1 层：物理层

    • Packet 内容：(端口): FastEthernet0/2, FastEthernet0/3, FastEthernet0/4

    • 解析：复制后的数据帧被分别送往这三个接口，转化为电信号发往网络中的 PC0、PC1 以及 Router0。

小结： 到这里，交换机的任务就圆满完成了。在整个 DHCP 交互的四个阶段（Discover, Offer, Request, ACK）中，无论报文的业务逻辑有多复杂，只要目的 MAC 是 FFFF.FFFF.FFFF，交换机的动作始终如一：接收 -> 查表学习源 MAC -> 向其他所有端口泛洪广播。

步骤九：ACK 广播泛洪落地，PC0 迎来大结局，正式配置 IP

随着交换机将包含最终确认信息的 DHCP ACK 广播帧分发至全网，我们终于迎来了整个 DHCP “DORA” 四步曲交互过程最激动人心的终局时刻！当广播帧送达路由器 (Router0)、PC1 和 PC0 时，不同设备基于自身状态做出了截然不同的判定：

目标主机（PC0）的处理：接收确认并配置 IP

此时，真正苦苦等待这个回包的 PC0，终于迎来了它的合法 IP 地址。我们来看看它激动人心的入站解封装过程：

底层解封装（第 1 层至第 4 层）

  • 第 2 层（数据链路层）：

    • 实际数据解析：“该帧的目的MAC地址与接收端口的MAC地址、广播地址或一个多播地址相匹配。该设备将PDU从以太网帧解封装。” PC0 的网卡识别到广播，剥离以太网帧头，向上递交。

  • 第 3 层与第 4 层（网际层与运输层）：

    • Packet 内容：源 IP: 192.168.0.252，目的 IP: 255.255.255.255；源端口 67，目的端口 68。

    • 剥离 IP 头部和 UDP 头部，提取出最核心的 DHCP 载荷，送达第七层。

应用层最终确认（第 7 层）

这是整个实验中最关键的一步，标志着 DHCP 租约的正式生效。

  • Packet 内容：DHCP Packet 服务器: 192.168.0.252，客户端: 0.0.0.0

  • 实际数据解析：

    1. “该数据包是一个DHCP数据包。DHCP客户端对其进行处理。”

    2. “DHCP客户端接收到一个DHCP确认数据包。” （成功识别这是最终的 ACK 报文）。

    3. “DHCP客户端接收到一个确认数据包并设置其IP地址配置。”

  • 要点：请特别注意第三句话！在此之前，PC0 的状态一直是“未指定地址”，只能靠广播度日。而在执行完这一步动作后，PC0 的操作系统正式将 192.168.0.1、子网掩码、默认网关等参数写入了本机的网卡配置中。

旁观设备（PC1 与 路由器）的处理：截然不同的丢弃层级

虽然拓扑中两台非目标设备都亮起了红叉，但通过 PDU 我们可以清晰地看到它们在 OSI 模型中拦截数据包的层级完全不同，这是一个非常经典的对比：

  • PC1（在第 7 层丢弃）：PC1 作为终端，其系统运行着 DHCP 客户端，持续监听 UDP 68 端口。因此 ACK 报文顺利穿透 1 至 4 层送达应用层。PC1 的 DHCP 进程打开信封后，发现载荷内的客户端 MAC 标识是 PC0 的，与自己不符，于是在第七层理智丢弃。

  • 路由器（在第 4 层丢弃）：路由器本地运行的是 DHCP 服务端，监听的是 UDP 67 端口。当这个目的端口为 UDP 68 的 ACK 报文到达路由器的运输层时，系统发现本地没有进程在监听该端口，于是数据包直接在第四层（运输层）被拦截并丢弃，根本没有机会进入第七层。

# 网络
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

cover

什么是 DAPP开发?DAPP 开发到底难不难?

avatar openEuler 社区
cover

通过Ubuntu和VMwareWorkStation揭秘MySQL数据库在C/S（客户端/服务器）模式中的使用

avatar openEuler 社区

Spring Boot 项目打包部署到云服务器的实践心得

在学习 Spring Boot 的过程中，我发现很多同学写好了本地能跑的项目，却不知道如何把它部署到云服务器上，让全世界都能访问。这次课程实践中，我从零开始，把一个简单的 Spring Boot Web 项目打包并部署到了阿里云 ECS 服务器上，踩了不少坑，也总结了一套完整的流程，在这里分享给大家。在这个过程中，我也意识到了很多细节的重要性，比如日志排查、环境一致性、端口安全配置等，这些都是课堂

avatar openEuler 社区