DHCP协议DORA四步分配IP，网工必考全流程拆解

DHCP协议的定义与标准化背景

动态主机配置协议，英文全称Dynamic Host Configuration Protocol，缩写DHCP，是TCP/IP协议栈应用层中的一员。它在RFC 2131和RFC 2132中完成标准化定义，核心使命是在网络终端设备接入时，自动向其分配IP地址、子网掩码、默认网关、DNS服务器地址等一系列网络配置参数。DHCP的前身是BOOTP协议，BOOTP诞生于上世纪八十年代，最初服务于无盘工作站启动过程，但它存在一个致命缺陷——管理员必须在BOOTP服务器上预先为每台设备的MAC地址静态绑定IP地址，缺乏动态回收和复用机制。DHCP在BOOTP的基础上增加了地址租约、自动回收和动态分配三大能力，使得IP地址管理从手工记账时代进入了自动化时代。

DHCP工作于应用层，但属于"基础设施型应用层协议"——用户不直接感知它，它却为所有上层应用的网络通信提供前置条件。DHCP报文封装在UDP中传输，服务器监听UDP 67端口，客户端监听UDP 68端口。选择UDP而非TCP的原因在于，DHCP客户端在获取IP地址前没有有效IP地址，而TCP三次握手需要完整源目IP配对——客户端需要TCP连接获取IP地址，但TCP连接本身又要求客户端已经拥有IP地址，形成逻辑死锁。UDP的无连接特性恰好解开了这个死结。

从协议分层角度看，DHCP与BOOTP共享相同的报文格式框架，DHCP报文在BOOTP报文的基础上扩展了选项字段，使得DHCP不仅能分配IP地址，还能下发数十种网络参数。RFC 2132专门定义了DHCP选项的编码格式和标准选项列表，选项编号从0到255，其中编号1是子网掩码，编号3是默认网关，编号6是DNS服务器，编号15是域名，编号51是IP地址租约时间。每个选项采用TLV格式编码，即Tag标记选项类型、Length标记值长度、Value承载实际数据。这种可扩展的设计使得DHCP在三十多年间不断纳入新的网络参数类型而无需改动协议基本框架，体现了协议设计的远见。

DHCP的DORA四步交互机制

DHCP客户端从一无所有到获得一个可用的IP地址，需要经历四个阶段的报文交互，业界通常取其每一步操作名称的首字母，合称为DORA过程。这四个字母分别代表Discover发现、Offer提供、Request请求和Acknowledge确认。理解DORA的每一步细节，是掌握DHCP协议精髓的关键所在，也是网络工程师考试中反复出现的命题焦点。

Discover阶段：全网广播寻服务器

客户端刚接入网络时，自身IP地址为0.0.0.0，不知道网络中谁是DHCP服务器，甚至不知道DHCP服务器是否真的存在。此时客户端构造一个DHCP Discover报文，将源IP地址设置为0.0.0.0，目的IP地址设置为255.255.255.255，即有限的广播地址。报文中携带客户端的MAC地址和一个随机生成的事务标识符，这个事务ID由客户端随机生成，用于匹配后续收到的响应是否属于自己的请求。Discover报文以UDP数据报封装，源端口为68，目的端口为67，向整个广播域内的所有节点送达。

在二层以太网帧层面，Discover报文的目标MAC地址同样填全F，即FF-FF-FF-FF-FF-FF。这意味着交换机收到该帧后会在该VLAN的所有端口泛洪转发，不会进行MAC地址表查表操作。同一广播域内的所有DHCP服务器都能收到这份Discover报文，为后续可能的Offer竞争埋下伏笔。如果网络中部署了DHCP中继代理，中继代理会拦截这个广播报文，将广播转换为单播，通过中继代理自身的IP地址向远端DHCP服务器转发，这便是DHCP跨网段工作的技术基础。

Offer阶段：服务器响应并预留地址

DHCP服务器收到Discover报文后，检查自己的地址池中是否还有可分配的IP地址。如果有，服务器从地址池中选出一个尚未租出的IP地址，将其暂时标记为"待分配"状态，然后构造一个DHCP Offer报文单播发送给客户端。Offer报文中填入被选中的IP地址、子网掩码、默认网关、DNS服务器地址、租约期限等参数。需要注意的是，服务器端发出Offer时使用的是单播目的IP地址，即它填入Offer报文目的IP字段的是那个尚未正式分配给客户端的IP地址，这种看似矛盾的做法之所以可行，是因为客户端在二层可以通过MAC地址接收这个单播帧——Offer报文的以太网帧目标MAC地址就是客户端的MAC地址，这在Discover阶段已经被服务器记录下来了。

Offer阶段还有一个容易被忽略的细节：Offer报文不代表地址已经被真正分配。在服务器端，这个IP地址当前处于"临时预留"状态，如果客户端在合理时间内没有回应Request，服务器会解除预留，将地址重新放回可用地址池。这种临时预留的机制防止了地址池中的IP被无效占用，是DHCP协议可靠性设计的重要组成部分。

Request阶段：客户端选择并正式申请

客户端可能收到来自多台DHCP服务器的Offer报文，因为一个广播域内完全可能存在多台DHCP服务器。客户端通常选择最先收到的Offer，然后向全网广播一个DHCP Request报文，在报文中明确指定自己选择了哪台服务器提供的哪个IP地址。之所以Request仍然使用广播而非单播，是因为客户端需要通过广播让所有发出过Offer的服务器都知道最终的选择结果，未被选中的服务器收到这个广播Request后会立即释放之前临时预留的IP地址，将其归还地址池，避免地址浪费。

Request报文中包含一个关键的选项字段——Option 54，它的值是客户端选中服务器的标识符。这个字段的设计非常精妙：在一个多DHCP服务器共存的网络中，每台服务器都可以通过检查Request报文中的Option 54来判断客户端的最终选择，进而决定是进入最终确认流程还是解除预留。Request报文同样是源地址0.0.0.0、目的地址255.255.255.255的广播报文，源端口68、目的端口67。

Acknowledge阶段：服务器最终确认

DHCP服务器收到Request报文后，验证客户端选择的IP地址是否确实来自自己的地址池，检查地址当前状态是否合法。验证通过后，服务器将IP地址的租约状态从"临时预留"正式转为"已分配"，将租约过期时间写入地址池管理记录，然后向客户端单播发送DHCP Ack报文。Ack报文中除了包含与Offer相同的配置参数外，还会携带经服务器最终确认的租约期限。客户端收到Ack后，将获得的IP地址绑定到自己的网络接口上，同时启动租约计时器，至此DHCP地址分配流程完成。

如果服务器在验证过程中发现IP地址已经不可用——例如在Offer到Request之间被其他方式占用了，或者Request中指定的IP地址不属于本服务器的地址池——服务器会回复一个DHCP Nak报文。Nak报文代表拒绝，客户端收到Nak后必须放弃当前所有状态，回到初始状态重新发起Discover。

DHCP租约管理与续约更新机制

DHCP并非将IP地址永久授予客户端，而是以"租约"的形式限时分配。租约本质上是一个倒计时定时器，从客户端收到Ack报文的那一刻开始计时。租约期限由DHCP服务器在Offer和Ack报文中通过Option 51指定，单位是秒。租约在企业内网可长达数天，公共Wi-Fi中缩短到数小时，高流动性场景可短至几分钟。租约到期前客户端必须续约，否则IP地址将被服务器回收并重新分配给其他设备，客户端自身的网络连接随即中断。

续约过程并非等到租约完全到期才启动，DHCP设计了分阶段的续约策略。当租约时间过半时，客户端会自动向DHCP服务器单播发送一个DHCP Request续约报文，目的IP地址直接填写服务器的IP地址。这是一个从广播到单播的关键转变——客户端此时已经拥有有效IP地址，完全有能力与服务器进行点对点通信。如果服务器在续约时认可该客户端的继续使用，会回复一个Ack报文，客户端据此重置租约计时器，从零开始重新计算租约期限。

如果租约过半时客户端发出的续约请求没有得到服务器响应——例如服务器宕机或网络链路中断——客户端不会立即放弃，而是继续等待。当租约时间消耗到87.5%时，客户端会再次尝试续约，但这次不再只向原DHCP服务器单播发送Request，而是以广播方式向全网重新发送DHCP Request报文，试图联系任何能为自己续约的DHCP服务器。如果这次广播续约仍然失败，当租约100%到期时，客户端必须释放IP地址，将网络接口恢复为无IP状态，重新进入Discover阶段。

续约过程中的Request报文与初始分配时的Request报文在本质上是相同的操作码，但上下文中携带的选项不同——续约时不带Option 54服务器标识符，因为续约Request默认就是向原分配服务器发送的。此外，客户端在续约成功后会更新本地记录的租约过期时间，但不会重新配置网络接口参数，因为IP地址没有变化，只是租约时间被延长了。如果续约过程中服务器返回了Nak，说明服务器认为该客户端无权继续使用这个IP地址，客户端必须立即停止使用，重新执行完整的DORA流程。

DHCP中继代理与跨网段分配原理

DORA的四步交互中有两步是广播通信——Discover和Request都是目的地址255.255.255.255的广播报文。广播报文无法跨越路由器，这是IP网络的基本规则。如果DHCP服务器和客户端不在同一个广播域，客户端的Discover报文到达路由器接口后就会被直接丢弃，客户端永远无法获得IP地址。解决这个矛盾的手段就是DHCP中继代理。

DHCP中继代理通常部署在路由器或三层交换机的接口上，功能是在客户端所在网段截获广播的Discover和Request报文，将其重新封装为单播UDP报文，通过中继代理自身的接口IP地址向远端DHCP服务器转发。中继代理在转发时会在DHCP报文中插入一个关键字段——GIADDR，即网关IP地址字段。GIADDR填写的是中继代理接收客户端广播报文的那个接口的IP地址，而不是中继代理自身的管理地址。

当远端DHCP服务器收到中继转发的Discover报文时，它并不直接

本篇完！