簡介面向DHCP協(xié)議與Java網(wǎng)絡編程開發(fā)者提供一套可直接運行的DHCP服務器與客戶端源代碼適合用于課程設計、畢業(yè)設計以及企業(yè)內(nèi)網(wǎng)管理工具的二次開發(fā)參考。壓縮包共84個文件大小僅186KB其中包含16個Java源文件作為核心實現(xiàn)代碼64個HTML格式的Javadoc頁面用于查閱類與接口說明另含CSS樣式、properties配置和GIF圖片等輔助文件整體結(jié)構清晰便于按需取用。代碼完整實現(xiàn)了DHCP發(fā)現(xiàn)、提供、請求、確認四個階段讀者可學習到基于UDP廣播的報文交互、BOOTP協(xié)議的編解碼方式以及服務器端多線程并發(fā)處理和IP地址池的動態(tài)分配策略。通過閱讀源碼和文檔既能掌握DatagramSocket、NIO等網(wǎng)絡編程技巧也能理解真實協(xié)議落地時的異常處理、配置存儲等工程問題為深入網(wǎng)絡協(xié)議開發(fā)打下基礎。截至當前已有632人學習使用是一份實用且輕量的協(xié)議源碼學習資料。1. 當你的設備拿不到 IPJava 手寫 DHCP 到底在做什么排查網(wǎng)絡時最讓人血壓飆升的場景之一就是終端瘋狂廣播 DHCP Discover 卻始終收不到 Offer。抓包一看服務器根本沒回應或者回應了但報文格式錯得離譜。這時候你如果能有一份 Java 實現(xiàn)的 DHCP 源代碼在手可以直接在 JVM 里跑起來調(diào)試比反復翻 RFC 2131 和路由器日志要直觀得多。DHCP 協(xié)議本身不復雜復雜的是 UDP 廣播、報文選項解析、租約狀態(tài)機這些細節(jié)在 Java 里怎么落地。這個方向的價值在于它不是讓你去替代現(xiàn)成的 dhcpd 或路由器內(nèi)置服務而是幫你理解協(xié)議交互的每一幀報文、每一個狀態(tài)轉(zhuǎn)換。無論是做網(wǎng)絡設備模擬器、接入認證系統(tǒng)、還是在測試環(huán)境里模擬 DHCP 攻擊與防護場景一份能跑的 Java 源碼都是最直接的學習和調(diào)試工具。適合的人群是網(wǎng)絡協(xié)議棧開發(fā)者、物聯(lián)網(wǎng)設備接入層的工程師以及那些在面試里被問到「DHCP 報文是怎么組裝和解析的」之后想弄個明白的 Java 后端。2. 實現(xiàn)前必須吃透的 DHCP 報文結(jié)構從 BOOTP 到選項域的字節(jié)級拆解2.1 為什么 DHCP 報文要用字節(jié)數(shù)組硬拼而不是 JSON 或?qū)ο罅骱芏嗳藙偵鲜謺r第一反應是我需要一個 DHCP 報文類把 op、htype、xid 這些字段用 Java 對象表示然后序列化。這個方向沒錯但注意 DHCP 報文在網(wǎng)絡上傳輸時就是純字節(jié)流而且它沒有現(xiàn)成的 Java 序列化協(xié)議必須按 RFC 2131 規(guī)定的固定偏移量逐字節(jié)塞進去。報文頭固定部分只有 236 字節(jié)從 op 字段到 sname 的 64 字節(jié)加上 file 的 128 字節(jié)后面接著的是 64 字節(jié)的 options 區(qū)。這里的第一個坑是你用的 ByteBuffer 是 Big-Endian 字節(jié)序而 DHCP 報文里絕大多數(shù)多字節(jié)字段比如 yiaddr、ciaddr都是網(wǎng)絡字節(jié)序也就是 Big-Endian。這意味著直接調(diào)用ByteBuffer.wrap()然后putInt()是安全的但如果你為了取某個字段用getInt()時忘記考慮緩沖區(qū)位置就會讀到錯位的數(shù)據(jù)。常見的實現(xiàn)方式是寫一個專門的 DHCPPacket 類內(nèi)部持有byte[] packet對外提供getOp()、setOp()之類的訪問方法。這樣在解碼時不需要反復 copy 字節(jié)直接對底層數(shù)組按偏移量操作。我一般還會內(nèi)置一個parseOptions()方法把 options 區(qū)從 240 字節(jié)偏移開始循環(huán)讀取先讀 option code1 字節(jié)如果是 0 是 padding如果是 255 是 end否則讀長度再讀值。這個循環(huán)邏輯是整個解析器最容易出錯的地方原因在于你必須在讀 code 前判斷剩余長度是否至少為 2code len否則直接拋異常。2.2 報文類型選項53 號選項和事務 ID區(qū)分 Discover / Offer / Request 的分水嶺如果你只是在網(wǎng)絡上抓包看源端口 68 和 67 就能猜出大概。但代碼要處理的是具體邏輯分支Discover類型 1、Offer類型 2、Request類型 3、Ack類型 5、Nak類型 6這些行為全靠 options 區(qū)里的第 53 號選項區(qū)分。byte類型取值有符號的問題在這里就暴露了。Java 里的byte是 -128 到 127而 DHCP 報文里某個 code 可能是 0x80 甚至 0xFF。如果你寫int code buffer[index]你會得到一個負數(shù)比如 0xFF 變成 -1。正確做法是int code buffer[index] 0xFF。這一點不著重說明后面的報文解析一定會翻車。事務 ID 是 xid 字段4 字節(jié)由客戶端隨機生成。服務器在回復時原樣帶回 xid客戶端用它匹配請求和響應。在 Java 里你用SecureRandom.nextLong()然后截取低 32 位就可以。注意不要用Math.random()去生成因為它在高并發(fā)或多次快速重啟時可能重復導致客戶端把舊 Offer 當成新 Offer。2.3 租約時間、子網(wǎng)掩碼、網(wǎng)關和 DNS選項的讀寫順序決定兼容性拿到選項值之后你要按標準順序把它們編碼回去。常見的順序是53報文類型、 server identifier54、 lease time51、 subnet mask1、 router3、 dns6。有些舊客戶端對選項順序敏感比如 Windows 老版本 DHCP 客戶端必須把 53 號選項放在最前面否則直接丟棄報文。選項值里額外要留意的是 IP 地址數(shù)組的對齊router 選項3和 DNS 選項6都是可以包含多個 IP 的列表以 4 字節(jié)為間隔。讀取時要循環(huán)讀滿length才算完不能只讀第一個。寫入時同樣按 4 字節(jié)一組。租約時間51 號是 4 字節(jié)整數(shù)單位是秒不能錯成毫秒否則客戶端會在幾小時內(nèi)以為租約到期瘋狂續(xù)租。提示寫一個獨立的DhcpOption類字段包括 code、length、byte[] data。解析時先把 options 全部拆成若干 DhcpOption 對象再按 code 去查而不是在讀循環(huán)里當場做分支處理。這樣的設計避免后續(xù)新增選項時改一大段解析代碼。3. 從零寫最小 DHCP 服務器UDP 廣播收發(fā)與租約管理的完整 Java 代碼3.1 綁定 67 端口監(jiān)聽廣播Socket 選項和網(wǎng)絡接口選擇DHCP 服務器監(jiān)聽 UDP 67 端口客戶端從 68 端口發(fā)送。在 Java 里這不是普通的DatagramSocket因為你希望收到發(fā)往 255.255.255.255 的廣播包。先看最精簡的監(jiān)聽代碼import java.net.DatagramPacket; import java.net.DatagramSocket; import java.net.InetAddress; import java.net.SocketException; public class DhcpServerSocket { private DatagramSocket socket; private InetAddress broadcastAddress; public DhcpServerSocket(int port, String broadcastIp) throws SocketException { // 廣播地址由網(wǎng)卡配置決定通常取 255.255.255.255 或子網(wǎng)定向廣播 this.broadcastAddress InetAddress.getByName(broadcastIp); // 第一個參數(shù)為端口第二個參數(shù)為綁定的本地地址null 表示所有地址 this.socket new DatagramSocket(port, null); // 允許廣播這步不做會收不到 255.255.255.255 的報文 socket.setBroadcast(true); // 加大接收緩沖區(qū)防止瞬間大量 Discover 導致丟包 socket.setReceiveBufferSize(64 * 1024); } public DatagramPacket receive() throws Exception { byte[] buf new byte[1500]; DatagramPacket packet new DatagramPacket(buf, buf.length); socket.receive(packet); return packet; } public void send(byte[] data, int length, InetAddress destIp, int destPort) throws Exception { DatagramPacket reply new DatagramPacket(data, length, destIp, destPort); // 目標端口固定為 68客戶端監(jiān)聽端口 socket.send(reply); } }參數(shù)說明new DatagramSocket(port, null)中的 null 代表綁定到所有網(wǎng)卡。如果你的機器有多塊網(wǎng)卡只希望在特定網(wǎng)卡上服務這里可以傳InetAddress.getByName(192.168.1.100)。setBroadcast(true)是為了能夠向廣播地址發(fā)送回復包不設置就只能單播。監(jiān)聽端口時如果提示Address already in use在 Linux 上可以用setsockopt的 SO_REUSEADDR 解決但 Java 里沒有直接暴露這個選項最簡單的辦法是確認沒有其他 DHCP 服務占著 67 端口。3.2 解析 Discover 報文并組裝 Offer一個完整的請求處理鏈路收到 Discover 后你要做的是讀取客戶端 MACchaddr 字段從偏移 28 開始16 字節(jié)根據(jù) MAC 查租約表分配一個空閑地址然后組裝 Offer 報文。下面這段代碼集中展示了核心處理流程public class DhcpRequestHandler { // 租約表MAC - IP 和過期時間 private final MapString, Lease leaseMap new ConcurrentHashMap(); // 可用 IP 池用隊列模擬分配 private final QueueString addressPool; public DhcpRequestHandler(ListString poolAddresses) { addressPool new LinkedList(poolAddresses); // 啟動一個定時線程定期清理過期租約 Executors.newSingleThreadScheduledExecutor() .scheduleAtFixedRate(this::cleanupExpiredLeases, 60, 60, TimeUnit.SECONDS); } public byte[] handleDiscover(byte[] requestPacket) { // 1. 解析客戶端 MAC包偏移 28 處長度 6但 chaddr 字段是 16 字節(jié) byte[] chaddr Arrays.copyOfRange(requestPacket, 28, 44); String macKey toMacString(chaddr); String offeredIp leaseMap.containsKey(macKey) ? leaseMap.get(macKey).ipAddress : allocateIp(macKey); if (offeredIp null) { return null; // 地址池耗盡 } // 2. 構造 Offer 報文的基礎字段 byte[] response new byte[240]; // 只占固定頭選項在后面追加 response[0] (byte) 0x02; // op: BOOTREPLY response[1] (byte) 0x01; // htype: Ethernet response[2] (byte) 0x06; // hlen: MAC 地址長度 // 復制 xid客戶端用這個字段匹配 Offer System.arraycopy(requestPacket, 4, response, 4, 4); // yiaddr 字段從偏移 16 開始填入分配的 IP byte[] ipBytes ipToBytes(offeredIp); System.arraycopy(ipBytes, 0, response, 16, 4); // 復制客戶端 MAC 到 chaddr System.arraycopy(chaddr, 0, response, 28, 6); // 3. 追加 options53 號報文類型 Offer、54server id、1掩碼、51租約 ByteBuffer options ByteBuffer.allocate(256); options.put((byte) 53).put((byte) 1).put((byte) 2); // Offer 類型 options.put((byte) 54).put((byte) 4) .put(ipToBytes(192.168.1.1)); // 服務器自身 IP options.put((byte) 1).put((byte) 4) .put(ipToBytes(255.255.255.0)); options.put((byte) 51).put((byte) 4) .putInt(7200); // 租約 2 小時 options.put((byte) 255); // End 選項 byte[] responseWithOptions new byte[240 options.position()]; System.arraycopy(response, 0, responseWithOptions, 0, 240); System.arraycopy(options.array(), 0, responseWithOptions, 240, options.position()); return responseWithOptions; } private String allocateIp(String mac) { // 簡化實現(xiàn)從隊列取地址不考慮釋放問題 String ip addressPool.poll(); if (ip ! null) { leaseMap.put(mac, new Lease(ip, System.currentTimeMillis() 7200_000L)); } return ip; } }邏輯說明handleDiscover的輸入是整個 UDP 報文的有效載荷字節(jié)數(shù)組。第一步解析 chaddr 時注意只取前 6 字節(jié)做 MAC因為 Ethernet 的 hlen 是 6但報文里該字段長度是 16 字節(jié)剩余部分為零填充。response[0] 0x02表示這是 BOOTREPLY而請求包對應值是 0x01BOOTREQUEST。xid 必須從請求包偏移 4 的位置復制 4 字節(jié)否則響應對不上客戶端。Options 的組裝用了ByteBuffer且每個 option 的格式是 code length value。長度字段必須是實際字節(jié)數(shù)比如 51 號 option 的租約時間是 4所以先put((byte) 4)再putInt(7200)。positon()返回當前寫入位置作為 options 區(qū)總長度。這種寫法比逐字節(jié)往一個byte[]里塞要清晰調(diào)試時也方便中途打印。3.3 收到 Request 后回 Ack狀態(tài)機里的最后一步Offer 發(fā)出后客戶端會廣播一個 Request類型為 3。這時候服務器要做的是確認該 Request 中的 requested IP50 號選項確實是本服務器分配的然后回復 Ack。下面代碼展示如何處理 Requestpublic byte[] handleRequest(byte[] requestPacket) { // 1. 從 options 里找到 50 號選項取請求的 IP ByteBuffer options ByteBuffer.wrap(requestPacket, 240, requestPacket.length - 240); String requestedIp null; String serverIdentifier null; while (options.remaining() 0) { int code options.get() 0xFF; if (code 0) { continue; // padding } if (code 255) { break; } int len options.get() 0xFF; byte[] val new byte[len]; options.get(val); if (code 50) { requestedIp bytesToIp(val); // 客戶端請求的地址 } else if (code 54) { serverIdentifier bytesToIp(val); // 客戶端期望的服務器地址 } } // 2. 判斷是否應該由本服務器響應客戶端指定了其他 server id 則忽略 if (serverIdentifier ! null !serverIdentifier.equals(localServerIp)) { return null; } // 3. 校驗地址池里確實有這個地址且未分配給別人 if (!addressPool.contains(requestedIp) !isLeasedToClient(requestedIp)) { return null; } // 4. 組裝 Ack報文類型 5返回分配結(jié)果 byte[] ack buildReply(requestPacket, (byte) 5, requestedIp); return ack; }邏輯說明handleRequest里的循環(huán)解析 options特別要注意options.get()返回的是有符號字節(jié)這里用 0xFF規(guī)避負數(shù)問題。當客戶端拿到 Offer 后會發(fā) Request并把 50 號選項設成自己想要的 IP。如果網(wǎng)絡里有多個 DHCP 服務器同時收到了 Request客戶端會用 54 號選項指定它認可的服務器其他服務器看到 54 號不是自己就直接忽略。這一步邏輯不寫就會出現(xiàn)兩臺服務器同時回 Ack 的沖突場景。3.4 定時清理租約ConcurrentHashMap 怎么和地址池配合實際運行中客戶端釋放地址時的 Release 報文是單播發(fā)給服務器的所以handleRequest方法里還需要處理報文類型 7Release。Release 報文里含客戶端 IPciaddr 字段服務器拿到后把地址放回池子、從租約表刪除。但客戶端可能異常斷電永遠不發(fā) Release所以必須依賴租約過期機制。private void cleanupExpiredLeases() { long now System.currentTimeMillis(); for (Map.EntryString, Lease entry : leaseMap.entrySet()) { if (entry.getValue().expireTime now) { // 地址回收放回隊列尾部允許被重新分配 addressPool.offer(entry.getValue().ipAddress); leaseMap.remove(entry.getKey()); } } }這里的隱患是地址池用ConcurrentHashMap和LinkedList組合本身就不是線程安全的。cleanupExpiredLeases在獨立線程里跑而handleDiscover在主接收線程里也會操作addressPool。解決方式是給地址池操作加鎖或者直接用BlockingQueue并用ConcurrentHashMap記錄租約和到期時間。我在實際項目里會用ConcurrentHashMap存mac - ip的映射再用ConcurrentHashMapString, Long存ip - expireTime清理時同時刪兩個 map分配時用AtomicInteger做輪詢游標而不是直接 poll 隊列因為釋放和過期回收都會動態(tài)往隊列里放地址。private final AtomicInteger cursor new AtomicInteger(0); private final ListString allIps; // 固定列表初始化時排序好 private String allocateIp(String mac) { for (int i 0; i allIps.size(); i) { int idx Math.abs(cursor.getAndIncrement() % allIps.size()); String candidate allIps.get(idx); if (!leaseMap.containsKey(mac) !leasedIpSet.contains(candidate)) { leaseMap.put(mac, new Lease(candidate, System.currentTimeMillis() 7200_000L)); leasedIpSet.add(candidate); return candidate; } } return null; }參數(shù)說明allIps在初始化時從配置的網(wǎng)段展開比如192.168.1.100到192.168.1.200生成 101 個地址。cursor每次分配時累加再取模實現(xiàn)輪詢分配避免每次都從列表頭部開始找導致早期地址快被用光、后續(xù)地址閑置。leasedIpSet是一個SetString用來快速判斷地址是否已被占用否則每次都要遍歷租約表。4. 客戶端實現(xiàn)與抓包驗證三步確認你的 DHCP 協(xié)議棧沒寫歪4.1 構造 Discover 報文的細節(jié)68 端口和全零地址客戶端代碼比服務器少很多核心是構造 Discover 并發(fā)送到 255.255.255.255:67。關鍵約束是源端口必須是 68源 IP 可以是 0.0.0.0因為客戶端此時還沒有 IP。public class DhcpClient { private DatagramSocket socket; public void startDiscovery() throws Exception { socket new DatagramSocket(68, InetAddress.getByName(0.0.0.0)); socket.setBroadcast(true); socket.setSoTimeout(5000); // 5 秒收不到就超時 byte[] discover buildDiscoverPacket(); DatagramPacket pkt new DatagramPacket(discover, discover.length, InetAddress.getByName(255.255.255.255), 67); socket.send(pkt); // 等待 Offer,讀到報文后校驗 xid 與自己的匹配 byte[] buf new byte[1500]; DatagramPacket response new DatagramPacket(buf, buf.length); socket.receive(response); parseOffer(buf); } private byte[] buildDiscoverPacket() { byte[] packet new byte[240 4]; packet[0] (byte) 0x01; // BOOTREQUEST packet[1] (byte) 0x01; packet[2] (byte) 0x06; // xid: 4 字節(jié)隨機數(shù) int xid new SecureRandom().nextInt(); packet[4] (byte) (xid 24); packet[5] (byte) (xid 16); packet[6] (byte) (xid 8); packet[7] (byte) xid; // 自己的 MAC假設網(wǎng)卡 MAC 是 01:02:03:04:05:06 byte[] mac new byte[]{(byte) 0x01, (byte) 0x02, (byte) 0x03, (byte) 0x04, (byte) 0x05, (byte) 0x06}; System.arraycopy(mac, 0, packet, 28, 6); // options53 號選項 Discover1 packet[240] (byte) 53; packet[241] (byte) 1; packet[242] (byte) 1; packet[243] (byte) 255; // End return packet; } }邏輯說明new DatagramSocket(68, 0.0.0.0)綁定到 68 端口這樣收到的 Offer 會被操作系統(tǒng)路由到該 socket。xid 的生成用SecureRandom.nextInt()而不是Math.random()是為了避免在多線程場景下的重復性。注意把 xid 拆成 4 個字節(jié)的順序——Java 的 byte 是有符號的xid 24的結(jié)果 0~255賦值給 byte 時 0xFF 會變成 -1但在傳輸中字節(jié)序列是正確的因為二進制表達沒變。實際解析時用 0xFF再拼回 int 即可。4.2 收到 Offer 后如何提取租約信息ip 和 options 的解析順序在parseOffer中要依次做檢查 op 字段是否為 2、xid 是否匹配、拿到 yiaddr偏移 16 起的 4 字節(jié)、掃描 options 找 51 號租約時間和 54 號服務器標識。解析順序別看反了很多人先處理 options 后取 IP就會發(fā)現(xiàn) options 區(qū)的偏移計算有誤。private void parseOffer(byte[] response) { if (response[0] ! (byte) 0x02) { throw new IllegalStateException(不是 BOOTREPLY); } // 檢查 xid 是否匹配這里略去與發(fā)送時保存的 xid 比較 byte[] yiaddr Arrays.copyOfRange(response, 16, 20); String assignedIp InetAddress.getByAddress(yiaddr).getHostAddress(); // 掃描 options int offset 240; while (offset response.length) { int code response[offset] 0xFF; if (code 0) { offset; continue; } if (code 255) break; int len response[offset 1] 0xFF; byte[] value Arrays.copyOfRange(response, offset 2, offset 2 len); if (code 1) { // 子網(wǎng)掩碼 String mask bytesToIp(value); // 后續(xù)計算可用地址范圍會用到 } else if (code 3) { // 網(wǎng)關列表一個選項可能包含多個 IP for (int i 0; i value.length; i 4) { String gateway bytesToIp(Arrays.copyOfRange(value, i, i 4)); } } else if (code 51) { long leaseTimeSec ((long) (value[0] 0xFF) 24) | ((value[1] 0xFF) 16) | ((value[2] 0xFF) 8) | (value[3] 0xFF); // leaseTimeSec 單位是秒 } offset 2 len; } }參數(shù)說明租約時間如果直接用ByteBuffer.wrap(value).getInt()也可以但要注意getInt()會得到有符號 int最長租約 0xFFFFFFFF 會變成 -1。這里我演示了手工拼接的方式結(jié)果用 long 承接。網(wǎng)關選項按 4 字節(jié)一組遍歷時要小心 len 不是 4 的倍數(shù)這種畸形包用value.length / 4作為循環(huán)次數(shù)更穩(wěn)妥。4.3 用 Wireshark 對照驗證你寫的源碼和標準報文差在哪代碼寫完后別急著部署先在本地起服務器再起客戶端用 Wireshark 抓bootp或dhcp過濾。如果要驗證 Java 客戶端發(fā)的 Discover 是否規(guī)范抓包后看這幾個點檢查項正確值/行為常見錯誤源端口68錯寫成 67 或隨機端口目標端口67錯寫成 68op 字段1請求/ 2響應兩個方向搞反xid 一致性請求與響應相同響應時復制偏移搞成 8 或 12options 的 End 標記必須有 255 結(jié)尾漏掉后服務端解析會越界chaddr 填充前 6 字節(jié) MAC后 10 字節(jié)補 0直接 copy 16 字節(jié)導致把雜數(shù)據(jù)帶進去我習慣在寫代碼時加一段 debug 日志每次收到 / 發(fā)出的報文用 HexFormat 或DatatypeConverter.printHexBinary()把前 40 字節(jié)打出來。這樣不依賴 Wireshark 也能在控制臺里對著報文字段偏移人工校驗。提示如果你在 Windows 上跑 Java 服務端收到的廣播包源地址可能是 0.0.0.0而目標地址是 255.255.255.255。如果綁定 67 端口時報SocketException: Permission denied是因為非管理員進程無權綁定 1024 以下端口。開發(fā)時用 6767 端口調(diào)試需要聯(lián)調(diào)時再以管理員權限啟動。5. Java 實現(xiàn) DHCP 的 5 個高頻踩坑點與對應排查手段5.1 報文里大于 127 的字節(jié)變成負數(shù)解析全盤錯亂現(xiàn)象客戶端發(fā)來的 Discover 包服務器讀到選項 code 是負數(shù)比如 -128實際是 0x80然后直接數(shù)組越界或走錯分支。原因Java byte 是有符號類型0x80 到 0xFF 會被解釋為 -128 到 -1。你在int code buffer[offset]時沒做掩碼處理。解決所有從報文里讀單字節(jié)并轉(zhuǎn)成「無符號整數(shù)」的地方統(tǒng)一寫成buffer[offset] 0xFF。不要覺得這行代碼多余特別是在 options 循環(huán)、長度字段和 IP 地址首字節(jié)處。另外在把 int 寫成 byte 時比如packet[240] (byte) 53如果 int 值超過 127必須強轉(zhuǎn)否則編譯不通過。寫一個toUnsignedByte(int)工具方法可以減少重復出錯。5.2 廣播包收不到setBroadcast(true) 漏了或者網(wǎng)卡綁定錯了現(xiàn)象服務器啟動后沒有任何日志客戶端一直顯示發(fā)送成功但等不到 Offer。用 Wireshark 看服務器所在機器發(fā)現(xiàn)根本沒有收到包。原因有兩類。第一類是 Java 的DatagramSocket默認不接收廣播地址的包必須顯式socket.setBroadcast(true)。第二類是服務器綁定的 IP 和客戶端廣播到達的網(wǎng)卡不是同一個。如果機器有 eth0 和 eth1客戶端廣播從 eth1 進來但你綁定的是 eth0 的 IP內(nèi)核同樣會丟包。排查方法先臨時寫一段代碼打印本機所有網(wǎng)卡地址然后把new DatagramSocket(port, null)改成new DatagramSocket(port, InetAddress.getByName(0.0.0.0))保證綁定到所有接口。如果還不行用tcpdump -i any port 67在 Linux 上確認報文是否到達內(nèi)核。5.3 Options 解析越界漏了 padding 和 End 選項的處理現(xiàn)象服務器解析某些客戶端比如老舊設備發(fā)來的請求時代碼直接拋ArrayIndexOutOfBoundsException或讀到一個巨大的 len 值。原因DHCP 報文 options 區(qū)不是每次都恰好填滿 64 字節(jié)。RFC 2131 規(guī)定 options 區(qū)末尾以 255 結(jié)束但在它之前可能有一串值為 0 的 padding 選項。你的循環(huán)如果只看了 255 沒看 0或者認為 len 字段一定是合理的遇到 0 時把 padding 當普通選項的 code 和 len 去讀就會讀到錯亂的字節(jié)。解決循環(huán)里的處理順序必須是讀 code如果 code 0跳過當前字節(jié)繼續(xù)下一個如果 code 255立即結(jié)束否則再讀 len 并跳過 len 字節(jié)。注意不能把 padding 當 code 為 0 的選項因為 padding 沒有 len 字段。另外解析時要用offset 2 len packet.length做邊界保護一旦條件不滿足直接丟棄該包并記日志。5.4 客戶端對 Ack 不買賬Server Identifier 選項寫錯地址現(xiàn)象服務器日志顯示已發(fā)出 AckWireshark 也看到了但客戶端就是報錯或者客戶端狀態(tài)停在 Request 階段不進入 Bound。原因Ack 里必須包含 54 號選項Server Identifier且該值必須是服務器自身的 IP 地址。如果寫成 255.255.255.255 或者 0.0.0.0客戶端按 RFC 就認為這個 Ack 不合法。還有一種情況是服務器有多個 IP寫成了其中某個不是客戶端網(wǎng)關所在網(wǎng)段的地址客戶端可能無法路由這個單播 Ack。解決在組裝 Ack 時用DatagramPacket的getLocalAddress()或提前從網(wǎng)卡讀到的地址確保54號選項的值與收包時客戶端發(fā)來的目標地址段匹配。實在無法確定時用收到 Discover 報文的源地址所在子網(wǎng)推斷服務器該用哪個地址回復。5.5 租約過期后地址沒釋放cleanup 線程跑飛或者占用檢查漏了現(xiàn)象地址池明明只有 50 個地址跑了幾天后全部被占用新設備拿不到 IP。但檢查 DHCP 租約表很多租約早已過期。原因cleanupExpiredLeases方法里刪除 map 條目時沒有同步更新地址池。比如你把leaseMap.remove(entry.getKey())寫了卻忘了把 IP 放回addressPool。還有可能是在移除租約時遍歷的是 entrySet但后面又有新請求往同一個 key 寫入導致 remove 和 put 競爭。解決清理邏輯要和分配邏輯用同一個鎖。我習慣做法是把租約表和地址池封裝成一個LeaseManager類所有方法加synchronized或者直接用ReentrantLock。清理時先標記 IP 釋放再刪租約順序不能反否則中間態(tài)有分配線程可能拿到這個 IP 又被后續(xù)刪除動作誤傷。提示這些坑里前三個是 Java 獨有的后兩個是 DHCP 協(xié)議實現(xiàn)共有的。如果你在做自己的項目建議每解決一個坑就補一條單測比如構造一個含 padding 的畸形報文驗證解析器是否崩潰覆蓋這些場景后改代碼會安心很多。6. 讓實現(xiàn)可以上生產(chǎn)報文一致性校驗與性能壓測的小工具我的習慣是給 DHCP 服務器代碼加一個獨立的「報文自檢」入口用真實的客戶端抓包文件回放而不是每次手動敲命令。流程是先用 Wireshark 把真實環(huán)境的 Discover 和 Request 報文導出為二進制文件然后用 Java 程序讀取每個包并調(diào)用你自己的解析邏輯最后把輸出的 Offer/Ack 再與 Wireshark 里抓到的真實響應逐字節(jié)對比。核心校驗代碼可以寫成一個獨立方法public boolean validatePacket(byte[] packet, int maxLength) { if (packet.length 240 || packet.length maxLength) { return false; } // op 只能是 1 或 2 if ((packet[0] 0xFF) ! 1 (packet[0] 0xFF) ! 2) { return false; } // htype 為 1 時 hlen 必須是 6 if (packet[1] 1 (packet[2] 0xFF) ! 6) { return false; } // 掃描 options驗證每個 option 都不越界 int offset 240; while (offset packet.length) { int code packet[offset] 0xFF; if (code 0) { offset; continue; } if (code 255) break; if (offset 1 packet.length) return false; int len packet[offset 1] 0xFF; if (offset 2 len packet.length) return false; offset 2 len; } return true; }運行單測時我把抓到的包分兩類合法報文和畸形報文。合法報文必須通過校驗畸形報文必須被拒絕。這個校驗器本質(zhì)上就是你的防御性編程的集中體現(xiàn)值很值得維護。有了能跑通的核心邏輯和校驗器下一步建議做一次壓力測試。用循環(huán)線程模擬 500 個客戶端同時啟動ExecutorService pool Executors.newFixedThreadPool(50); CountDownLatch startSignal new CountDownLatch(1); for (int i 0; i 500; i) { final int clientId i; pool.submit(() - { try { startSignal.await(); DhcpClient client new DhcpClient(); client.setMac(randomMac(clientId)); client.startDiscovery(); } catch (Exception e) { System.err.println(client clientId failed: e.getMessage()); } }); } startSignal.countDown(); pool.shutdown();注意這里每個線程都創(chuàng)建獨立DatagramSocket綁定 68 端口這本身就會遇到端口沖突——多個進程不能同時綁同一個端口。所以在壓測時要讓客戶端隨機使用 68 到 70 范圍內(nèi)的端口或者用同一個 socket 串行發(fā)。更實際的做法是直接用服務端日志里的xid去重統(tǒng)計單位時間收到多少個不同 xid 的 Discover再用單線程代碼往服務器灌大量手工構造的 Discover 報文來測試吞吐。最后一個技巧把核心的報文組裝和解析邏輯與網(wǎng)絡收發(fā)解耦。網(wǎng)絡層可以換 Netty 的 DatagramChannel 或者 OIO 實現(xiàn)但解析和組裝是純函數(shù)式的輸入 byte[] 輸出 byte[]。這樣將來想把服務跑在 Vert.x 上或者遷移到 GraalVM 原生鏡像都不需要動協(xié)議代碼。我的個人習慣是任何時候都會以 Wireshark 抓包為最終真理寫完代碼先抓包對比 20 個請求再談可靠性。DHCP 看起來簡單但報文里的每個字節(jié)都有自己的脾氣希望這套實現(xiàn)思路能幫你少走幾個彎路。本文還有配套的精品資源點擊獲取