简介这套源码基于Java语言实现了DHCP协议服务端与客户端的核心交互流程完整覆盖发现、提供、请求、确认四个阶段并处理了广播地址、UDP端口及BOOTP报文格式等关键细节适合对网络协议和Java网络编程感兴趣的开发者学习。资源共含84个文件以16个Java源文件为骨干实现UDP通信、IP地址池管理、配置信息存储与多线程并发处理另有64个Javadoc生成的HTML文档按包和类清晰展示接口设计配套的样式表、属性文件及索引文件让本地阅读体验更加顺畅。整个压缩包仅186KB轻量而完整既可作为课程设计或技术研究的起点也能为自研网络管理工具提供借鉴。通过源码与文档对照可以掌握DHCP数据包编码与解码、服务器端线程安全设计、异常处理等实用思路这些正是综合性网络编程项目的核心难点。目前已有632人学习下载是一份兼顾协议原理与工程实现的参考资源。1. 为什么需要一份能直接改的 DHCP Java 源代码在做网络设备管理平台要给内网设备自动分配 IP这类人搜“DHCP Java 源代码”时往往带着具体诉求能看懂、能改、还能跑在 Java 后端而不是拿个 C 语言的嵌入式实现硬套。这份源码资源把 DHCP 协议从报文字节落到完整状态机包含报文解析、选项编码、客户端和服务端的核心交互链路。选 Java 写 DHCP 的一个现实原因是调试透明不用跟指针较劲UDP Socket API 直接处理广播包和单播包抓包和日志一对就能定位问题。同时编译产物可以直接集成进 Spring Boot、Netty 这类工程不额外引入跨平台编译的负担非常适合做网络课程设计、物联网网关后台或者需要内嵌 DHCP 能力的网络管理项目。下面按报文模型、状态机、选项与租约、排错、验证五段展开中间穿插源码包里的类设计思路和踩坑记录能抄的代码直接抄参数含义我会逐个解释。2. DHCP 报文模型与 Java 数据载体先拆清字节再写交互逻辑2.1 为什么选 Java 写 DHCP省掉的三类复杂度DHCP 实现选什么语言本质是场景问题。如果是嵌进路由器和交换机固件那 C 语言加原始套接字是绕不开的但如果是放到 Java 后台工程里或者只是为了把动态地址分配这套协议吃透用 Java 反而省掉不少麻烦。Java 标准库刚好正面覆盖 DHCP 的两项关键能力。第一项是 UDP 通信java.net.DatagramSocket直接绑定 67、68 两个端口收发字节数组不需要调用系统原生库。第二项是字节操作java.nio.ByteBuffer自带边界检查读指针越界直接抛异常不像 C 语言那样把内存读穿后才在某个角落炸出来。对 DHCP 这种“固定头 可变选项区”的报文ByteBuffer 天然比“指针 长度手动计算”安全。源码包里的类围绕两个对象展开DhcpPacket承载报文DhcpOption承载选项。解析报文、构造应答、记录租约都在这两个对象上操作后面的例子也沿用这套命名。2.2 固定头 236 字节对照表与边界判断DHCP 报文固定头从 BOOTP 继承而来总共 236 字节之后再进入选项区。下面这张表是实现时逐字节拆包的基础字段顺序不能乱偏移算错一个后面全部错位。字段偏移长度含义op011 表示客户端请求2 表示服务端应答htype11硬件类型1 表示以太网hlen21硬件地址长度以太网 MAC 是 6PPPoE 是 8hops31经过 DHCP 中继时的跳数直连场景填 0xid44事务 ID客户端每次请求随机生成secs82客户端开始获取地址以来的秒数flags102第 15 位为 1 时要求服务器广播应答ciaddr124客户端已知自己的 IP 时才非 0yiaddr164服务器打算分配给客户端的 IPsiaddr204服务器 IPgiaddr244中继代理 IP直连场景为 0chaddr2816客户端 MAC 地址sname4464服务器名可选不用则全 0file108128启动文件名可选不用则全 0options236可变前 4 字节固定为 magic cookie这表里最容易混淆的是ciaddr和yiaddr。ciaddr是客户端在已知自己 IP 时填的比如续租阶段yiaddr是服务器在 OFFER 和 ACK 阶段填的分配地址。解析时千万别把两个 4 字节字段读反读反之后租约表里绑定的 IP 就全是乱的。2.3 从字节到对象DhcpPacket 解析方法与无符号陷阱解析代码放在DhcpPacket.parse(byte[])静态方法里入参是 UDP 收上来的完整报文数据返回一个填充好字段的对象解析失败直接抛异常。import java.nio.ByteBuffer; import java.nio.ByteOrder; import java.util.ArrayList; import java.util.List; public class DhcpPacket { public static final int FIXED_HEADER_LEN 236; public static final int MAGIC_COOKIE 0x63825363; public static final int PORT_SERVER 67; public static final int PORT_CLIENT 68; private byte op; private byte htype; private byte hlen; private byte hops; private int xid; private short secs; private short flags; private byte[] ciaddr new byte[4]; private byte[] yiaddr new byte[4]; private byte[] siaddr new byte[4]; private byte[] giaddr new byte[4]; private byte[] chaddr new byte[16]; private byte[] sname new byte[64]; private byte[] file new byte[128]; private ListDhcpOption options new ArrayList(); public static DhcpPacket parse(byte[] data) throws Exception { if (data.length FIXED_HEADER_LEN 4) { throw new IllegalArgumentException(报文长度不足固定头和 magic cookie 都不够); } ByteBuffer bf ByteBuffer.wrap(data).order(ByteOrder.BIG_ENDIAN); DhcpPacket pkt new DhcpPacket(); pkt.op bf.get(); pkt.htype bf.get(); pkt.hlen bf.get(); pkt.hops bf.get(); pkt.xid bf.getInt(); pkt.secs bf.getShort(); pkt.flags bf.getShort(); bf.get(pkt.ciaddr); bf.get(pkt.yiaddr); bf.get(pkt.siaddr); bf.get(pkt.giaddr); bf.get(pkt.chaddr); bf.get(pkt.sname); bf.get(pkt.file); int cookie bf.getInt(); if (cookie ! MAGIC_COOKIE) { throw new IllegalArgumentException(magic cookie 不匹配收到的不像是 DHCP 报文); } while (bf.hasRemaining()) { int tag bf.get() 0xff; if (tag 0) { continue; // 填充字节直接跳过 } if (tag 255) { break; // 结束标记 } if (bf.remaining() 1) { break; } int len bf.get() 0xff; if (len bf.remaining()) { break; // 长度越界按截断处理 } byte[] value new byte[len]; bf.get(value); pkt.options.add(new DhcpOption(tag, value)); } return pkt; } }这段代码有两个容易写错的位置。第一是ByteBuffer要显式设置ByteOrder.BIG_ENDIANDHCP 报文头所有多字节字段都是网络字节序虽然 Java 默认也是大端但写明之后换到别的报文格式时不会惯性出错。第二是选项区的tag和len必须按无符号读因为 Java 的byte是带符号的如果tag 255直接拿来判断在 Java 里它其实是-1和break的条件对不上循环就把结束标记当普通选项处理后面全乱套。提示data.length 240这种判断别省掉。UDP 收到的不一定是 DHCP有可能长度只有几十字节的杂包不先挡掉这一层后面ByteBuffer.getInt()会抛BufferUnderflowException而且异常栈不好排查。3. 客户端与服务端状态机从 DISCOVER 到 ACK 的核心链路3.1 四报文交互链路与状态转换DHCP 分配地址不是一问一答而是四个报文串起来的完整链路。客户端广播 DISCOVER 寻找网络里的服务器所有收到广播的服务器各自预留地址并回应 OFFER客户端挑其中一台再广播 REQUEST 确认“我要用这台给的地址”被选中的服务器回 ACK其余服务器释放预留。客户端侧状态机用枚举管理最直观public enum DhcpClientState { INIT, // 初始准备发 DISCOVER SELECTING, // 已发 DISCOVER等待 OFFER REQUESTING, // 已发 REQUEST等待 ACK BOUND, // 已拿到地址正常运行 RENEWING, // T1 时间到单播续租 REBINDING // T2 时间到广播续租 }每个状态对应一套处理逻辑状态转换的触发条件是收到某个报文或某个定时器到期。把时序画成代码就是INIT收到 OFFER 进REQUESTINGREQUESTING收到 ACK 进BOUNDBOUND的 T1 计时器触发进RENEWINGT2 触发进REBINDING续租失败重新回到INIT。3.2 服务器端 UDP 监听循环绑定地址和 XID 匹配服务器端的主循环是阻塞收包收到一个请求就按消息类型分发处理。这里有个关键参数DatagramSocket要绑定0.0.0.0:67而不是绑到本机某个具体网卡的 IP。服务器经常有多个网卡绑定具体 IP 会漏掉从其他网卡进来的广播包。import java.net.DatagramSocket; import java.net.DatagramPacket; import java.net.InetAddress; import java.util.Arrays; import java.util.concurrent.ConcurrentHashMap; import java.util.Map; public class DhcpServer implements Runnable { private final MapInteger, String offerCache new ConcurrentHashMap(); private volatile boolean running true; Override public void run() { try (DatagramSocket socket new DatagramSocket(DhcpPacket.PORT_SERVER, InetAddress.getByName(0.0.0.0))) { System.out.println(DHCP server listening on udp/67); while (running) { byte[] buf new byte[576]; DatagramPacket req new DatagramPacket(buf, buf.length); socket.receive(req); byte[] raw Arrays.copyOf(req.getData(), req.getLength()); DhcpPacket pkt DhcpPacket.parse(raw); DhcpOption typeOpt findOption(pkt.getOptions(), 53); if (typeOpt null || typeOpt.getValue().length ! 1) { continue; } int msgType typeOpt.getValue()[0] 0xff; switch (msgType) { case 1: // DISCOVER handleDiscover(socket, pkt); break; case 3: // REQUEST handleRequest(socket, pkt); break; case 7: // RELEASE handleRelease(pkt); break; default: break; } } } catch (Exception e) { e.printStackTrace(); } } private DhcpOption findOption(ListDhcpOption options, int tag) { for (DhcpOption opt : options) { if (opt.getTag() tag) { return opt; } } return null; } }单线程同步处理只适合演示和低负载场景真实部署时socket.receive之后应该丢给线程池处理但要注意DatagramSocket的receive和send不是线程安全的要并发就得每个工作线程各自持有独立的 socket或者加锁这不是玄学是网上很多并发版 DHCP 服务器翻车的地方。XID 匹配是整个交互能对上的基础。客户端发出 DISCOVER 时生成一个随机xid服务器回 OFFER 时xid原样带回等客户端广播 REQUEST 时xid还是同一个。我实际用ConcurrentHashMapInteger, String offerCache记录这个关系key是xidvalue是预留的 IP 字符串服务器收到 REQUEST 后先查这张表查不到就直接 NAK。注意OFFER 只是预留不是确认。如果客户端广播了 DISCOVER服务器回了 OFFER但客户端随后没发 REQUEST这个预留地址必须能释放。最简单的做法是给offerCache存一个带过期时间的条目过期自动删除否则地址池很快被“跑路”的 OFFER 占满。4. 选项编解码与租约管理最容易翻车的两块逻辑4.1 选项是 TLV 结构编解码方法别按数组操作写DHCP 选项区是典型的 TLV 编码Type-Length-Value一个接一个排列。选项 53 是消息类型一个字节选项 54 是服务器标识四个字节的 IP选项 51 是租约时长四个字节的秒数。写编码的时候最容易犯的错是不按长度算直接把整个字节数组怼进去。public class DhcpOption { public static final int OPTION_SUBNET_MASK 1; public static final int OPTION_ROUTER 3; public static final int OPTION_DNS 6; public static final int OPTION_REQUEST_IP 50; public static final int OPTION_LEASE_TIME 51; public static final int OPTION_MESSAGE_TYPE 53; public static final int OPTION_SERVER_ID 54; public static final int OPTION_CLIENT_ID 61; private int tag; private byte[] value; public void writeTo(java.nio.ByteBuffer bf) { if (tag 0 || tag 255) { bf.put((byte) tag); return; } bf.put((byte) tag); bf.put((byte) value.length); bf.put(value); } public static int readInt(byte[] v) { if (v.length ! 4) { return 0; } return ((v[0] 0xff) 24) | ((v[1] 0xff) 16) | ((v[2] 0xff) 8) | (v[3] 0xff); } }选项编码有一个边界要盯死value.length强制转成byte的时候如果长度超过 255 就会被截断。DHCP 选项标准规定单条选项长度最大 255所以读入时发现长度超大优先怀疑报文被污染或解析偏移错位而不是硬着头皮继续处理。一个实际场景服务器组装 ACK 报文时选项区里至少要包含消息类型53、服务器标识54、子网掩码1、租约时长51有需要再加默认网关3和 DNS6。组装顺序通常把 53 放最前面因为很多 DHCP 客户端实现是顺序解析选项遇到 53 才知道当前报文应当按哪种行为处理。4.2 租约仓库内存表、过期扫描与冲突检测租约是整个 DHCP 服务器的核心数据谁在什么时间拿了哪个 IP、什么时候到期全都记录在案。内存实现用两张ConcurrentHashMap互相索引一张按 MAC 查租约一张按 IP 查租约。public class LeaseRepository { private final MapString, Lease byMac new ConcurrentHashMap(); private final MapString, Lease byIp new ConcurrentHashMap(); public Lease offer(String mac, String ip) { long now System.currentTimeMillis(); Lease lease new Lease(mac, ip, now, now 3600_000L); byMac.put(mac, lease); byIp.put(ip, lease); return lease; } public Lease getByMac(String mac) { return byMac.get(mac); } public Lease getByIp(String ip) { return byIp.get(ip); } public void release(String mac) { Lease lease byMac.remove(mac); if (lease ! null) { byIp.remove(lease.getIp()); } } public void reapExpired() { long now System.currentTimeMillis(); byMac.values().removeIf(l - l.getExpireAt() now); } }内存租约表最大的坑是双 Map 一致性。只删了byMac不删byIp地址池里这个 IP 就永远不可用冲突检测的时候还查得到它。release方法里先移byMac拿到刚移除的租约再去删byIp这个顺序不能反如果先删byIp再删byMac万一byMac.remove返回空byIp那条就成了孤儿数据。地址分配前的冲突检测是另一个绕不开的点。常见做法是分配前先getByIp判断租约表里有没有占用但只查表不够还要用 ICMP Echo 探测一下目标 IP 是否有设备响应。注意这个探测要用短超时一般 500 毫秒以内探测时间过长会让 DISCOVER 的应答延迟到客户端超时用户感知就是“分配 IP 慢”。提示租约时长按秒为单位存在选项 51 里Lease对象里的expireAt用毫秒时间戳转换时别把单位搞混。我曾经在一个项目里把选项 51 直接当成毫秒写进去结果客户端拿到 1 秒租约不到一秒就续租日志刷屏排查半天才发现是单位问题。5. DHCP 实现避坑指南五个让我熬夜的翻车现场5.1 报文解析阶段的坑偏移量、无符号、magic cookie先说第一个坑现象是抓包工具里看 DHCP 请求完全正常代码一解析就抛“magic cookie 不匹配”。原因很朴素options 区紧跟在固定头之后固定头是 236 字节而 magic cookie 占了 options 区的前 4 字节。我最初解析时没跳过那 4 个字节直接把 offset 236 处当成选项的 tag取到的当然不是合法的0x63825363后面自然全乱。解决方式是严格按长度校验先判断data.length 240再读前 4 字节比对 cookie之后再进入 TLV 循环。第二个坑解析出来的选项 50请求 IP值一直和抓包结果对不上。原因是 Java 的byte有符号直接从字节数组里拿tag和len不转无符号遇到 128 以上的值就变负数长度判断和后续的new byte[len]会抛NegativeArraySizeException。解决方式已经写进前面的代码int tag bf.get() 0xffint len bf.get() 0xff这个 0xff不是可有可无是必须要的。第三个坑在hlen字段上。默认写 6 是标准以太网 MAC 长度解析时按 6 字节从chaddr里取 MAC 绑定租约表。但如果客户端走的是 PPPoEhlen是 8你按 6 取就会把 MAC 取错租约表里绑定的地址全是残缺的。解决方式是按hlen动态读取不要写死读完之后再判断一个合法区间6 到 16 之间才继续处理。5.2 交互与租约阶段的坑广播、并发、重启恢复第四个坑服务器端回 OFFER 和 ACK 时目标地址选错。现象是客户端能发 DISCOVER却永远收不到服务器的回应Wireshark 里能看到请求包看不到应答包。原因是响应包被发到了单播地址而客户端此时还没拿到 IP根本收不到。正确逻辑要看请求里的flags字段第 15 位为 1 时响应必须走广播255.255.255.255:68只有客户端在续租阶段有了ciaddr才能安全走单播。我一般的做法是统一走广播牺牲一点网络流量换兼容性单播优化留到性能测试阶段再做。第五个坑服务器重启后租约丢失全网设备短时间集体断线重连。内存租约表在进程退出那一刻就清空了重启后地址池认为所有地址空闲但终端上还保留着旧 IP直到它们发起续租被服务器 NAK再重新走完整流程。解决方式是租约持久化最简单的是把租约记录定期序列化到本地文件启动时加载回内存。加载时要重新检查一遍过期时间和冲突不要盲目信任旧数据。注意客户端 DHCP 续租失败不会立刻崩它会等 T2 计时器到期后重新广播 DISCOVER整个过程持续约 1 分半。所以排查“重启后断网”时别盯着应用日志猛看先确认租约持久化是否真的加载进去了。6. 验证与进阶用 Wireshark 和虚拟网卡把实现打磨到敢上线6.1 抓包确认四报文顺序验证 DHCP 实现最直接的方式就是抓包。Wireshark 里过滤器直接输bootpDHCP 的协议名在抓包里沿用 BOOTP 的称呼所有 DISCOVER、OFFER、REQUEST、ACK 报文都会列出来。想只看消息类型可以用bootp.option.type 53配合bootp.option.value来过滤。一次干净的抓包必须看到四步走的完整链路顺序不能乱序号报文方向关键字段1客户端 → 广播op1xid随机值option 531(DISCOVER)2服务器 → 广播/单播op2xid 与请求一致option 532(OFFER)3客户端 → 广播op1xid 仍一致option 533(REQUEST)带 option 50 请求地址4服务器 → 广播/单播op2xid 不变option 535(ACK)看抓包的时候重点核对两件事第一是 OFFER 和 ACK 的xid是否和 DISCOVER 一致不一致就是服务器端写死了一个全局固定 xid这在多客户端环境下会互相串台。第二是 ACK 报文的yiaddr是否和 REQUEST 里 option 50 请求的地址一致不一致客户端会拒收然后重新走流程表现就是抓包里有大量重复的 DISCOVER。6.2 用虚拟环境做回归测试我用 VirtualBox 的 host-only 网络做回归测试关闭 VirtualBox 自带 DHCP把 Java DHCP 服务器跑在宿主机虚拟机的网卡改成 DHCP 自动获取然后反复刷新租约验证稳定性。脚本化之后连续跑 100 次请求统计 ACK 成功率#!/bin/bash # 连续 100 次续租, 统计 DHCPACK 次数, 低于 100 说明有丢包 success0 for i in $(seq 1 100); do sudo dhclient -r ens38 2/dev/null sudo dhclient -1 ens38 21 | grep -q DHCPACK success$((success 1)) done echo success: $success/100这个脚本的意义在于暴露时序类问题删除旧租约、重新申请、服务器端释放旧租约这三个动作之间只要有一个没处理好成功率就达不到 100。我在这条命令上吃过亏所以从那以后每次实现完 DHCP都强制走一遍“重启服务 → 清客户端租约 → 连续触发 100 次获取 → 核对租约表里每一行过期时间”的流程跑通了才敢说这个实现能交付。希望帮到你。本文还有配套的精品资源点击获取