DHCP详解：从DORA报文到配置排错与安全防护

1. 没有DHCP的日子：手动配IP有多苦，你根本不想知道

干网络这行越久，我越喜欢把DHCP比作一套“自动租房系统”。IP地址就是那间出租房，设备就是拎包入住的租客。租客来了，系统自动分一间房，约定租期，到期自动续租，走人自动回收。这比喻听起来轻松，但现实里，没有这套系统的网络机房，绝对是每个网络工程师的噩梦。

我早年刚入行时，公司机房有四十多台服务器加两百多台办公终端。所有设备都是静态IP，靠一张Excel表维护IP分配记录。新员工入职要申请IP，我先得翻表找一个空闲地址，再手动改电脑配置。偶尔有人离职，没人告诉我释放了IP，过了一两年表格里全是僵尸记录，真正的空闲地址找不出几个。更离谱的是，有同事出差带着笔记本回来，没改IP设置，直接和会议室另一台设备冲突，整个网段时不时就有人掉线。那阵子天天被电话轰炸，排查下来一半都是IP冲突。后来我才彻底明白：DHCP不是“方便用用”的功能，而是让网络从“手工时代”跨入“自动时代”的分水岭。

这也就是为什么DHCP会成为所有网络工程师入门的第一座山。不管是考软考网络工程师，还是平时配置交换机、路由器，DHCP都是绕不过去的核心服务。它和DNS、HTTP一样属于应用层协议，运行在UDP之上，端口号67（服务器）和68（客户端）。本质上它做的事情极其单纯：给你一个IP地址，告诉你子网掩码、网关、DNS，然后要求你定期回来续个租约。但要把这套机制讲透，能应对实际工作中的坑，还得从报文交互开始一步步拆。

2. DHCP的四个报文和一个租约：这台“租房系统”究竟怎么运转的

2.1 客户端还没IP，怎么跟服务器说话

刚开始学DHCP的时候，我有个疑问卡了很久：客户端自己还没有IP地址，怎么去和服务器通信？后来才知道，DHCP的交互根本不依赖源IP通不通，而是靠广播和MAC地址。整个过程被概括成DORA四个字母：Discover（发现）、Offer（提议）、Request（请求）、Ack（确认），像极了租房流程——租客先喊一嗓子“谁有房？”（Discover，广播到整个局域网），房东听到后回应“我有房，配置是这样的”（Offer，也通过广播发回去），租客相中后说“我要租这套”（Request），房东最后确认“成交”（Ack）。成交之后，租客才能正式使用带出去的IP地址。

还有个细节很容易被忽略：DHCP的Offer包在二层上目的MAC是全F（FF:FF:FF:FF:FF:FF），也就是广播帧，而不是单播给客户端的。原因很朴素——客户端此刻没有IP，但它有MAC地址。服务器虽然知道客户端的MAC，可以在二层单播回应，但当时协议设计时为了兼容老设备和简化处理，默认用广播。当然，现代DHCP也支持通过设置广播位为0来让服务器用单播响应，不过绝大多数场景下你看到的还是广播。

2.2 租约里的T1和T2：不是到期才续租

租约不是像租房合同那样到期前一晚才联系房东。DHCP租约时间（Lease Time）默认常见配置是86400秒（24小时），但客户端并不会真的等满了才去续。它在租约的50%时间点（T1）会尝试单播请求续租，直接发Request报文给当初分配地址的那台服务器（DHCP服务器在Offer时通过option 54给过客户端自己的IP）。如果T1时间点没能续租成功，客户端会继续使用地址，一直等到租约87.5%的时间点（T2），此时它会重新发广播Request，不再单单找原来的服务器，而是允许任何一台DHCP服务器响应。再不行，熬到租约到期，客户端只能放弃这个IP，重新走一遍DORA。

理解这套机制对排查问题特别关键。你可以这样实测：在一台Windows电脑上把租约时间改成1小时，然后在t1附近抓包，能看到客户端发单播Request到服务器，服务器回单播Ack；但如果在交换机上抓包，你会发现T1时仍然是广播包——因为Windows实现细节会有差别，有些系统在T1时也用广播。最典型的坑是：DHCP服务器端配置了租约时间变更，但客户端没到T2就不会主动重新获取，你改完配置后急吼吼地让员工重启电脑，其实没必要。

2.3 报文里藏着哪些关键字段

抓包看DHCP报文时，别被一堆字段吓住。你只需要盯住这么几个：

• Bootp Flags：0x8000表示广播应答，0x0000表示单播。
• Client IP Address（ciaddr）：客户端自己的IP地址，通常最初是0.0.0.0，续租时才填上。
• Your IP Address（yiaddr）：服务器分配给客户端的IP，看Offer和Ack包里这个字段最有用。
• Server IP Address（siaddr）：服务器IP，也常用于后