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 阶段交互" 的巧妙设计

相关推荐
程序员Xu4 小时前
【LeetCode热题100道笔记】腐烂的橘子
笔记·算法·leetcode
ST.J4 小时前
SQL与数据库笔记
数据库·笔记·sql
小马哥编程5 小时前
计算机网络:网络设备在OSI七层模型中的工作层次和传输协议
网络·计算机网络·智能路由器
肥肠可耐的西西公主5 小时前
后端(JDBC)学习笔记(CLASS 1):基础篇(一)
笔记·学习
学会煎墙5 小时前
3分钟快速入门WebSocket
网络·websocket·网络协议
白堤上的喵5 小时前
信息安全基础知识
网络
赖龙6 小时前
记录SSL部署,链路不完整问题
网络·网络协议·ssl
悠哉悠哉愿意6 小时前
【数学建模学习笔记】无监督聚类模型:分层聚类
笔记·python·学习·数学建模
fatiaozhang95276 小时前
浪潮CD1000-移动云电脑-RK3528芯片-2+32G-安卓9-2种开启ADB ROOT刷机教程方法
android·网络·adb·电脑·电视盒子·刷机固件·机顶盒刷机