DHCP协议基础：从网络启动到镜像加载的基石

各位同学，今天我们来聊聊DHCP协议。说实话，这个协议在网络世界里太常见了，常见到很多人反而忽略了它的重要性。但在网络启动和镜像加载这个场景里，DHCP可是绝对的主角之一。

我个人习惯把DHCP比作「网络世界的身份证发放处」。你想想看，一台刚开机的设备，它连自己是谁都不知道——没有IP地址，没有子网掩码，更不知道网关在哪。这时候DHCP就派上用场了。

DHCP的全称是Dynamic Host Configuration Protocol，动态主机配置协议。它的核心作用说白了就三件事：

我记得有一次在数据中心部署几百台服务器，如果每台都手动配IP，那得配到猴年马月去？DHCP一上，半小时全搞定。嗯，这就是它的价值。

核心要点：DHCP不仅分配IP，更重要的是它能在分配IP的同时，告诉客户端「你的启动文件在哪」、「TFTP服务器是谁」。这对PXE网络启动至关重要。

DHCP的交互过程，业内常说的「四次握手」。具体是哪四次？我们来看：

这里有个细节——DHCP Discover和DHCP Request都是广播报文。为什么会这样？因为客户端一开始连服务器的地址都不知道，只能靠广播来「喊话」。

我在项目中遇到过一个问题：客户端一直拿不到IP，抓包一看，Discover发出去了，Offer也回来了，但Request之后就没下文了。最后发现是交换机上开启了DHCP Snooping，把非信任端口的Offer报文给拦截了。这种坑，没踩过的人真想不到。

DHCP报文里有个灵活的部分叫「选项」（Options）。标准定义了上百种选项，但对我们网络启动来说，最核心的就两个：

实战技巧：我建议你在配置DHCP时，把Option 66和Option 67一起配。只配66不配67，客户端会尝试默认文件名（通常是pxelinux.0或bootx64.efi），但很多时候文件名是自定义的，不配67就会失败。

举个例子，假设你的TFTP服务器IP是192.168.1.100，启动文件是pxelinux.0，那DHCP配置里应该这样写：

option tftp-server-name "192.168.1.100";
option bootfile-name "pxelinux.0";

有些同学可能会问：为什么不用HTTP而用TFTP？嗯，这里有个历史原因——TFTP协议简单，实现起来占用的内存小，早期的网卡ROM里就能塞下TFTP客户端。现在虽然UEFI支持HTTP Boot了，但PXE启动的主流还是TFTP。

注意：Option 66填的是IP地址还是域名？我建议填IP地址。因为客户端在启动阶段可能还没有DNS解析能力，填域名反而会出问题。我曾经踩过这个坑，填了域名结果客户端解析不了，启动直接卡住。

现在问题来了：如果你的DHCP服务器在网段A，客户端在网段B，广播报文过不去怎么办？

解决方案就是DHCP中继代理（DHCP Relay Agent）。它部署在客户端所在的网段，负责把广播的DHCP Discover转换成单播，转发给远端的DHCP服务器。

中继代理的工作原理其实很简单：

说白了，中继代理就是个「传话筒」。但它做了一件很重要的事——在转发的报文里添加了giaddr（网关IP地址）字段。DHCP服务器根据这个字段就知道客户端在哪个网段，从而分配正确的IP地址。

我记得有一次帮客户做跨网段PXE启动，配置了中继代理但就是不行。排查了半天，发现是中继代理的giaddr填错了，指向了另一个网段的网关。这种低级错误，说出来都是泪。

为了让大家更直观地理解本章的知识结构，我画了一张图：

这张图把DHCP的核心知识点串起来了。你从中心往外看，四个分支分别对应作用、报文类型、关键选项和中继代理，而最下面的PXE网络启动则是我们最终要达成的目标。

好了，DHCP协议基础就讲到这里。记住一句话：DHCP是网络启动的入口，没有它，一切都是空谈。下一章我们会深入PXE协议，看看DHCP和TFTP是怎么配合完成启动的。

本章小结：