简介这是一份面向Java网络编程学习者与初学者的UDP图片传输实战示例聚焦UDP协议下图片数据的分包发送与合包还原这一典型场景。资源通过客户端将图片转为字节数据、附加鉴权信息后分包发送服务端对每个UDP包进行正确性校验避免他人伪造或错误包被解析再将合法包合并还原为完整图片帮助读者理解UDP不可靠传输下的分包、校验与重组思路。压缩包共7个文件包含6个Java源码与1份使用说明txt整体约5KB源码按客户端发送、服务端接收、UDP包头封装、文件工具等职责拆分结构清晰便于对照阅读。目前已有431人学习下载适合希望掌握Java UDP通信、数据校验与图片字节流处理的中级开发者参考也可作为课程设计或网络实验的练手素材。1. UDP 分包传图为什么我宁愿手写校验也不直接上 TCP前阵子帮一个做工业相机的朋友排查问题他们的设备通过 UDP 往服务器推图片结果十张里有三张是花的还有两张干脆打不开。抓包一看发送端把一张 200KB 的 JPEG 直接塞进一个 UDP 包IP 层分片后只要丢一片整张图就废了。这个udp_分包_和包.rar里的例子解决的正是这个场景客户端把图片转成字节数组加鉴权头切成固定大小的包发出去服务端逐包校验、去重、按序合并最后还原成一张完整图片。它适合两类人一是正在用 UDP 做实时图传、又不想被 TCP 队头阻塞拖累的开发者二是想搞懂 UDP 应用层分包到底该怎么设计校验和重组逻辑的学习者。Java 写的六个源文件加一份说明结构不复杂但把「怎么保证收到的包是自己的、且没坏」这件事讲得比较透。2. 拆开这个包六个 Java 文件各自扛什么活2.1 从文件清单反推模块职责拿到一个源码包我习惯先看文件命名和数量基本能猜出架构。这个包里六个 Java 文件加一个说明文档分工很清晰文件名推测职责关键点SendUdp.java客户端入口读图、转字节、调分包逻辑SendAccept.java客户端发送确认处理服务端回执或重传BasicUdpRemoteRequestBuffer.java缓冲区管理按 remote 地址缓存分片UdpHeader.java自定义包头鉴权、序号、总包数等字段Server.java服务端入口收包、校验、触发合包FIleUtils.java文件工具字节与文件互转UdpHeader.java是整个方案的核心。UDP 本身只保证「发出去」不保证「到、对、序」所以应用层必须自己造一个头。常见做法是在每个包前面加固定长度的字节段里面塞进图片 ID、分片序号、总分片数、数据长度和一个校验字段。服务端收到后先读头校验通过才把数据体放进缓冲区对应位置。BasicUdpRemoteRequestBuffer.java这个名字里的 Buffer 很关键。UDP 是无连接的同一个服务端可能同时收到多个客户端的包必须按来源地址隔离缓冲区否则 A 的图会和 B 的图拼在一起。这个类大概率维护了一个MapSocketAddress, 分片集合的结构。2.2 为什么不用 TCP选型理由要讲清有人会问传图片为什么不用 TCP省得自己分包。这里有个边界TCP 的可靠传输伴随队头阻塞一个包丢了后面全等着对于实时性要求高、能容忍偶尔丢帧的场景比如监控预览、传感器快照UDP 加应用层重组反而更可控。但这个例子的定位不是「高吞吐流媒体」而是「单张图片的可靠传输」所以它必须在应用层把 TCP 干的活补回来分包、校验、确认、重组。理解这一点后面看代码就不会觉得「多此一举」。提示如果你的场景是持续视频流这个例子的「整图重组」模式需要改造不能直接套用。3. 客户端分包发送字节转换、鉴权头与切包逻辑3.1 图片转字节与包头设计客户端第一步是把图片文件读成字节数组然后按 MTU 减去包头长度来切分。以太网 MTU 通常 1500 字节减去 IP 头 20、UDP 头 8留给应用层约 1472 字节。实际工程里我会留余量用 1024 或 1200 作为每包数据体大小避免 IP 层再分片。包头字段的设计直接决定服务端能不能校验。参考这个例子的思路一个够用的头至少包含// UdpHeader.java 思路示意固定长度包头便于服务端按偏移读取 public class UdpHeader { public static final int HEADER_LEN 16; // 固定16字节头 private int magic; // 魔数快速识别是否为本协议包 private int imageId; // 图片标识区分不同图片 private int totalPackets; // 总分片数 private int packetIndex; // 当前分片序号从0开始 private int dataLen; // 本包数据体实际长度 private int checksum; // 数据体校验值常用CRC32或简单累加和 // 序列化为字节数组服务端按同样偏移反序列化 public byte[] toBytes() { /* 按大端序写入 ByteBuffer */ } public static UdpHeader parse(byte[] raw) { /* 按偏移读取 */ } }逻辑说明magic是防串包的第一道门服务端收到非本协议的包直接丢。imageId配合来源地址能区分同一客户端连续发的多张图。packetIndex和totalPackets让服务端知道什么时候收齐。checksum是第二道门防止数据体在传输中被改坏。参数说明HEADER_LEN一旦定下客户端和服务端必须一致改一处就得同步改另一处这是血泪经验。checksum用 CRC32 比简单累加和更能发现字节错位代价是多几行代码。3.2 切包与发送循环// SendUdp.java 核心发送逻辑示意 byte[] imageBytes FIleUtils.fileToBytes(test.jpg); int dataPerPacket 1024; // 每包数据体大小留足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)); // 可选每包之间微睡眠避免瞬时打爆接收缓冲 }逻辑说明循环按dataPerPacket切分最后一包长度用Math.min兜住。每包都重新构造头把序号和校验写进去。concat是自定义的字节拼接方法先头后体。参数说明dataPerPacket设 1024 是保守值局域网可以试 1400公网建议不超过 1200。imageId用递增或时间戳避免多张图混淆。发送循环里加不加睡眠取决于接收端缓冲区大小和网络抖动丢包严重时先查这里。注意UDP 发送本身不阻塞循环发太快会把本机发送缓冲和对方接收缓冲一起打满表现为「发成功了但对方没收到」。这是新手最容易翻车的地方。4. 服务端校验与合包怎么判断包是自己的、且没坏4.1 校验的三层防线服务端收到包后不能直接往缓冲区塞必须先过三关。第一关是来源过滤只处理已知客户端的地址或者至少按地址隔离缓冲区。第二关是包头校验magic不对、dataLen和实际长度对不上、packetIndex越界都直接丢。第三关是数据体校验用同样的 CRC32 算法算一遍和头里的checksum比对不一致说明数据坏了。// 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; // 不是本协议包 byte[] body Arrays.copyOfRange(raw, UdpHeader.HEADER_LEN, raw.length); if (body.length ! header.getDataLen()) return; // 长度不符 if (crc32(body) ! header.getChecksum()) return; // 校验失败 // 通过校验按来源地址imageId放入缓冲区 buffer.put(dp.getSocketAddress(), header, body);逻辑说明Arrays.copyOf截取实际收到的长度因为dp.getData()返回的是整个缓冲区尾部有空白。校验顺序从廉价到昂贵先看长度和魔数再做 CRC减少无效计算。参数说明缓冲区buf要大于最大可能包长2048 够用。crc32必须和客户端用同一套实现多项式一致否则永远校验不过。4.2 合包触发与图片还原合包的关键是判断「收齐了」。缓冲区按imageId维护一个分片数组每收到一个合法包就填入对应下标同时计数。当计数等于totalPackets按序拼接所有数据体写回文件。// BasicUdpRemoteRequestBuffer.java 合包示意 // 每个来源imageId对应一个分片容器 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) { // 去重防止重复包重复计数 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判断实现去重重复包不重复计数否则计数虚高会提前触发合包拼出残缺图片。参数说明key用地址加imageId保证多客户端隔离。合包后立即清理 map防止内存泄漏——长时间运行的服务端如果不清理缓冲区会越堆越大。提示合并时按数组下标顺序拼接不要依赖收到顺序。UDP 到达顺序是乱的这是它和 TCP 最本质的区别之一。5. 避坑与排查那些让我加班到凌晨的 UDP 问题5.1 图片花屏或打不开现象服务端生成了文件但打开是花的或直接报错。原因通常是分片丢失或错位但计数却显示收齐了。排查时先打印每个分片的长度和校验结果重点看有没有null分片被当成空数组拼接。解决合包前再遍历一次数组任何下标为null就判定未收齐不触发合并。5.2 校验永远不过现象客户端发的包服务端 CRC 全部对不上。原因多半是两端 CRC 实现的多项式或初始值不一致或者客户端算的是「头体」而服务端只算「体」。解决统一校验范围只对数据体算把算法封装成两端共用的工具方法别各写各的。5.3 大图发送后服务端只收到前几包现象小图正常大图丢包严重。原因是发送循环太快接收缓冲区溢出。解决在发送循环里加短暂Thread.sleep(1)或者用DatagramSocket.setSendBufferSize调大发送缓冲接收端也调大setReceiveBufferSize。iperf3 打流测试时也会遇到类似现象本质是缓冲和速率不匹配。5.4 多张图串在一起现象连续发两张图服务端拼出一张「缝合怪」。原因是imageId没变或缓冲区 key 设计不当。解决每张图用唯一imageId缓冲区 key 必须包含来源地址和imageId合包后立刻清理。5.5 端口被占用或收不到包现象服务端启动报错或客户端发了没反应。先确认端口没被占再确认防火墙放行。UDP 端口测试可以用netstat -anu看监听状态。如果服务端绑定了127.0.0.1外部客户端连不上要绑0.0.0.0。6. 进阶把校验从 CRC32 换成自定义规则以及我的验证习惯这个例子的校验用的是固定算法实际项目里我会把校验字段做成可配置。比如工业场景要求更强的完整性可以把 CRC32 换成 CRC32C 或者加一层简单哈希。改的时候只动UdpHeader和两端的校验工具类包头长度不变兼容性最好。验证合包是否正确我有个笨但有效的习惯客户端发图前先算整张图的 MD5服务端合包后再算一次两个值对上才算真正成功。这比肉眼看图可靠得多也能发现「看起来正常但像素被改」的隐蔽问题。// 端到端验证发送前和合包后各算一次 String sendMd5 md5(FIleUtils.fileToBytes(test.jpg)); // ... 发送与接收 ... String recvMd5 md5(FIleUtils.fileToBytes(received.jpg)); System.out.println(一致: sendMd5.equals(recvMd5));参数说明MD5 只用于验证不用于安全场景。如果图片大算 MD5 有开销可以只在调试阶段开。另外SendAccept.java的存在说明这个例子可能带了简单的确认机制。如果要做可靠传输可以在服务端收齐后回一个「完成」包客户端收到才认为发送成功超时未收到就重发整图或缺失分片。这是从「能收」到「可靠收」的关键一步也是这个源码包可以继续扩展的方向。从那以后我每次做 UDP 分包都强制先跑一遍小图、再跑大图、最后跑连续多图三步都过才敢上真实环境。希望帮到你。本文还有配套的精品资源点击获取 UDP分包传图实战：自定义包头校验与图片重组方案
简介这是一份面向Java网络编程学习者与初学者的UDP图片传输实战示例聚焦UDP协议下图片数据的分包发送与合包还原这一典型场景。资源通过客户端将图片转为字节数据、附加鉴权信息后分包发送服务端对每个UDP包进行正确性校验避免他人伪造或错误包被解析再将合法包合并还原为完整图片帮助读者理解UDP不可靠传输下的分包、校验与重组思路。压缩包共7个文件包含6个Java源码与1份使用说明txt整体约5KB源码按客户端发送、服务端接收、UDP包头封装、文件工具等职责拆分结构清晰便于对照阅读。目前已有431人学习下载适合希望掌握Java UDP通信、数据校验与图片字节流处理的中级开发者参考也可作为课程设计或网络实验的练手素材。1. UDP 分包传图为什么我宁愿手写校验也不直接上 TCP前阵子帮一个做工业相机的朋友排查问题他们的设备通过 UDP 往服务器推图片结果十张里有三张是花的还有两张干脆打不开。抓包一看发送端把一张 200KB 的 JPEG 直接塞进一个 UDP 包IP 层分片后只要丢一片整张图就废了。这个udp_分包_和包.rar里的例子解决的正是这个场景客户端把图片转成字节数组加鉴权头切成固定大小的包发出去服务端逐包校验、去重、按序合并最后还原成一张完整图片。它适合两类人一是正在用 UDP 做实时图传、又不想被 TCP 队头阻塞拖累的开发者二是想搞懂 UDP 应用层分包到底该怎么设计校验和重组逻辑的学习者。Java 写的六个源文件加一份说明结构不复杂但把「怎么保证收到的包是自己的、且没坏」这件事讲得比较透。2. 拆开这个包六个 Java 文件各自扛什么活2.1 从文件清单反推模块职责拿到一个源码包我习惯先看文件命名和数量基本能猜出架构。这个包里六个 Java 文件加一个说明文档分工很清晰文件名推测职责关键点SendUdp.java客户端入口读图、转字节、调分包逻辑SendAccept.java客户端发送确认处理服务端回执或重传BasicUdpRemoteRequestBuffer.java缓冲区管理按 remote 地址缓存分片UdpHeader.java自定义包头鉴权、序号、总包数等字段Server.java服务端入口收包、校验、触发合包FIleUtils.java文件工具字节与文件互转UdpHeader.java是整个方案的核心。UDP 本身只保证「发出去」不保证「到、对、序」所以应用层必须自己造一个头。常见做法是在每个包前面加固定长度的字节段里面塞进图片 ID、分片序号、总分片数、数据长度和一个校验字段。服务端收到后先读头校验通过才把数据体放进缓冲区对应位置。BasicUdpRemoteRequestBuffer.java这个名字里的 Buffer 很关键。UDP 是无连接的同一个服务端可能同时收到多个客户端的包必须按来源地址隔离缓冲区否则 A 的图会和 B 的图拼在一起。这个类大概率维护了一个MapSocketAddress, 分片集合的结构。2.2 为什么不用 TCP选型理由要讲清有人会问传图片为什么不用 TCP省得自己分包。这里有个边界TCP 的可靠传输伴随队头阻塞一个包丢了后面全等着对于实时性要求高、能容忍偶尔丢帧的场景比如监控预览、传感器快照UDP 加应用层重组反而更可控。但这个例子的定位不是「高吞吐流媒体」而是「单张图片的可靠传输」所以它必须在应用层把 TCP 干的活补回来分包、校验、确认、重组。理解这一点后面看代码就不会觉得「多此一举」。提示如果你的场景是持续视频流这个例子的「整图重组」模式需要改造不能直接套用。3. 客户端分包发送字节转换、鉴权头与切包逻辑3.1 图片转字节与包头设计客户端第一步是把图片文件读成字节数组然后按 MTU 减去包头长度来切分。以太网 MTU 通常 1500 字节减去 IP 头 20、UDP 头 8留给应用层约 1472 字节。实际工程里我会留余量用 1024 或 1200 作为每包数据体大小避免 IP 层再分片。包头字段的设计直接决定服务端能不能校验。参考这个例子的思路一个够用的头至少包含// UdpHeader.java 思路示意固定长度包头便于服务端按偏移读取 public class UdpHeader { public static final int HEADER_LEN 16; // 固定16字节头 private int magic; // 魔数快速识别是否为本协议包 private int imageId; // 图片标识区分不同图片 private int totalPackets; // 总分片数 private int packetIndex; // 当前分片序号从0开始 private int dataLen; // 本包数据体实际长度 private int checksum; // 数据体校验值常用CRC32或简单累加和 // 序列化为字节数组服务端按同样偏移反序列化 public byte[] toBytes() { /* 按大端序写入 ByteBuffer */ } public static UdpHeader parse(byte[] raw) { /* 按偏移读取 */ } }逻辑说明magic是防串包的第一道门服务端收到非本协议的包直接丢。imageId配合来源地址能区分同一客户端连续发的多张图。packetIndex和totalPackets让服务端知道什么时候收齐。checksum是第二道门防止数据体在传输中被改坏。参数说明HEADER_LEN一旦定下客户端和服务端必须一致改一处就得同步改另一处这是血泪经验。checksum用 CRC32 比简单累加和更能发现字节错位代价是多几行代码。3.2 切包与发送循环// SendUdp.java 核心发送逻辑示意 byte[] imageBytes FIleUtils.fileToBytes(test.jpg); int dataPerPacket 1024; // 每包数据体大小留足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)); // 可选每包之间微睡眠避免瞬时打爆接收缓冲 }逻辑说明循环按dataPerPacket切分最后一包长度用Math.min兜住。每包都重新构造头把序号和校验写进去。concat是自定义的字节拼接方法先头后体。参数说明dataPerPacket设 1024 是保守值局域网可以试 1400公网建议不超过 1200。imageId用递增或时间戳避免多张图混淆。发送循环里加不加睡眠取决于接收端缓冲区大小和网络抖动丢包严重时先查这里。注意UDP 发送本身不阻塞循环发太快会把本机发送缓冲和对方接收缓冲一起打满表现为「发成功了但对方没收到」。这是新手最容易翻车的地方。4. 服务端校验与合包怎么判断包是自己的、且没坏4.1 校验的三层防线服务端收到包后不能直接往缓冲区塞必须先过三关。第一关是来源过滤只处理已知客户端的地址或者至少按地址隔离缓冲区。第二关是包头校验magic不对、dataLen和实际长度对不上、packetIndex越界都直接丢。第三关是数据体校验用同样的 CRC32 算法算一遍和头里的checksum比对不一致说明数据坏了。// 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; // 不是本协议包 byte[] body Arrays.copyOfRange(raw, UdpHeader.HEADER_LEN, raw.length); if (body.length ! header.getDataLen()) return; // 长度不符 if (crc32(body) ! header.getChecksum()) return; // 校验失败 // 通过校验按来源地址imageId放入缓冲区 buffer.put(dp.getSocketAddress(), header, body);逻辑说明Arrays.copyOf截取实际收到的长度因为dp.getData()返回的是整个缓冲区尾部有空白。校验顺序从廉价到昂贵先看长度和魔数再做 CRC减少无效计算。参数说明缓冲区buf要大于最大可能包长2048 够用。crc32必须和客户端用同一套实现多项式一致否则永远校验不过。4.2 合包触发与图片还原合包的关键是判断「收齐了」。缓冲区按imageId维护一个分片数组每收到一个合法包就填入对应下标同时计数。当计数等于totalPackets按序拼接所有数据体写回文件。// BasicUdpRemoteRequestBuffer.java 合包示意 // 每个来源imageId对应一个分片容器 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) { // 去重防止重复包重复计数 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判断实现去重重复包不重复计数否则计数虚高会提前触发合包拼出残缺图片。参数说明key用地址加imageId保证多客户端隔离。合包后立即清理 map防止内存泄漏——长时间运行的服务端如果不清理缓冲区会越堆越大。提示合并时按数组下标顺序拼接不要依赖收到顺序。UDP 到达顺序是乱的这是它和 TCP 最本质的区别之一。5. 避坑与排查那些让我加班到凌晨的 UDP 问题5.1 图片花屏或打不开现象服务端生成了文件但打开是花的或直接报错。原因通常是分片丢失或错位但计数却显示收齐了。排查时先打印每个分片的长度和校验结果重点看有没有null分片被当成空数组拼接。解决合包前再遍历一次数组任何下标为null就判定未收齐不触发合并。5.2 校验永远不过现象客户端发的包服务端 CRC 全部对不上。原因多半是两端 CRC 实现的多项式或初始值不一致或者客户端算的是「头体」而服务端只算「体」。解决统一校验范围只对数据体算把算法封装成两端共用的工具方法别各写各的。5.3 大图发送后服务端只收到前几包现象小图正常大图丢包严重。原因是发送循环太快接收缓冲区溢出。解决在发送循环里加短暂Thread.sleep(1)或者用DatagramSocket.setSendBufferSize调大发送缓冲接收端也调大setReceiveBufferSize。iperf3 打流测试时也会遇到类似现象本质是缓冲和速率不匹配。5.4 多张图串在一起现象连续发两张图服务端拼出一张「缝合怪」。原因是imageId没变或缓冲区 key 设计不当。解决每张图用唯一imageId缓冲区 key 必须包含来源地址和imageId合包后立刻清理。5.5 端口被占用或收不到包现象服务端启动报错或客户端发了没反应。先确认端口没被占再确认防火墙放行。UDP 端口测试可以用netstat -anu看监听状态。如果服务端绑定了127.0.0.1外部客户端连不上要绑0.0.0.0。6. 进阶把校验从 CRC32 换成自定义规则以及我的验证习惯这个例子的校验用的是固定算法实际项目里我会把校验字段做成可配置。比如工业场景要求更强的完整性可以把 CRC32 换成 CRC32C 或者加一层简单哈希。改的时候只动UdpHeader和两端的校验工具类包头长度不变兼容性最好。验证合包是否正确我有个笨但有效的习惯客户端发图前先算整张图的 MD5服务端合包后再算一次两个值对上才算真正成功。这比肉眼看图可靠得多也能发现「看起来正常但像素被改」的隐蔽问题。// 端到端验证发送前和合包后各算一次 String sendMd5 md5(FIleUtils.fileToBytes(test.jpg)); // ... 发送与接收 ... String recvMd5 md5(FIleUtils.fileToBytes(received.jpg)); System.out.println(一致: sendMd5.equals(recvMd5));参数说明MD5 只用于验证不用于安全场景。如果图片大算 MD5 有开销可以只在调试阶段开。另外SendAccept.java的存在说明这个例子可能带了简单的确认机制。如果要做可靠传输可以在服务端收齐后回一个「完成」包客户端收到才认为发送成功超时未收到就重发整图或缺失分片。这是从「能收」到「可靠收」的关键一步也是这个源码包可以继续扩展的方向。从那以后我每次做 UDP 分包都强制先跑一遍小图、再跑大图、最后跑连续多图三步都过才敢上真实环境。希望帮到你。本文还有配套的精品资源点击获取