：自定義包頭校驗與圖片重組方案)
簡介這是一份面向Java網(wǎng)絡(luò)編程學(xué)習(xí)者與初學(xué)者的UDP圖片傳輸實戰(zhàn)示例聚焦UDP協(xié)議下圖片數(shù)據(jù)的分包發(fā)送與合包還原這一典型場景。資源通過客戶端將圖片轉(zhuǎn)為字節(jié)數(shù)據(jù)、附加鑒權(quán)信息后分包發(fā)送服務(wù)端對每個UDP包進行正確性校驗避免他人偽造或錯誤包被解析再將合法包合并還原為完整圖片幫助讀者理解UDP不可靠傳輸下的分包、校驗與重組思路。壓縮包共7個文件包含6個Java源碼與1份使用說明txt整體約5KB源碼按客戶端發(fā)送、服務(wù)端接收、UDP包頭封裝、文件工具等職責(zé)拆分結(jié)構(gòu)清晰便于對照閱讀。目前已有431人學(xué)習(xí)下載適合希望掌握J(rèn)ava UDP通信、數(shù)據(jù)校驗與圖片字節(jié)流處理的中級開發(fā)者參考也可作為課程設(shè)計或網(wǎng)絡(luò)實驗的練手素材。1. UDP 分包傳圖為什么我寧愿手寫校驗也不直接上 TCP前陣子幫一個做工業(yè)相機的朋友排查問題他們的設(shè)備通過 UDP 往服務(wù)器推圖片結(jié)果十張里有三張是花的還有兩張干脆打不開。抓包一看發(fā)送端把一張 200KB 的 JPEG 直接塞進一個 UDP 包IP 層分片后只要丟一片整張圖就廢了。這個udp_分包_和包.rar里的例子解決的正是這個場景客戶端把圖片轉(zhuǎn)成字節(jié)數(shù)組加鑒權(quán)頭切成固定大小的包發(fā)出去服務(wù)端逐包校驗、去重、按序合并最后還原成一張完整圖片。它適合兩類人一是正在用 UDP 做實時圖傳、又不想被 TCP 隊頭阻塞拖累的開發(fā)者二是想搞懂 UDP 應(yīng)用層分包到底該怎么設(shè)計校驗和重組邏輯的學(xué)習(xí)者。Java 寫的六個源文件加一份說明結(jié)構(gòu)不復(fù)雜但把「怎么保證收到的包是自己的、且沒壞」這件事講得比較透。2. 拆開這個包六個 Java 文件各自扛什么活2.1 從文件清單反推模塊職責(zé)拿到一個源碼包我習(xí)慣先看文件命名和數(shù)量基本能猜出架構(gòu)。這個包里六個 Java 文件加一個說明文檔分工很清晰文件名推測職責(zé)關(guān)鍵點SendUdp.java客戶端入口讀圖、轉(zhuǎn)字節(jié)、調(diào)分包邏輯SendAccept.java客戶端發(fā)送確認(rèn)處理服務(wù)端回執(zhí)或重傳BasicUdpRemoteRequestBuffer.java緩沖區(qū)管理按 remote 地址緩存分片UdpHeader.java自定義包頭鑒權(quán)、序號、總包數(shù)等字段Server.java服務(wù)端入口收包、校驗、觸發(fā)合包FIleUtils.java文件工具字節(jié)與文件互轉(zhuǎn)UdpHeader.java是整個方案的核心。UDP 本身只保證「發(fā)出去」不保證「到、對、序」所以應(yīng)用層必須自己造一個頭。常見做法是在每個包前面加固定長度的字節(jié)段里面塞進圖片 ID、分片序號、總分片數(shù)、數(shù)據(jù)長度和一個校驗字段。服務(wù)端收到后先讀頭校驗通過才把數(shù)據(jù)體放進緩沖區(qū)對應(yīng)位置。BasicUdpRemoteRequestBuffer.java這個名字里的 Buffer 很關(guān)鍵。UDP 是無連接的同一個服務(wù)端可能同時收到多個客戶端的包必須按來源地址隔離緩沖區(qū)否則 A 的圖會和 B 的圖拼在一起。這個類大概率維護了一個MapSocketAddress, 分片集合的結(jié)構(gòu)。2.2 為什么不用 TCP選型理由要講清有人會問傳圖片為什么不用 TCP省得自己分包。這里有個邊界TCP 的可靠傳輸伴隨隊頭阻塞一個包丟了后面全等著對于實時性要求高、能容忍偶爾丟幀的場景比如監(jiān)控預(yù)覽、傳感器快照UDP 加應(yīng)用層重組反而更可控。但這個例子的定位不是「高吞吐流媒體」而是「單張圖片的可靠傳輸」所以它必須在應(yīng)用層把 TCP 干的活補回來分包、校驗、確認(rèn)、重組。理解這一點后面看代碼就不會覺得「多此一舉」。提示如果你的場景是持續(xù)視頻流這個例子的「整圖重組」模式需要改造不能直接套用。3. 客戶端分包發(fā)送字節(jié)轉(zhuǎn)換、鑒權(quán)頭與切包邏輯3.1 圖片轉(zhuǎn)字節(jié)與包頭設(shè)計客戶端第一步是把圖片文件讀成字節(jié)數(shù)組然后按 MTU 減去包頭長度來切分。以太網(wǎng) MTU 通常 1500 字節(jié)減去 IP 頭 20、UDP 頭 8留給應(yīng)用層約 1472 字節(jié)。實際工程里我會留余量用 1024 或 1200 作為每包數(shù)據(jù)體大小避免 IP 層再分片。包頭字段的設(shè)計直接決定服務(wù)端能不能校驗。參考這個例子的思路一個夠用的頭至少包含// UdpHeader.java 思路示意固定長度包頭便于服務(wù)端按偏移讀取 public class UdpHeader { public static final int HEADER_LEN 16; // 固定16字節(jié)頭 private int magic; // 魔數(shù)快速識別是否為本協(xié)議包 private int imageId; // 圖片標(biāo)識區(qū)分不同圖片 private int totalPackets; // 總分片數(shù) private int packetIndex; // 當(dāng)前分片序號從0開始 private int dataLen; // 本包數(shù)據(jù)體實際長度 private int checksum; // 數(shù)據(jù)體校驗值常用CRC32或簡單累加和 // 序列化為字節(jié)數(shù)組服務(wù)端按同樣偏移反序列化 public byte[] toBytes() { /* 按大端序?qū)懭?ByteBuffer */ } public static UdpHeader parse(byte[] raw) { /* 按偏移讀取 */ } }邏輯說明magic是防串包的第一道門服務(wù)端收到非本協(xié)議的包直接丟。imageId配合來源地址能區(qū)分同一客戶端連續(xù)發(fā)的多張圖。packetIndex和totalPackets讓服務(wù)端知道什么時候收齊。checksum是第二道門防止數(shù)據(jù)體在傳輸中被改壞。參數(shù)說明HEADER_LEN一旦定下客戶端和服務(wù)端必須一致改一處就得同步改另一處這是血淚經(jīng)驗。checksum用 CRC32 比簡單累加和更能發(fā)現(xiàn)字節(jié)錯位代價是多幾行代碼。3.2 切包與發(fā)送循環(huán)// SendUdp.java 核心發(fā)送邏輯示意 byte[] imageBytes FIleUtils.fileToBytes(test.jpg); int dataPerPacket 1024; // 每包數(shù)據(jù)體大小留足MTU余量 int total (imageBytes.length dataPerPacket - 1) / dataPerPacket; DatagramSocket socket new DatagramSocket(); InetAddress server InetAddress.getByName(127.0.0.1); int serverPort 9999; for (int i 0; i total; i) { int offset i * dataPerPacket; int len Math.min(dataPerPacket, imageBytes.length - offset); byte[] body new byte[len]; System.arraycopy(imageBytes, offset, body, 0, len); UdpHeader header new UdpHeader(); header.setMagic(0x55AA); header.setImageId(1001); header.setTotalPackets(total); header.setPacketIndex(i); header.setDataLen(len); header.setChecksum(crc32(body)); byte[] packet concat(header.toBytes(), body); socket.send(new DatagramPacket(packet, packet.length, server, serverPort)); // 可選每包之間微睡眠避免瞬時打爆接收緩沖 }邏輯說明循環(huán)按dataPerPacket切分最后一包長度用Math.min兜住。每包都重新構(gòu)造頭把序號和校驗寫進去。concat是自定義的字節(jié)拼接方法先頭后體。參數(shù)說明dataPerPacket設(shè) 1024 是保守值局域網(wǎng)可以試 1400公網(wǎng)建議不超過 1200。imageId用遞增或時間戳避免多張圖混淆。發(fā)送循環(huán)里加不加睡眠取決于接收端緩沖區(qū)大小和網(wǎng)絡(luò)抖動丟包嚴(yán)重時先查這里。注意UDP 發(fā)送本身不阻塞循環(huán)發(fā)太快會把本機發(fā)送緩沖和對方接收緩沖一起打滿表現(xiàn)為「發(fā)成功了但對方?jīng)]收到」。這是新手最容易翻車的地方。4. 服務(wù)端校驗與合包怎么判斷包是自己的、且沒壞4.1 校驗的三層防線服務(wù)端收到包后不能直接往緩沖區(qū)塞必須先過三關(guān)。第一關(guān)是來源過濾只處理已知客戶端的地址或者至少按地址隔離緩沖區(qū)。第二關(guān)是包頭校驗magic不對、dataLen和實際長度對不上、packetIndex越界都直接丟。第三關(guān)是數(shù)據(jù)體校驗用同樣的 CRC32 算法算一遍和頭里的checksum比對不一致說明數(shù)據(jù)壞了。// Server.java 收包校驗示意 byte[] buf new byte[2048]; DatagramPacket dp new DatagramPacket(buf, buf.length); socket.receive(dp); byte[] raw Arrays.copyOf(dp.getData(), dp.getLength()); if (raw.length UdpHeader.HEADER_LEN) return; // 太短非法 UdpHeader header UdpHeader.parse(raw); if (header.getMagic() ! 0x55AA) return; // 不是本協(xié)議包 byte[] body Arrays.copyOfRange(raw, UdpHeader.HEADER_LEN, raw.length); if (body.length ! header.getDataLen()) return; // 長度不符 if (crc32(body) ! header.getChecksum()) return; // 校驗失敗 // 通過校驗按來源地址imageId放入緩沖區(qū) buffer.put(dp.getSocketAddress(), header, body);邏輯說明Arrays.copyOf截取實際收到的長度因為dp.getData()返回的是整個緩沖區(qū)尾部有空白。校驗順序從廉價到昂貴先看長度和魔數(shù)再做 CRC減少無效計算。參數(shù)說明緩沖區(qū)buf要大于最大可能包長2048 夠用。crc32必須和客戶端用同一套實現(xiàn)多項式一致否則永遠(yuǎn)校驗不過。4.2 合包觸發(fā)與圖片還原合包的關(guān)鍵是判斷「收齊了」。緩沖區(qū)按imageId維護一個分片數(shù)組每收到一個合法包就填入對應(yīng)下標(biāo)同時計數(shù)。當(dāng)計數(shù)等于totalPackets按序拼接所有數(shù)據(jù)體寫回文件。// BasicUdpRemoteRequestBuffer.java 合包示意 // 每個來源imageId對應(yīng)一個分片容器 MapString, byte[][] slots new ConcurrentHashMap(); MapString, AtomicInteger counts new ConcurrentHashMap(); public void put(SocketAddress addr, UdpHeader h, byte[] body) { String key addr.toString() _ h.getImageId(); byte[][] arr slots.computeIfAbsent(key, k - new byte[h.getTotalPackets()][]); if (arr[h.getPacketIndex()] null) { // 去重防止重復(fù)包重復(fù)計數(shù) arr[h.getPacketIndex()] body; int c counts.computeIfAbsent(key, k - new AtomicInteger()).incrementAndGet(); if (c h.getTotalPackets()) { mergeAndSave(key, arr); // 收齊合并落盤 slots.remove(key); counts.remove(key); } } }邏輯說明用ConcurrentHashMap是因為 UDP 接收可能多線程。arr[index] null判斷實現(xiàn)去重重復(fù)包不重復(fù)計數(shù)否則計數(shù)虛高會提前觸發(fā)合包拼出殘缺圖片。參數(shù)說明key用地址加imageId保證多客戶端隔離。合包后立即清理 map防止內(nèi)存泄漏——長時間運行的服務(wù)端如果不清理緩沖區(qū)會越堆越大。提示合并時按數(shù)組下標(biāo)順序拼接不要依賴收到順序。UDP 到達(dá)順序是亂的這是它和 TCP 最本質(zhì)的區(qū)別之一。5. 避坑與排查那些讓我加班到凌晨的 UDP 問題5.1 圖片花屏或打不開現(xiàn)象服務(wù)端生成了文件但打開是花的或直接報錯。原因通常是分片丟失或錯位但計數(shù)卻顯示收齊了。排查時先打印每個分片的長度和校驗結(jié)果重點看有沒有null分片被當(dāng)成空數(shù)組拼接。解決合包前再遍歷一次數(shù)組任何下標(biāo)為null就判定未收齊不觸發(fā)合并。5.2 校驗永遠(yuǎn)不過現(xiàn)象客戶端發(fā)的包服務(wù)端 CRC 全部對不上。原因多半是兩端 CRC 實現(xiàn)的多項式或初始值不一致或者客戶端算的是「頭體」而服務(wù)端只算「體」。解決統(tǒng)一校驗范圍只對數(shù)據(jù)體算把算法封裝成兩端共用的工具方法別各寫各的。5.3 大圖發(fā)送后服務(wù)端只收到前幾包現(xiàn)象小圖正常大圖丟包嚴(yán)重。原因是發(fā)送循環(huán)太快接收緩沖區(qū)溢出。解決在發(fā)送循環(huán)里加短暫Thread.sleep(1)或者用DatagramSocket.setSendBufferSize調(diào)大發(fā)送緩沖接收端也調(diào)大setReceiveBufferSize。iperf3 打流測試時也會遇到類似現(xiàn)象本質(zhì)是緩沖和速率不匹配。5.4 多張圖串在一起現(xiàn)象連續(xù)發(fā)兩張圖服務(wù)端拼出一張「縫合怪」。原因是imageId沒變或緩沖區(qū) key 設(shè)計不當(dāng)。解決每張圖用唯一imageId緩沖區(qū) key 必須包含來源地址和imageId合包后立刻清理。5.5 端口被占用或收不到包現(xiàn)象服務(wù)端啟動報錯或客戶端發(fā)了沒反應(yīng)。先確認(rèn)端口沒被占再確認(rèn)防火墻放行。UDP 端口測試可以用netstat -anu看監(jiān)聽狀態(tài)。如果服務(wù)端綁定了127.0.0.1外部客戶端連不上要綁0.0.0.0。6. 進階把校驗從 CRC32 換成自定義規(guī)則以及我的驗證習(xí)慣這個例子的校驗用的是固定算法實際項目里我會把校驗字段做成可配置。比如工業(yè)場景要求更強的完整性可以把 CRC32 換成 CRC32C 或者加一層簡單哈希。改的時候只動UdpHeader和兩端的校驗工具類包頭長度不變兼容性最好。驗證合包是否正確我有個笨但有效的習(xí)慣客戶端發(fā)圖前先算整張圖的 MD5服務(wù)端合包后再算一次兩個值對上才算真正成功。這比肉眼看圖可靠得多也能發(fā)現(xiàn)「看起來正常但像素被改」的隱蔽問題。// 端到端驗證發(fā)送前和合包后各算一次 String sendMd5 md5(FIleUtils.fileToBytes(test.jpg)); // ... 發(fā)送與接收 ... String recvMd5 md5(FIleUtils.fileToBytes(received.jpg)); System.out.println(一致: sendMd5.equals(recvMd5));參數(shù)說明MD5 只用于驗證不用于安全場景。如果圖片大算 MD5 有開銷可以只在調(diào)試階段開。另外SendAccept.java的存在說明這個例子可能帶了簡單的確認(rèn)機制。如果要做可靠傳輸可以在服務(wù)端收齊后回一個「完成」包客戶端收到才認(rèn)為發(fā)送成功超時未收到就重發(fā)整圖或缺失分片。這是從「能收」到「可靠收」的關(guān)鍵一步也是這個源碼包可以繼續(xù)擴展的方向。從那以后我每次做 UDP 分包都強制先跑一遍小圖、再跑大圖、最后跑連續(xù)多圖三步都過才敢上真實環(huán)境。希望幫到你。本文還有配套的精品資源點擊獲取 UDP分包傳圖實戰(zhàn)：自定義包頭校驗與圖片重組方案
簡介這是一份面向Java網(wǎng)絡(luò)編程學(xué)習(xí)者與初學(xué)者的UDP圖片傳輸實戰(zhàn)示例聚焦UDP協(xié)議下圖片數(shù)據(jù)的分包發(fā)送與合包還原這一典型場景。資源通過客戶端將圖片轉(zhuǎn)為字節(jié)數(shù)據(jù)、附加鑒權(quán)信息后分包發(fā)送服務(wù)端對每個UDP包進行正確性校驗避免他人偽造或錯誤包被解析再將合法包合并還原為完整圖片幫助讀者理解UDP不可靠傳輸下的分包、校驗與重組思路。壓縮包共7個文件包含6個Java源碼與1份使用說明txt整體約5KB源碼按客戶端發(fā)送、服務(wù)端接收、UDP包頭封裝、文件工具等職責(zé)拆分結(jié)構(gòu)清晰便于對照閱讀。目前已有431人學(xué)習(xí)下載適合希望掌握J(rèn)ava UDP通信、數(shù)據(jù)校驗與圖片字節(jié)流處理的中級開發(fā)者參考也可作為課程設(shè)計或網(wǎng)絡(luò)實驗的練手素材。1. UDP 分包傳圖為什么我寧愿手寫校驗也不直接上 TCP前陣子幫一個做工業(yè)相機的朋友排查問題他們的設(shè)備通過 UDP 往服務(wù)器推圖片結(jié)果十張里有三張是花的還有兩張干脆打不開。抓包一看發(fā)送端把一張 200KB 的 JPEG 直接塞進一個 UDP 包IP 層分片后只要丟一片整張圖就廢了。這個udp_分包_和包.rar里的例子解決的正是這個場景客戶端把圖片轉(zhuǎn)成字節(jié)數(shù)組加鑒權(quán)頭切成固定大小的包發(fā)出去服務(wù)端逐包校驗、去重、按序合并最后還原成一張完整圖片。它適合兩類人一是正在用 UDP 做實時圖傳、又不想被 TCP 隊頭阻塞拖累的開發(fā)者二是想搞懂 UDP 應(yīng)用層分包到底該怎么設(shè)計校驗和重組邏輯的學(xué)習(xí)者。Java 寫的六個源文件加一份說明結(jié)構(gòu)不復(fù)雜但把「怎么保證收到的包是自己的、且沒壞」這件事講得比較透。2. 拆開這個包六個 Java 文件各自扛什么活2.1 從文件清單反推模塊職責(zé)拿到一個源碼包我習(xí)慣先看文件命名和數(shù)量基本能猜出架構(gòu)。這個包里六個 Java 文件加一個說明文檔分工很清晰文件名推測職責(zé)關(guān)鍵點SendUdp.java客戶端入口讀圖、轉(zhuǎn)字節(jié)、調(diào)分包邏輯SendAccept.java客戶端發(fā)送確認(rèn)處理服務(wù)端回執(zhí)或重傳BasicUdpRemoteRequestBuffer.java緩沖區(qū)管理按 remote 地址緩存分片UdpHeader.java自定義包頭鑒權(quán)、序號、總包數(shù)等字段Server.java服務(wù)端入口收包、校驗、觸發(fā)合包FIleUtils.java文件工具字節(jié)與文件互轉(zhuǎn)UdpHeader.java是整個方案的核心。UDP 本身只保證「發(fā)出去」不保證「到、對、序」所以應(yīng)用層必須自己造一個頭。常見做法是在每個包前面加固定長度的字節(jié)段里面塞進圖片 ID、分片序號、總分片數(shù)、數(shù)據(jù)長度和一個校驗字段。服務(wù)端收到后先讀頭校驗通過才把數(shù)據(jù)體放進緩沖區(qū)對應(yīng)位置。BasicUdpRemoteRequestBuffer.java這個名字里的 Buffer 很關(guān)鍵。UDP 是無連接的同一個服務(wù)端可能同時收到多個客戶端的包必須按來源地址隔離緩沖區(qū)否則 A 的圖會和 B 的圖拼在一起。這個類大概率維護了一個MapSocketAddress, 分片集合的結(jié)構(gòu)。2.2 為什么不用 TCP選型理由要講清有人會問傳圖片為什么不用 TCP省得自己分包。這里有個邊界TCP 的可靠傳輸伴隨隊頭阻塞一個包丟了后面全等著對于實時性要求高、能容忍偶爾丟幀的場景比如監(jiān)控預(yù)覽、傳感器快照UDP 加應(yīng)用層重組反而更可控。但這個例子的定位不是「高吞吐流媒體」而是「單張圖片的可靠傳輸」所以它必須在應(yīng)用層把 TCP 干的活補回來分包、校驗、確認(rèn)、重組。理解這一點后面看代碼就不會覺得「多此一舉」。提示如果你的場景是持續(xù)視頻流這個例子的「整圖重組」模式需要改造不能直接套用。3. 客戶端分包發(fā)送字節(jié)轉(zhuǎn)換、鑒權(quán)頭與切包邏輯3.1 圖片轉(zhuǎn)字節(jié)與包頭設(shè)計客戶端第一步是把圖片文件讀成字節(jié)數(shù)組然后按 MTU 減去包頭長度來切分。以太網(wǎng) MTU 通常 1500 字節(jié)減去 IP 頭 20、UDP 頭 8留給應(yīng)用層約 1472 字節(jié)。實際工程里我會留余量用 1024 或 1200 作為每包數(shù)據(jù)體大小避免 IP 層再分片。包頭字段的設(shè)計直接決定服務(wù)端能不能校驗。參考這個例子的思路一個夠用的頭至少包含// UdpHeader.java 思路示意固定長度包頭便于服務(wù)端按偏移讀取 public class UdpHeader { public static final int HEADER_LEN 16; // 固定16字節(jié)頭 private int magic; // 魔數(shù)快速識別是否為本協(xié)議包 private int imageId; // 圖片標(biāo)識區(qū)分不同圖片 private int totalPackets; // 總分片數(shù) private int packetIndex; // 當(dāng)前分片序號從0開始 private int dataLen; // 本包數(shù)據(jù)體實際長度 private int checksum; // 數(shù)據(jù)體校驗值常用CRC32或簡單累加和 // 序列化為字節(jié)數(shù)組服務(wù)端按同樣偏移反序列化 public byte[] toBytes() { /* 按大端序?qū)懭?ByteBuffer */ } public static UdpHeader parse(byte[] raw) { /* 按偏移讀取 */ } }邏輯說明magic是防串包的第一道門服務(wù)端收到非本協(xié)議的包直接丟。imageId配合來源地址能區(qū)分同一客戶端連續(xù)發(fā)的多張圖。packetIndex和totalPackets讓服務(wù)端知道什么時候收齊。checksum是第二道門防止數(shù)據(jù)體在傳輸中被改壞。參數(shù)說明HEADER_LEN一旦定下客戶端和服務(wù)端必須一致改一處就得同步改另一處這是血淚經(jīng)驗。checksum用 CRC32 比簡單累加和更能發(fā)現(xiàn)字節(jié)錯位代價是多幾行代碼。3.2 切包與發(fā)送循環(huán)// SendUdp.java 核心發(fā)送邏輯示意 byte[] imageBytes FIleUtils.fileToBytes(test.jpg); int dataPerPacket 1024; // 每包數(shù)據(jù)體大小留足MTU余量 int total (imageBytes.length dataPerPacket - 1) / dataPerPacket; DatagramSocket socket new DatagramSocket(); InetAddress server InetAddress.getByName(127.0.0.1); int serverPort 9999; for (int i 0; i total; i) { int offset i * dataPerPacket; int len Math.min(dataPerPacket, imageBytes.length - offset); byte[] body new byte[len]; System.arraycopy(imageBytes, offset, body, 0, len); UdpHeader header new UdpHeader(); header.setMagic(0x55AA); header.setImageId(1001); header.setTotalPackets(total); header.setPacketIndex(i); header.setDataLen(len); header.setChecksum(crc32(body)); byte[] packet concat(header.toBytes(), body); socket.send(new DatagramPacket(packet, packet.length, server, serverPort)); // 可選每包之間微睡眠避免瞬時打爆接收緩沖 }邏輯說明循環(huán)按dataPerPacket切分最后一包長度用Math.min兜住。每包都重新構(gòu)造頭把序號和校驗寫進去。concat是自定義的字節(jié)拼接方法先頭后體。參數(shù)說明dataPerPacket設(shè) 1024 是保守值局域網(wǎng)可以試 1400公網(wǎng)建議不超過 1200。imageId用遞增或時間戳避免多張圖混淆。發(fā)送循環(huán)里加不加睡眠取決于接收端緩沖區(qū)大小和網(wǎng)絡(luò)抖動丟包嚴(yán)重時先查這里。注意UDP 發(fā)送本身不阻塞循環(huán)發(fā)太快會把本機發(fā)送緩沖和對方接收緩沖一起打滿表現(xiàn)為「發(fā)成功了但對方?jīng)]收到」。這是新手最容易翻車的地方。4. 服務(wù)端校驗與合包怎么判斷包是自己的、且沒壞4.1 校驗的三層防線服務(wù)端收到包后不能直接往緩沖區(qū)塞必須先過三關(guān)。第一關(guān)是來源過濾只處理已知客戶端的地址或者至少按地址隔離緩沖區(qū)。第二關(guān)是包頭校驗magic不對、dataLen和實際長度對不上、packetIndex越界都直接丟。第三關(guān)是數(shù)據(jù)體校驗用同樣的 CRC32 算法算一遍和頭里的checksum比對不一致說明數(shù)據(jù)壞了。// Server.java 收包校驗示意 byte[] buf new byte[2048]; DatagramPacket dp new DatagramPacket(buf, buf.length); socket.receive(dp); byte[] raw Arrays.copyOf(dp.getData(), dp.getLength()); if (raw.length UdpHeader.HEADER_LEN) return; // 太短非法 UdpHeader header UdpHeader.parse(raw); if (header.getMagic() ! 0x55AA) return; // 不是本協(xié)議包 byte[] body Arrays.copyOfRange(raw, UdpHeader.HEADER_LEN, raw.length); if (body.length ! header.getDataLen()) return; // 長度不符 if (crc32(body) ! header.getChecksum()) return; // 校驗失敗 // 通過校驗按來源地址imageId放入緩沖區(qū) buffer.put(dp.getSocketAddress(), header, body);邏輯說明Arrays.copyOf截取實際收到的長度因為dp.getData()返回的是整個緩沖區(qū)尾部有空白。校驗順序從廉價到昂貴先看長度和魔數(shù)再做 CRC減少無效計算。參數(shù)說明緩沖區(qū)buf要大于最大可能包長2048 夠用。crc32必須和客戶端用同一套實現(xiàn)多項式一致否則永遠(yuǎn)校驗不過。4.2 合包觸發(fā)與圖片還原合包的關(guān)鍵是判斷「收齊了」。緩沖區(qū)按imageId維護一個分片數(shù)組每收到一個合法包就填入對應(yīng)下標(biāo)同時計數(shù)。當(dāng)計數(shù)等于totalPackets按序拼接所有數(shù)據(jù)體寫回文件。// BasicUdpRemoteRequestBuffer.java 合包示意 // 每個來源imageId對應(yīng)一個分片容器 MapString, byte[][] slots new ConcurrentHashMap(); MapString, AtomicInteger counts new ConcurrentHashMap(); public void put(SocketAddress addr, UdpHeader h, byte[] body) { String key addr.toString() _ h.getImageId(); byte[][] arr slots.computeIfAbsent(key, k - new byte[h.getTotalPackets()][]); if (arr[h.getPacketIndex()] null) { // 去重防止重復(fù)包重復(fù)計數(shù) arr[h.getPacketIndex()] body; int c counts.computeIfAbsent(key, k - new AtomicInteger()).incrementAndGet(); if (c h.getTotalPackets()) { mergeAndSave(key, arr); // 收齊合并落盤 slots.remove(key); counts.remove(key); } } }邏輯說明用ConcurrentHashMap是因為 UDP 接收可能多線程。arr[index] null判斷實現(xiàn)去重重復(fù)包不重復(fù)計數(shù)否則計數(shù)虛高會提前觸發(fā)合包拼出殘缺圖片。參數(shù)說明key用地址加imageId保證多客戶端隔離。合包后立即清理 map防止內(nèi)存泄漏——長時間運行的服務(wù)端如果不清理緩沖區(qū)會越堆越大。提示合并時按數(shù)組下標(biāo)順序拼接不要依賴收到順序。UDP 到達(dá)順序是亂的這是它和 TCP 最本質(zhì)的區(qū)別之一。5. 避坑與排查那些讓我加班到凌晨的 UDP 問題5.1 圖片花屏或打不開現(xiàn)象服務(wù)端生成了文件但打開是花的或直接報錯。原因通常是分片丟失或錯位但計數(shù)卻顯示收齊了。排查時先打印每個分片的長度和校驗結(jié)果重點看有沒有null分片被當(dāng)成空數(shù)組拼接。解決合包前再遍歷一次數(shù)組任何下標(biāo)為null就判定未收齊不觸發(fā)合并。5.2 校驗永遠(yuǎn)不過現(xiàn)象客戶端發(fā)的包服務(wù)端 CRC 全部對不上。原因多半是兩端 CRC 實現(xiàn)的多項式或初始值不一致或者客戶端算的是「頭體」而服務(wù)端只算「體」。解決統(tǒng)一校驗范圍只對數(shù)據(jù)體算把算法封裝成兩端共用的工具方法別各寫各的。5.3 大圖發(fā)送后服務(wù)端只收到前幾包現(xiàn)象小圖正常大圖丟包嚴(yán)重。原因是發(fā)送循環(huán)太快接收緩沖區(qū)溢出。解決在發(fā)送循環(huán)里加短暫Thread.sleep(1)或者用DatagramSocket.setSendBufferSize調(diào)大發(fā)送緩沖接收端也調(diào)大setReceiveBufferSize。iperf3 打流測試時也會遇到類似現(xiàn)象本質(zhì)是緩沖和速率不匹配。5.4 多張圖串在一起現(xiàn)象連續(xù)發(fā)兩張圖服務(wù)端拼出一張「縫合怪」。原因是imageId沒變或緩沖區(qū) key 設(shè)計不當(dāng)。解決每張圖用唯一imageId緩沖區(qū) key 必須包含來源地址和imageId合包后立刻清理。5.5 端口被占用或收不到包現(xiàn)象服務(wù)端啟動報錯或客戶端發(fā)了沒反應(yīng)。先確認(rèn)端口沒被占再確認(rèn)防火墻放行。UDP 端口測試可以用netstat -anu看監(jiān)聽狀態(tài)。如果服務(wù)端綁定了127.0.0.1外部客戶端連不上要綁0.0.0.0。6. 進階把校驗從 CRC32 換成自定義規(guī)則以及我的驗證習(xí)慣這個例子的校驗用的是固定算法實際項目里我會把校驗字段做成可配置。比如工業(yè)場景要求更強的完整性可以把 CRC32 換成 CRC32C 或者加一層簡單哈希。改的時候只動UdpHeader和兩端的校驗工具類包頭長度不變兼容性最好。驗證合包是否正確我有個笨但有效的習(xí)慣客戶端發(fā)圖前先算整張圖的 MD5服務(wù)端合包后再算一次兩個值對上才算真正成功。這比肉眼看圖可靠得多也能發(fā)現(xiàn)「看起來正常但像素被改」的隱蔽問題。// 端到端驗證發(fā)送前和合包后各算一次 String sendMd5 md5(FIleUtils.fileToBytes(test.jpg)); // ... 發(fā)送與接收 ... String recvMd5 md5(FIleUtils.fileToBytes(received.jpg)); System.out.println(一致: sendMd5.equals(recvMd5));參數(shù)說明MD5 只用于驗證不用于安全場景。如果圖片大算 MD5 有開銷可以只在調(diào)試階段開。另外SendAccept.java的存在說明這個例子可能帶了簡單的確認(rèn)機制。如果要做可靠傳輸可以在服務(wù)端收齊后回一個「完成」包客戶端收到才認(rèn)為發(fā)送成功超時未收到就重發(fā)整圖或缺失分片。這是從「能收」到「可靠收」的關(guān)鍵一步也是這個源碼包可以繼續(xù)擴展的方向。從那以后我每次做 UDP 分包都強制先跑一遍小圖、再跑大圖、最后跑連續(xù)多圖三步都過才敢上真實環(huán)境。希望幫到你。本文還有配套的精品資源點擊獲取