孔良1. 地址到底是怎么“给到你设备”的：先讲清楚DHCP在解决什么问题
很多人觉得DHCP就是个“自动分配IP的玩意儿”，配置也就那么几行，真正遇到问题的时候却常常一头雾水。我之前帮一个朋友排查网络，他信誓旦旦地说自己把电脑IP设成了静态，所以“不关DHCP的事”，结果办公室几十台设备全部上不了网——原因恰恰是他手动填的那个地址，和DHCP地址池里正在分配的某个地址撞在了一起。这个场景让我意识到，很多人对DHCP的理解其实停留在“它给我IP”这个表层，完全没想过它背后到底干了多少事。
先问一个热搜里出现频率很高的问题：“IP是如何让对端知道的？”
答案比想象中复杂。网络通信要建立，前提是双方都得有一个合法的三层身份。你说你配了个静态IP 192.168.1.50，但你对面那台机器是192.168.2.50，你们两个即使插在同一台交换机上，报文发出去也到不了对方——因为目标网段跟本地网段对不上，网关又不知道在哪里。所以在局域网里，IP地址不是“自己觉得有就行”，而是必须要跟整个广播域的网络规划一致。
DHCP解决的就是这个三元问题：
- 地址分配：保证每个接入的设备在特定网段里拿到一个不冲突的地址。
- 参数同步：不仅仅是IP，还要给设备下发掩码、网关、DNS、域名这些配套参数，让设备真正能上网，而不仅仅是“有地址”。
- 冲突避免：通过服务器的统一管理，避免手工配置中常见的A设备填了B设备的IP这种低级事故。
还有人问：“使用静态IP，还需要DHCP吗？”这个问题得看场景。如果你是家里三台设备、网络拓扑十年不变，那静态IP完全可行。但只要你面对的设备超过十台、人员有流动、网络会调整，純静态方案很快就会变成维护灾难：你得维护一张长长的Excel表，新同事入职要手动找空地址，离职了还要记得释放。而DHCP的租约机制天然解决了这些问题——地址是借给你的，到期自动回收重新分配，你根本不需要关心设备什么时候走。
当然，DHCP不是万能的，它也会带来一些新问题，比如地址租期长短怎么定、多个DHCP服务器同时存在会不会打架、跨网段分配怎么实现。这些正是后文要展开的内容。先把原理的坑填平，配置的时候你才能知道每一条命令到底在做什么，而不是照着文档抄一遍完事。
提示：判断一个网络里DHCP重不重要，最简单的标准是看“地址变动频率”。设备经常换、网络经常调的场合，DHCP就是刚需；地址十年不动的场景，静态反而更省心。这个判断标准，后面配置租期时还会用到。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四次握手拆到报文级：Discover、Offer、Request、ACK里藏着的细节
DHCP的完整交互过程，几乎所有教材都会画一张四步流程图：Discover、Offer、Request、ACK。原理大家都会背，但真正在工作中反复出问题的，往往是这四步里某些“看起来不重要”的细节。
2.1 Discover：为什么源IP是0.0.0.0
客户端刚接入网络时，自己没有任何IP配置，所以发DHCP Discover报文时，报文头里源IP只能是0.0.0.0，目的IP是255.255.255.255（广播）。这个设计很朴素——我连自己是谁都不知道，只能向全世界喊一嗓子“有没有人愿意给我发个地址”。
但注意，这里的“全世界”指的是当前二层广播域。交换机收到广播帧后，会把它从除了入端口以外的所有端口转发出去。这带来一个直接后果：DHCP Discover报文出不了路由器。路由器默认不转发广播，所以当客户端的网关不在同一个广播域时，Discover根本到不了服务器。这个限制，正是后面DHCP中继存在的根本原因。
报文里还有一个容易被忽视的字段是chaddr，即客户端的MAC地址。服务器后续回应时，就是靠这个MAC地址找到客户端的。
2.2 Offer：广播还是单播，其实有讲究
服务器收到Discover后，会从地址池里挑一个可用的地址，构造Offer报文回应。这里有个细节：Offer的目的地址，既可以是广播地址，也可以是单播地址。服务器怎么判断？
关键在于服务器是否知道客户端的IP地址。Discover报文里，客户端还没有地址，所以ciaddr字段是0.0.0.0，服务器无法用IP直接单播回去。但多数实现中，服务器会先把Offer发到广播地址255.255.255.255，再靠链路层把帧目的MAC设为客户端的MAC。从IP层看是广播，从链路层看是定向投递，两者并不矛盾。
有一种例外情况：如果客户端在发出Discover之前曾经有过一个IP，只是租约过期了，那么在Request阶段ciaddr字段会填上旧地址，此时服务器就可以直接单播回应。
2.3 Request：为什么客户端要“广播”确认
客户端收到一个或多个Offer后，会从中选择一个（通常是最先到达的那个），然后发送DHCP Request报文。注意，这个Request仍然是广播发送的。
为什么要广播？因为可能有多台DHCP服务器同时响应了Discover。客户端广播Request的目的，是告诉所有服务器：“我选了A服务器的Offer，你们其他的可以把预留的地址释放掉了。”如果改成单播发给A服务器，其他服务器就不知道自己落选了，那些被预留给客户端的地址可能要等到租约超时才被回收，这在地址池紧张时会造成大量浪费。
同时，Request报文里会带上一个server identifier字段，填的是被选中服务器的IP地址，这样其他服务器看到这个字段就知道自己没有被选中。
2.4 ACK以及比ACK更重要的租约机制
服务器收到Request后，确认无误就发送ACK，里面包含了正式的IP地址、租期、网关、DNS等完整参数。客户端收到ACK后，才算真正获得了一个可用的网络配置。
但这不代表一劳永逸。客户端拿到的地址是有租期的，到了T1时间点（默认是租期的50%），客户端会尝试通过单播向服务器续租。如果没续上，到了T2时间点（租期的87.5%），客户端会转入rebinding状态，重新用广播Request寻找任意可用的服务器。如果整个租期都结束了还没续上，客户端只能放弃这个地址，回到Discover重新开始。
这个机制的意义在于：租约不是永久授权，而是周期性的确认。所以即使网络里临时出现了冲突或网段调整，最长等待一个租期，所有设备也会自动收敛到新配置上。我见过有人把max-lease-time设成30天，调整网关后整整一