Wireshark笔记-DHCP两步交互流程与数据解析

背景

昨天给出了计算机网络工程师中很重要的知识点，DHCP四步交互。

今天再补充下DHCP一个次重要的知识点，两步交互。

这个两步交互是有条件的。一般情况是续租时（意思就是连过一次这个wifi了）

客户端保留历史租约，直接发 DHCP Request（携带曾用 IP），服务器验证租期有效后回 ACK，跳过 “发现（Discover）、提供（Offer）” 阶段；

过程

Wireshark抓包如下：

在Info中可知，就两步Request -> ACK

下面来看下第一个包（Request ）：

比较关键的信息

Client IP：0.0.0.0（客户端暂未分配有效 IP，通过 Option 50 声明 Requested IP: 192.168.23.101（曾租用过的 IP）。

Transaction ID：0xf8218414（唯一会话标识，后续 ACK 包同 ID，证明是同一流程）。

Boot flags：0x0000（无广播标志，但目的 IP 是 255.255.255.255，说明客户端不确定服务器是否在线，仍广播请求，但携带历史 IP 意图）。

下一个ACK包

比较关键的信息：

Message Type：ACK (Boot Reply, 2)，服务器确认 IP 分配，属于 DHCP 交互的最终确认阶段。

Transaction ID：0xf8218414，与前文 DHCP Request 包的事务 ID 一致，绑定同一交互会话。

Your (client) IP：192.168.23.101 ，服务器分配给客户端的 IP（客户端曾通过 Option 50 请求该 IP，属于续租场景）。

Boot Flags：0x0000 (Unicast)，服务器单播回复（而非广播），因已通过 Request 包获取客户端 MAC，直接定向发送更高效。

Option 54 (Server ID)：192.168.23.138，标识 DHCP 服务器，避免多服务器冲突（本场景虽单服务器，但协议保留该字段）。

Option 51 (Lease Time)：隐含租约时长（如 86400 秒），客户端可使用该 IP 的有效期，续租时此值决定 “信任周期”。

有个疑问

此处提出一个疑问，估计大部分读者都应该发现了。为什么dhcp服务端的ACK会直接回192.168.23.101的单播。dhcp的客户端不应该没有ip地址吗？

DHCP 的单播交互，是 “链路层交付（MAC） + 网络层标识（IP）” 的分离设计：

① 链路层负责 “把帧送到客户端网卡”（靠 MAC）；

② 网络层的目标 IP 负责 “让客户端知道这是给自己的 IP 配置”（靠 Option 50 和 ACK 的 IP 匹配）。

客户端即使还没 IP，只要 MAC 对、客户端中DHCP 进程在监听，就能接收并处理这个 ACK，最终完成 IP 配置。这就是 DHCP 协议对 “无 IP 阶段交互” 的巧妙设计