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租约层只认绑定记录职责清晰改起来也方便。下面这张表是我对四层职责和关键数据结构的梳理后面每个章节会逐个展开模块核心职责关键数据结构报文层二进制打包解包、选项编解码固定头部字段 options 字典地址池层地址范围管理、可用性判断起始/结束 IP、已用集合、保留集合租约层租期计算、状态流转、续租处理租约记录IP、MAC、到期时间、状态服务层socket 收发、报文分发、日志主循环 处理函数映射2. DHCP 报文的字节级结构拆解2.1 固定头部236 字节的硬骨头DHCP 报文的前 236 字节是固定结构字段顺序和长度都是写死的一个字节都不能错位。我一开始就是没仔细核对字段长度导致解析出来的 IP 全是乱码排查了半天才发现是某个字段多算了一个字节。所以这部分必须逐字段对照。固定头部的关键字段包括op1 字节标识请求或应答、htype1 字节硬件类型以太网是 1、hlen1 字节硬件地址长度MAC 是 6、hops1 字节跳数、xid4 字节事务 ID用来匹配请求和应答、secs2 字节客户端已用时间、flags2 字节标志位最高位表示是否要求广播应答、ciaddr/yiaddr/siaddr/giaddr各 4 字节分别是客户端地址、分配给客户端的地址、服务器地址、中继代理地址、chaddr16 字节客户端硬件地址MAC 只占前 6 字节后面补零、sname64 字节服务器名、file128 字节启动文件名。用 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 是 DNS51 是租期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 是 1Offer 是 2Request 是 3Decline 是 4Ack 是 5Nak 是 6Release 是 7Inform 是 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 False3.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 在 0xid 在 4yiaddr 在 16chaddr 在 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(ftype{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% 的使用场景。冲突检测、中继、热加载这些是锦上添花等主链路稳了再逐个加每加一个都单独测出问题也好定位。这个项目我前后迭代了大概两周真正卡住的地方都不是协议本身而是广播收发、状态流转这些工程细节慢慢磨就好了。