Python手写DHCP服务器：从协议原理到生产级实现

DHCP 这东西，日常存在感极低，但只要你动过一次网络配置，就绕不开它。大多数人第一次接触它是在路由器后台，看到"DHCP 服务"开关，点一下，完事。可一旦要自己用 Python 写一个 DHCP 服务器，问题就来了：协议报文长什么样、广播怎么处理、地址池怎么分配、租约怎么管理，这些细节文档里写得零散，网上教程又大多只给个半成品。我当初做这个项目，就是为了把"地址自动分配"这件事从黑盒拆成白盒，用 Python 从零实现一个能跑起来的 DHCP 服务器，顺便把协议里那些容易踩的坑摸清楚。

这篇内容适合两类人：一类是刚学完 socket 编程、想找个真实协议练手的 Python 开发者；另一类是网络方向的学习者，想搞明白 DHCP 报文在字节层面到底怎么组织。我会从协议原理讲起，把报文结构、地址池设计、租约状态机、广播收发这些核心环节逐个拆开，配上可直接运行的代码片段和实测中遇到的问题。读完你至少能自己搭一个能分配地址、能处理续租、能应对地址冲突的 DHCP 服务，而不是只会调库。

1. 为什么值得用 Python 手写一个 DHCP 服务器

1.1 DHCP 到底在解决什么问题

先说清楚 DHCP 的定位。一台设备接入网络，要能通信，至少得知道四样东西：自己的 IP 地址、子网掩码、网关地址、DNS 服务器。这四样如果全靠手工配，在设备少的时候还行，设备一多、人员一换，配错、冲突、漏配就是家常便饭。DHCP 的核心价值就是把这套配置自动化：设备开机发一个"我是谁、我该用哪个地址"的请求，服务器回一个"你用这个地址、掩码是这个、网关走这里"的应答，整个过程几秒内完成，用户无感知。

从协议层面看，DHCP 是典型的 C/S 架构，基于 UDP，服务端监听 67 端口，客户端用 68 端口。它最特殊的地方在于大量依赖广播：客户端在还没拿到地址之前，根本不知道服务器在哪，只能朝广播地址 255.255.255.255 发请求。这一点决定了我们写服务器时，socket 必须开广播权限，否则报文根本发不出去。理解了这个前提，后面很多设计选择就顺理成章了。

1.2 手写实现相比现成方案的价值

有人会问，现成的 DHCP 服务（路由器自带、各类系统服务）已经很成熟了，为什么还要自己写？我的理由有三个。第一，可控性。现成服务你只能配参数，遇到特殊需求（比如按 MAC 前缀分配固定网段、按时间段限速分配）就抓瞎，自己写想怎么改就怎么改。第二，可观测性。自己实现的服务器，每一封报文的收发、每一次地址分配决策都能打日志，排查"某台设备为什么拿不到地址"这类问题时，比对着黑盒猜要高效得多。第三，学习价值。DHCP 报文是二进制协议，字段对齐、字节序、选项编码这些细节，只有亲手拼过一遍字节，才算真正理解。

我实测下来，一个功能完整的 DHCP 服务器核心逻辑大概 500 到 800 行 Python 就能覆盖，包括报文解析、地址池管理、租约维护、冲突检测。这个体量非常适合作为网络编程的练手项目，既不会大到劝退，也不会小到没东西可学。

1.3 整体架构先看一眼

在动手写代码之前，先把模块划分清楚，避免写到一半发现结构混乱。我的实现分成四层：报文层负责 DHCP 报文的打包与解包，处理固定字段和可变选项；地址池层管理可分配地址范围、已用地址、保留地址；租约层维护每个地址的租期、状态、绑定关系；服务层是主循环，负责收包、分发、调用上面三层、发包。这四层之间通过明确的数据结构交互，报文层只认字节，地址池层只认 IP，租约层只认绑定记录，职责清晰，改起来也方便。

下面这张表是我对四层职责和关键数据结构的梳理，后面每个章节会逐个展开：

2. DHCP 报文的字节级结构拆解

2.1 固定头部：236 字节的硬骨头

DHCP 报文的前 236 字节是固定结构，字段顺序和长度都是写死的，一个字节都不能错位。我一开始就是没仔细核对字段长度，导致解析出来的 IP 全是乱码，排查了半天才发现是某个字段多算了一个字节。所以这部分必须逐字段对照。

固定头部的关键字段包括：op（1 字节，标识请求或应答）、htype（1 字节，硬件类型，以太网是 1）、hlen（1 字节，硬件地址长度，MAC 是 6）、hops（1 字节，跳数）、xid（4 字节，事务 ID，用来匹配请求和应答）、secs（2 字节，客户端已用时间）、flags（2 字节，标志位，最高位表示是否要求广播应答）、ciaddr/yiaddr/siaddr/giaddr（各 4 字节，分别是客户端地址、分配给客户端的地址、服务器地址、中继代理地址）、chaddr（16 字节，客户端硬件地址，MAC 只占前 6 字节，后面补零）、sname（64 字节，服务器名）、file（128 字节，启动文件名）。

用 Python 的struct模块打包时，格式串要严格对应。我用的格式是!BBBBIHHIIII16s64s128s，开头的!表示网络字节序（大端），这一点极其重要——DHCP 所有多字节字段都是大端序，忘了加!解析出来的 xid 和地址全是反的。chaddr 固定 16 字节，MAC 只有 6 字节，剩下 10 字节补零，解包时取前 6 字节即可。

import struct # 固定头部格式：网络字节序，逐字段对应 HEADER_FORMAT = '!BBBBIHHIIII16s64s128s' HEADER_SIZE = struct.calcsize(HEADER_FORMAT) # 应为 236 def parse_header(data): fields = struct.unpack(HEADER_FORMAT, data[:HEADER_SIZE]) return { 'op': fields[0], 'htype': fields[1], 'hlen': fields[2], 'hops': fields[3], 'xid': fields[4], 'secs': fields[5], 'flags': fields[6], 'ciaddr': fields[7], 'yiaddr': fields[8], 'siaddr': fields[9], 'giaddr': fields[10], 'chaddr': fields[11][:6], # 只取前 6 字节 MAC 'sname': fields[12], 'file': fields[13], }

提示：struct.calcsize算出来的头部长度必须是 236，如果你的环境算出来不是这个数，检查格式串里每个字段的类型符是否和协议一致，尤其是 chaddr 的 16s 和后面两个大字段。

2.2 魔术 Cookie 与选项字段

固定头部之后是 4 字节的魔术 Cookie，值是0x63825363。这 4 个字节的作用是告诉解析方"后面是 DHCP 选项区"，没有它就没法区分这是 DHCP 还是更早的 BOOTP 报文。解析时先校验这 4 字节，对不上直接丢弃，能省掉后面一堆无效解析。

选项区是 DHCP 最灵活也最容易出错的部分。每个选项的格式是：1 字节选项码 + 1 字节长度 + 长度个字节的数据。选项码 53 是消息类型（Discover、Offer、Request、Ack 等），选项码 1 是子网掩码，3 是网关，6 是 DNS，51 是租期，54 是服务器标识。选项区以选项码 255 结束。解析选项时要注意两个坑：一是某些选项长度可变，必须按长度字段动态读取，不能写死；二是选项可能不按顺序出现，解析逻辑要能处理任意顺序。

MAGIC_COOKIE = b'\x63\x82\x53\x63' def parse_options(data): options = {} i = 0 while i < len(data): code = data[i] if code == 255: # 结束选项 break if code == 0: # 填充选项，跳过 i += 1 continue length = data[i + 1] value = data[i + 2:i + 2 + length] options[code] = value i += 2 + length return options

打包选项时逻辑反过来：按选项码顺序写入，每个选项先写码再写长度再写值，最后补 255 结束符。这里有个细节，选项 53（消息类型）通常放在最前面，某些客户端对顺序敏感，虽然协议没强制要求，但按惯例放前面兼容性更好。我实测过把 53 放到后面，部分设备确实会忽略整个报文，所以这个顺序别省。

2.3 消息类型与交互流程

DHCP 的交互流程围绕几种消息类型展开，最核心的是四步：Discover（客户端广播找服务器）、Offer（服务器回应可分配的地址）、Request（客户端确认要用这个地址）、Ack（服务器最终确认）。除此之外还有 Nak（服务器拒绝）、Release（客户端主动释放）、Decline（客户端声明地址冲突）、Inform（客户端已有地址只要其他配置）。

这几种消息类型用选项 53 的值区分，Discover 是 1，Offer 是 2，Request 是 3，Decline 是 4，Ack 是 5，Nak 是 6，Release 是 7，Inform 是 8。服务器收到报文后，第一件事就是读选项 53 判断类型，再决定走哪个处理分支。这个分发逻辑是整个服务层的主干，后面章节会详细讲。

理解流程时有个关键点：Offer 阶段服务器只是"预留"地址，并没有真正分配。客户端可能同时收到多个服务器的 Offer，它只会选一个发 Request，其他服务器的预留地址要能回收。所以地址池里要有"预留"这个中间状态，不能一发 Offer 就标记为已用，否则并发场景下地址会被白白占住。这个设计细节很多简化实现都忽略了，导致地址池很快耗尽。

3. 地址池与租约管理的数据结构设计

3.1 地址池该用什么结构存

地址池的本质是"一个 IP 范围 + 每个地址的占用状态"。最直接的做法是用一个字典，键是 IP 字符串，值是状态标记。但字典遍历找可用地址效率低，地址一多就慢。我的做法是维护三个集合：available（可用地址）、reserved（已发 Offer 未确认）、allocated（已确认分配）。分配时从 available 里取，取到后移到 reserved，收到 Request 确认后从 reserved 移到 allocated，租约到期或 Release 后移回 available。

用集合而不是列表，是因为集合的增删和成员判断都是 O(1)，地址池几千个地址也不会有性能问题。初始化时按起始和结束 IP 生成所有地址字符串塞进 available 集合。这里要注意 IP 和整数的转换，用ipaddress模块的IPv4Address和int互转最稳妥，自己手写位运算容易在边界上出错。

import ipaddress class AddressPool: def __init__(self, start_ip, end_ip): start = int(ipaddress.IPv4Address(start_ip)) end = int(ipaddress.IPv4Address(end_ip)) self.available = {str(ipaddress.IPv4Address(i)) for i in range(start, end + 1)} self.reserved = {} self.allocated = {} def acquire(self, mac): if not self.available: return None ip = self.available.pop() self.reserved[ip] = mac return ip def confirm(self, ip, mac, lease_time): if self.reserved.get(ip) == mac: del self.reserved[ip] self.allocated[ip] = {'mac': mac, 'expire': time.time() + lease_time} return True return False

3.2 租约记录里必须存哪些字段

租约记录不能只存 IP 和 MAC，至少还要有到期时间、租期长度、状态。到期时间用来判断是否过期，租期长度用来在续租时重新计算，状态用来区分"正常""即将过期""已过期"。我一开始只存了到期时间，结果续租时不知道该给多长租期，只能写死一个值，后来补上租期字段才解决。

租约的状态流转是这样的：分配时状态为 active，到期时间设为当前时间加租期；客户端在租期过半时通常会发续租请求，服务器收到后把到期时间往后推一个租期；如果到期还没续租，状态转为 expired，地址回收进 available。这里有个容易忽略的点：续租请求可能来自不同服务器，如果客户端换了网络环境，原服务器收到续租请求时地址可能已经不在自己池子里，要能正确回 Nak 让客户端重新走完整流程。

3.3 保留地址与固定绑定

实际部署里经常需要给某些设备固定 IP，比如打印机、监控设备。这类需求靠"保留地址"实现：维护一个 MAC 到 IP 的映射表，分配时先查表，命中就直接给固定地址，不走动态池。保留地址要从 available 集合里剔除，避免被动态分配出去。这个逻辑要在初始化时处理，否则会出现固定地址被别的设备抢走的情况。

固定绑定的另一个用途是地址冲突规避。如果某台设备手工配了静态 IP，又恰好落在 DHCP 池范围内，DHCP 服务器不知道，可能把这个地址分给别的设备，造成冲突。解决办法是在池子里预留一段"排除区间"，初始化时把这些地址从 available 里去掉。这个排除列表最好做成配置项，方便按实际网络规划调整。

4. 服务主循环与广播收发的实操细节

4.1 socket 怎么开才能收广播

DHCP 服务器要收客户端发往 255.255.255.255 的广播包，socket 必须做两件事：绑定到 0.0.0.0（而不是某个具体网卡地址），并设置SO_BROADCAST选项允许发送广播。绑定 67 端口需要管理员权限，Windows 和 Linux 都一样，开发时如果没权限，可以临时改成高端口测试，但要注意客户端默认发往 67，改端口后得同步调整测试客户端的配置。

import socket sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.bind(('0.0.0.0', 67))

SO_REUSEADDR是为了快速重启服务时不被"地址已占用"卡住，调试阶段频繁重启，不加这个每次都要等端口释放，很耽误事。SO_BROADCAST不加的话，发送广播包会直接抛异常，这个坑我踩过，报错信息不明显，查了半天才发现是少了这个选项。

4.2 应答该单播还是广播

服务器回包用单播还是广播，取决于客户端报文里的 flags 字段最高位。如果这一位是 1，表示客户端还不会用单播（因为它可能还没配好地址栈），服务器必须用广播回；如果是 0，可以单播到 yiaddr。但实际实现里有个麻烦：客户端在 Discover 阶段还没有 IP，单播根本发不到它手上，所以Discover 的应答基本都得走广播。Request 阶段客户端可能已经有地址了，可以尝试单播，但为了兼容性，很多实现统一用广播，简单可靠。

我的做法是：Offer 和 Ack 默认广播到 255.255.255.255，目标端口 68。广播包在局域网里所有设备都能收到，靠 xid 和 chaddr 匹配，客户端只处理属于自己的那封。这种方式效率不高，但兼容性最好，实测各类设备都能正常拿到地址。

4.3 主循环的分发逻辑

主循环就是一个死循环，收包、解析、按消息类型分发、发包。分发用字典映射处理函数，比一长串 if-elif 清晰。每个处理函数负责构造对应类型的应答报文。这里要注意异常处理：单封报文解析失败不能让整个服务崩掉，用 try-except 包住单次处理，记录日志后继续下一轮。

handlers = { 1: handle_discover, # Discover 3: handle_request, # Request 7: handle_release, # Release 8: handle_inform, # Inform } while True: data, addr = sock.recvfrom(1024) try: header = parse_header(data) options = parse_options(data[240:]) msg_type = options.get(53, b'\x00')[0] handler = handlers.get(msg_type) if handler: handler(sock, header, options, addr) except Exception as e: log.error(f'处理报文失败: {e}')

报文长度上限设 1024 足够，DHCP 报文一般不超过 576 字节。recvfrom返回的 addr 是客户端地址，Discover 阶段这个地址可能是 0.0.0.0，不能拿它当回包目标，必须用广播地址。

5. 实测中踩过的坑与排查链路

5.1 地址分配了但客户端拿不到

第一次跑通时遇到的现象是：服务器日志显示已经发了 Offer，但客户端一直重发 Discover，始终拿不到地址。排查链路是这样的：先确认服务器确实发出了包，抓包看到 Offer 报文发出去了；再看客户端有没有收到，发现客户端侧抓包没有 Offer；问题定位到发送环节。最后发现是回包目标地址写成了addr（客户端地址），而 Discover 阶段这个地址是 0.0.0.0，包发出去等于石沉大海。改成广播地址 255.255.255.255 后立刻正常。

这个坑的教训是：Discover 和 Request 阶段的回包目标地址不能想当然用来源地址。来源地址在客户端没配好之前是不可靠的，统一走广播最稳。后来我在代码里加了个判断，只要客户端 ciaddr 是 0，一律广播，彻底避免这个问题。

5.2 选项解析错位导致地址乱码

另一个坑是解析出来的 yiaddr 是乱码。原因是固定头部格式串里某个字段类型写错了，导致后续字段全部错位。排查方法是把原始字节按十六进制打印出来，对照协议文档逐字段核对偏移量。DHCP 头部字段偏移是固定的：op 在 0，xid 在 4，yiaddr 在 16，chaddr 在 28。用偏移量直接切片验证，比对着格式串猜要快得多。

# 按偏移量直接取，用于交叉验证 xid = struct.unpack('!I', data[4:8])[0] yiaddr = socket.inet_ntoa(data[16:20]) mac = data[28:34]

这种按偏移硬取的方式虽然不优雅，但作为调试手段非常有效，能快速确认是格式串问题还是数据本身问题。确认无误后再回到格式串解析，两边结果对得上就说明解析逻辑没问题。

5.3 地址池耗尽的假象

有次测试发现地址池很快就空了，但实际在线的设备没几台。查日志发现大量地址停在 reserved 状态没转成 allocated。原因是测试客户端发了 Discover 拿到 Offer 后，没有继续发 Request（可能是测试脚本的问题），这些预留地址就一直占着。真实环境里客户端一般会正常走完流程，但异常情况（客户端崩溃、网络中断）确实会导致预留泄漏。

解决办法是给 reserved 状态加超时：预留超过一定时间（比如 30 秒）还没收到 Request，就回收进 available。这个超时值不能太短，否则客户端还没来得及发 Request 地址就被回收了；也不能太长，否则泄漏的地址占着不放。30 秒是个比较稳妥的经验值，实测覆盖了绝大多数正常客户端的响应时间。

5.4 续租时租期计算错误

续租场景下，客户端发的是 Request 但带着已有的 ciaddr，服务器要识别这是续租而不是新分配。我最初的实现没区分，续租时又走了一遍分配逻辑，导致同一个 MAC 拿到两个不同地址。修复方法是：Request 处理时先查租约表，如果这个 MAC 已有 active 租约且请求的 IP 和租约一致，就只更新到期时间，不重新分配。

续租的租期计算也有讲究。协议建议客户端在租期过半时续租，服务器确认后把到期时间设为"当前时间 + 租期"。这里要用当前时间而不是原到期时间往后推，否则客户端延迟续租会导致租期越来越短。这个细节在文档里不显眼，但实际影响很大，我调了好久才发现续租几次后租期变得极短。

6. 让实现更接近生产可用的几个增强

6.1 冲突检测：分配前先探一下

地址分配出去之前，最好先确认这个地址当前没被占用。标准做法是发 ARP 探测，但纯 Python 实现 ARP 比较麻烦，需要原始套接字权限。一个折中方案是维护一个"最近被 Decline 的地址"黑名单：客户端如果发现拿到的地址冲突，会发 Decline 报文，服务器收到后把该地址标记为不可用一段时间（比如 1 小时），期间不再分配。这个机制不能完全替代 ARP 探测，但能覆盖大部分冲突场景，实现成本低很多。

Decline 的处理逻辑要单独写：收到 Decline 后，从 reserved 或 allocated 里移除该地址，加入黑名单，记录时间戳。黑名单定期清理，过期的重新放回 available。这个设计让地址池有了一定的自愈能力，不会因为个别冲突地址反复被分配而影响整体。

6.2 日志与可观测性

自己写的服务器，日志就是唯一的排查手段，必须打全。我记录的字段包括：时间戳、消息类型、客户端 MAC、xid、分配的 IP、处理结果。日志格式用结构化的一行一条，方便 grep 和后续分析。关键决策点（比如为什么没分配到地址、为什么回 Nak）要打明确原因，不能只打"处理失败"。

def log_event(msg_type, mac, xid, ip, result): mac_str = ':'.join(f'{b:02x}' for b in mac) log.info(f'type={msg_type} mac={mac_str} xid={xid:08x} ip={ip} result={result}')

MAC 格式化用冒号分隔是惯例，排查时和抓包工具的输出对得上，省去转换的麻烦。xid 用十六进制打印，和抓包里的显示一致，方便交叉比对。

6.3 配置文件化与热加载

地址池范围、租期、网关、DNS、保留绑定这些参数，硬编码在代码里改起来麻烦，抽到配置文件里更实用。我用一个简单的 JSON 配置文件，启动时读取，结构清晰也方便版本管理。热加载不是必须的，但改配置后不用重启服务确实方便，实现上可以监听文件修改时间，变化时重新加载。不过热加载要小心并发问题，加载过程中如果有请求进来，可能读到半更新的配置，简单做法是加载时加锁，或者干脆只支持重启生效，看实际需求取舍。

配置里我建议把"排除地址段"单独列出来，和动态池分开。实际网络里网关、服务器、打印机这些固定设备往往集中在某几段，把这些段排除掉，动态池只覆盖真正需要自动分配的范围，冲突概率会低很多。

6.4 多网段与中继场景的简化处理

单网段环境实现起来简单，但真实网络经常有多网段，靠 DHCP 中继（relay）把请求转发到中心服务器。中继场景下，报文里的 giaddr 字段会被填上中继代理的地址，服务器要根据 giaddr 判断客户端在哪个网段，从对应的地址池分配。完整支持中继需要维护"网段到地址池"的映射，按 giaddr 查表选池。

如果只是学习目的，可以先不做中继，但代码结构上留好扩展点：把"选地址池"抽成一个函数，当前实现固定返回默认池，将来加中继时改成按 giaddr 查表即可。这样不用大改就能支持多网段，是个性价比很高的设计。

7. 关于这个项目的一点个人体会

写这个 DHCP 服务器的过程，最大的收获不是代码本身，而是对"二进制协议"这件事的理解变了。以前调库的时候，报文就是个黑盒，出问题只能猜；自己拼过字节、对过偏移、抓过包之后，再看任何基于 UDP 的协议，心里都有底了。尤其是选项区那种"码 + 长度 + 值"的 TLV 结构，在太多协议里反复出现，吃透一次，后面遇到类似的直接套。

如果让我给想动手的人一个建议，那就是先把抓包工具用熟，再写代码。我前期很多时间浪费在"不知道报文长什么样"上，后来养成先抓包看真实报文、再对照协议文档、最后写解析代码的习惯，效率高了一大截。另外，测试时准备一个能手动构造报文的客户端脚本，比用真实设备调试灵活得多，想测什么场景就构造什么报文，不用反复折腾设备。

代码层面，别一上来就追求功能全。先把 Discover-Offer-Request-Ack 这条主链路跑通，能分配地址、能续租，就已经覆盖了 80% 的使用场景。冲突检测、中继、热加载这些是锦上添花，等主链路稳了再逐个加，每加一个都单独测，出问题也好定位。这个项目我前后迭代了大概两周，真正卡住的地方都不是协议本身，而是广播收发、状态流转这些工程细节，慢慢磨就好了。