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

相关推荐
饶了我吧,放了我吧15 小时前
数据通信与计算机网络-交换
网络
weixin_4569042715 小时前
UDP端口释放和清理时间分析
网络·网络协议·udp
Lowjin_15 小时前
计算机网络-ipv4首部校验原理
网络·计算机网络
Net_Walke15 小时前
【网络协议】数字签名与证书
网络·网络协议
aramae16 小时前
Linux开发工具入门:零基础到熟练使用(二)
linux·运维·服务器·网络·笔记
Suckerbin16 小时前
burpsuite网络安全学院: JWT attacks靶场通关
网络·笔记·安全·web安全·网络安全
智者知已应修善业17 小时前
【C++无数组矩阵对角线平均值保留2位小数】2022-11-18
c语言·c++·经验分享·笔记·算法·矩阵
环球经济报18 小时前
“常小豚苏超限定款”公益联名:以热爱之名守护生态赛场
笔记
Suger99918 小时前
centos网络打流测试
linux·网络·centos
半导体守望者19 小时前
TR帝尔编码器GSD文件 PROFIBUS XML PROFINET EtherCAT 文件 ADH CDH CMV等
xml·经验分享·笔记·机器人·自动化·制造