尧图网页设计 
简介这份源码资源面向Java网络编程学习者与分布式系统入门开发者围绕UDP协议不可靠性这一核心痛点给出了一套可运行的可靠通信系统完整实现。项目按客户端与服务器端分目录组织涵盖序列号与确认机制、超时重传、CRC校验、流量控制等可靠性策略并借助DatagramSocket与DatagramPacket完成数据收发是理解传输层协议改造与网络编程API的实用范例。压缩包共132个文件约1.13MB以43个java源文件与63个class编译文件为主体另含9个xml配置、3个jar依赖及少量图片资源源码与配置层次分明便于对照阅读与二次调试。目前已有187人学习下载。通过研读客户端请求发起、服务器循环接收与确认响应、数据包序列化反序列化及错误处理等关键环节读者可掌握在Java中构建可靠UDP通信的完整思路为网络编程与分布式系统设计积累实操经验。1. 从一份 class 文件清单说起这套 Java UDP 可靠通讯源码到底能跑出什么拿到这个压缩包第一眼看到的不是.java而是XmlUtil.class、DAOImpl.class、ClientConnectionThread.class、DataPacket.class、ServerMessageThread.class、friendChat.class、ChatClientFriendList.class、otherOnline.class、delteFriend.class这一串编译产物很多人会愣一下——源码包里怎么全是 class其实这恰恰说明它是一份「已经跑通过、被反编译或直接打包」的课程设计级工程作者把编译后的字节码和资源一起塞进了 rar。它要解决的问题很具体用 UDP 做一套带好友列表、在线状态、单聊窗口的通讯系统同时自己补上 UDP 天生缺失的可靠性。适合谁正在做网络编程课设、想搞懂DatagramSocket怎么配合序列号做重传、或者面试前想把「UDP 和 TCP 协议的区别」从背答案变成能画时序图的人。这套东西不是生产级 IM但它是把「不可靠传输上盖可靠层」这件事拆到类级别的最好教具。2. 拆开 DataPacket 与确认机制UDP 可靠传输在 Java 里怎么落地2.1 为什么选 UDP 而不是直接上 TCP课程设计里选 UDP 做可靠通讯表面看是自找麻烦实际有它的合理性。TCP 把可靠性、顺序、拥塞控制全包了你写出来的代码只有Socket和ServerSocket两个类根本看不到「确认」「重传」「超时」这些机制长什么样。而 UDP 只给你DatagramSocket和DatagramPacket剩下的全得自己搭。这套源码的价值就在这——它逼你把可靠传输的每个零件都亲手装一遍。从DataPacket.class这个类名能推断出作者没有直接把业务字符串丢进DatagramPacket而是先封装了一层自定义包结构。常见做法是包头放序列号seq、确认号ack、标志位SYN/ACK/FIN、数据长度包体放实际负载。这样接收端才能判断「这个包是不是我要的」「要不要回确认」「是不是重复包」。// DataPacket 的典型字段设计根据 class 名反推的结构 public class DataPacket { private int seq; // 序列号标识发送顺序 private int ack; // 确认号回应对方收到的 seq private int flag; // 标志位0数据 1确认 2连接请求 3断开 private byte[] data; // 实际业务负载 private long timestamp; // 发送时间戳用于计算 RTT // ... 序列化/反序列化方法 }参数说明seq每发一个数据包自增接收端靠它排序和去重ack只在确认包里有效值等于「我已连续收到 seq 之前的全部包」flag决定这个包走哪条处理分支timestamp是超时重传的判据。逻辑上发送方维护一个「已发送未确认」队列每发一包启动一个定时器超时未收到对应 ack 就重发。2.2 序列号、确认与超时重传的最小闭环可靠性的核心是一个闭环发→等确认→超时重发。这套源码里ClientConnectionThread和ServerMessageThread大概率分别承担客户端和服务端的收发线程。我一般会这样组织发送逻辑// 发送方带超时重传的发送循环 private static final int TIMEOUT 1000; // 超时阈值毫秒 private static final int MAX_RETRY 5; // 最大重传次数 public void sendReliable(DatagramSocket socket, InetAddress addr, int port, byte[] payload) throws Exception { int seq nextSeq; DataPacket packet new DataPacket(seq, 0, 0, payload, System.currentTimeMillis()); byte[] bytes packet.toBytes(); DatagramPacket dp new DatagramPacket(bytes, bytes.length, addr, port); for (int retry 0; retry MAX_RETRY; retry) { socket.send(dp); socket.setSoTimeout(TIMEOUT); try { byte[] buf new byte[1024]; DatagramPacket ackDp new DatagramPacket(buf, buf.length); socket.receive(ackDp); // 阻塞等确认 DataPacket ackPkt DataPacket.fromBytes(ackDp.getData()); if (ackPkt.getAck() seq) { return; // 确认收到退出 } } catch (SocketTimeoutException e) { // 超时进入下一轮重传 } } throw new RuntimeException(重传 MAX_RETRY 次仍未确认seq seq); }逻辑说明setSoTimeout让receive最多阻塞 1 秒超时抛异常后循环重发。MAX_RETRY防止无限重传拖死线程。这里有个容易翻车的点——socket.setSoTimeout是设在 socket 上的全局属性如果同一个 socket 既发又收超时值会互相干扰所以常见做法是发送和接收各用一个DatagramSocket或者用单独的接收线程。参数怎么调TIMEOUT设太小局域网里没事跨网段稍微抖一下就疯狂重传设太大丢包后恢复慢。经验值是局域网 200~500ms公网 1000~2000ms。MAX_RETRY一般 3~5 次再多说明链路已经不可用该报错而不是硬扛。2.3 用 XmlUtil 和 DAOImpl 看数据持久化与好友列表XmlUtil.class和DAOImpl.class这两个类暴露了这套系统的数据层设计。XmlUtil大概率负责把好友列表、聊天记录序列化成 XML 存本地DAOImpl则是数据访问接口的实现。为什么用 XML 而不是数据库课程设计场景下XML 不需要装 MySQL、不用配连接池一个文件读写就搞定交作业时老师双击就能跑。// XmlUtil 的典型用法读写好友列表 public class XmlUtil { public static void saveFriends(ListFriend friends, String filePath) { try (BufferedWriter writer new BufferedWriter(new FileWriter(filePath))) { writer.write(friends\n); for (Friend f : friends) { writer.write( friend ip\ f.getIp() \ port\ f.getPort() \ f.getName() /friend\n); } writer.write(/friends); } catch (IOException e) { e.printStackTrace(); } } }DAOImpl则把「增删好友」「更新在线状态」这些操作统一成方法delteFriend.class注意作者拼写成了 delte不是 delete和otherOnline.class就是它的调用方。这种分层在课设里算规范的了——界面层、业务层、数据层分开改起来不至于牵一发动全身。3. 客户端与服务端怎么跑起来从 DatagramSocket 到聊天窗口3.1 服务端启动流程与端口绑定服务端是整个系统的锚点它得先起来客户端才知道往哪发。从ServerMessageThread.class和ClientConnectionThread.class的命名看服务端为每个上线客户端开一个连接线程主线程负责监听和分发。// 服务端主循环接收并分发到处理线程 public class ChatServer { private static final int PORT 8888; private static MapString, ClientInfo onlineUsers new ConcurrentHashMap(); public static void main(String[] args) throws Exception { DatagramSocket serverSocket new DatagramSocket(PORT); System.out.println(服务端启动监听端口 PORT); byte[] buf new byte[2048]; while (true) { DatagramPacket packet new DatagramPacket(buf, buf.length); serverSocket.receive(packet); // 阻塞接收 DataPacket dp DataPacket.fromBytes(packet.getData()); // 交给连接线程处理避免阻塞主接收循环 new Thread(new ClientConnectionThread(dp, packet.getAddress(), packet.getPort(), serverSocket, onlineUsers)).start(); } } }逻辑说明主循环只做一件事——收包、解析、丢给线程池或新线程。onlineUsers用ConcurrentHashMap是因为多个连接线程会并发读写在线列表普通HashMap在多线程下会出问题。端口 8888 是常见约定实际部署时如果被占用改这里就行客户端对应改。参数说明buf大小 2048 字节决定了单个 UDP 包的上限。UDP 理论最大 65507 字节但实际网络里超过 MTU约 1500 字节就会分片分片丢一个整个包就废了。所以聊天消息一般控制在 1KB 以内大文件传输得在应用层自己分块。3.2 客户端登录、好友列表与消息收发客户端这边ChatClientFriendList.class管好友列表界面friendChat.class管单聊窗口otherOnline.class管在线用户刷新。启动顺序一般是先起一个接收线程监听服务端推送再发登录包然后拉好友列表。// 客户端启动接收线程 发送登录请求 public class ChatClient { private DatagramSocket socket; private InetAddress serverAddr; private static final int SERVER_PORT 8888; public void start() throws Exception { socket new DatagramSocket(); // 客户端用随机端口 serverAddr InetAddress.getByName(127.0.0.1); // 接收线程独立跑不阻塞界面 new Thread(new ClientReceiveThread(socket)).start(); // 发送登录包 DataPacket login new DataPacket(nextSeq, 0, 2, LOGIN:user1.getBytes(), System.currentTimeMillis()); byte[] data login.toBytes(); socket.send(new DatagramPacket(data, data.length, serverAddr, SERVER_PORT)); } }逻辑说明客户端DatagramSocket不指定端口系统随机分配这样多个客户端可以在同一台机器上跑而不冲突。接收线程必须独立否则界面会卡死。登录包用flag2标识服务端收到后把该用户加入onlineUsers再广播给其他在线用户。参数说明InetAddress.getByName(127.0.0.1)是本机测试用局域网联机改成服务端的实际 IP。nextSeq是客户端自己的序列号计数器和服务端的独立。3.3 好友上下线与消息转发的线程模型otherOnline.class和ServerMessageThread.class配合完成在线状态同步。常见做法是服务端维护onlineUsers映射用户名→IP端口当有人上线或下线遍历这个映射给每个在线用户发一个状态更新包。客户端收到后刷新ChatClientFriendList的显示。// 服务端广播在线状态变化 public void broadcastOnlineStatus(DatagramSocket socket, MapString, ClientInfo users) { StringBuilder sb new StringBuilder(ONLINE:); for (String name : users.keySet()) { sb.append(name).append(,); } byte[] data sb.toString().getBytes(); for (ClientInfo info : users.values()) { try { DataPacket dp new DataPacket(0, 0, 1, data, System.currentTimeMillis()); byte[] bytes dp.toBytes(); socket.send(new DatagramPacket(bytes, bytes.length, info.getAddress(), info.getPort())); } catch (IOException e) { // 单个用户发送失败不影响其他人 } } }逻辑说明广播时逐个发送单个失败只记录不中断这是 UDP 场景下的容错习惯。flag1表示这是状态通知包客户端据此区分是聊天消息还是系统通知。4. 避坑与排查UDP 可靠通讯最容易翻车的五个地方4.1 现象客户端能发不能收界面一直不刷新原因接收线程和发送共用了同一个DatagramSocket发送时setSoTimeout把超时设成了 1 秒接收线程的receive也跟着 1 秒超时频繁抛SocketTimeoutException被吞掉看起来就像收不到。解决发送和接收各用一个DatagramSocket或者接收线程里不要依赖setSoTimeout用独立的超时控制。4.2 现象局域网内正常换台机器就丢包严重原因TIMEOUT设得太短比如 200ms跨网段 RTT 波动大确认包还没回来就重传了导致接收端收到大量重复包。解决把TIMEOUT调到 1000ms 以上同时在接收端做去重——维护一个「已处理 seq 集合」重复 seq 直接丢弃并重发确认。4.3 现象中文消息收到是乱码原因getBytes()不指定字符集用的是平台默认编码Windows 上是 GBKLinux 上是 UTF-8跨平台就乱。解决发送端getBytes(StandardCharsets.UTF_8)接收端new String(data, StandardCharsets.UTF_8)两端统一。4.4 现象好友列表删了人重启后又回来了原因delteFriend.class只改了内存里的列表没调XmlUtil.saveFriends落盘或者落盘路径写的是相对路径工作目录一变就写到别处去了。解决删除后立即调DAOImpl的保存方法路径用System.getProperty(user.dir)拼绝对路径。4.5 现象服务端跑久了内存暴涨原因onlineUsers里下线的用户没清理或者每个连接都 new 一个线程但线程结束后没回收引用。解决客户端下线时发flag3的断开包服务端收到后从onlineUsers移除线程用线程池管理别无限 new。5. 进阶把这份课设源码改成能演示「丢包重传」的教学工具这套源码默认在局域网跑基本不丢包所以你根本看不到重传逻辑生效。想真正验证可靠性机制我一般会加一个「人为丢包」开关在服务端接收循环里随机丢弃一定比例的包然后观察客户端是否重传、最终消息是否完整。// 在服务端接收循环里注入丢包模拟弱网 private static final double LOSS_RATE 0.3; // 30% 丢包率 public static void main(String[] args) throws Exception { DatagramSocket serverSocket new DatagramSocket(PORT); byte[] buf new byte[2048]; Random random new Random(); while (true) { DatagramPacket packet new DatagramPacket(buf, buf.length); serverSocket.receive(packet); if (random.nextDouble() LOSS_RATE) { continue; // 直接丢弃不处理 } DataPacket dp DataPacket.fromBytes(packet.getData()); new Thread(new ClientConnectionThread(dp, packet.getAddress(), packet.getPort(), serverSocket, onlineUsers)).start(); } }把LOSS_RATE从 0 逐步调到 0.5你能亲眼看到客户端发送后等不到确认1 秒后重传重传第二次才成功。这时候再去看DataPacket里的seq和ack字段就完全不是背概念了。验证方法很简单——在发送端打印每次重传的 seq 和重试次数在接收端打印收到的 seq 列表对比一下就知道有没有重复、有没有丢。丢包率预期现象观察点0%无重传一次成功发送日志无 retry30%偶发重传 1~2 次retry 计数偶尔 050%频繁重传部分消息达 MAX_RETRY有异常抛出70%大量消息失败需调大 MAX_RETRY 或 TIMEOUT还有一个进阶玩法把TIMEOUT做成动态的根据每次确认的 RTT 算加权平均类似 TCP 的自适应重传。公式是SRTT α * SRTT (1-α) * RTTRTO SRTT * 2α 取 0.8~0.9。这样在 RTT 波动时不会因为固定超时值而误重传。改完之后你会发现同样 30% 丢包率下重传次数明显下降。从那以后我每次拿到这种「号称可靠」的 UDP 源码都强制先跑一遍人为丢包测试不看到重传日志就不认它真做了可靠性。希望这套拆解能帮到你把课设从「能跑」推到「知道为什么能跑」。本文还有配套的精品资源点击获取 Java UDP可靠通讯源码解析：从DataPacket到重传机制
简介这份源码资源面向Java网络编程学习者与分布式系统入门开发者围绕UDP协议不可靠性这一核心痛点给出了一套可运行的可靠通信系统完整实现。项目按客户端与服务器端分目录组织涵盖序列号与确认机制、超时重传、CRC校验、流量控制等可靠性策略并借助DatagramSocket与DatagramPacket完成数据收发是理解传输层协议改造与网络编程API的实用范例。压缩包共132个文件约1.13MB以43个java源文件与63个class编译文件为主体另含9个xml配置、3个jar依赖及少量图片资源源码与配置层次分明便于对照阅读与二次调试。目前已有187人学习下载。通过研读客户端请求发起、服务器循环接收与确认响应、数据包序列化反序列化及错误处理等关键环节读者可掌握在Java中构建可靠UDP通信的完整思路为网络编程与分布式系统设计积累实操经验。1. 从一份 class 文件清单说起这套 Java UDP 可靠通讯源码到底能跑出什么拿到这个压缩包第一眼看到的不是.java而是XmlUtil.class、DAOImpl.class、ClientConnectionThread.class、DataPacket.class、ServerMessageThread.class、friendChat.class、ChatClientFriendList.class、otherOnline.class、delteFriend.class这一串编译产物很多人会愣一下——源码包里怎么全是 class其实这恰恰说明它是一份「已经跑通过、被反编译或直接打包」的课程设计级工程作者把编译后的字节码和资源一起塞进了 rar。它要解决的问题很具体用 UDP 做一套带好友列表、在线状态、单聊窗口的通讯系统同时自己补上 UDP 天生缺失的可靠性。适合谁正在做网络编程课设、想搞懂DatagramSocket怎么配合序列号做重传、或者面试前想把「UDP 和 TCP 协议的区别」从背答案变成能画时序图的人。这套东西不是生产级 IM但它是把「不可靠传输上盖可靠层」这件事拆到类级别的最好教具。2. 拆开 DataPacket 与确认机制UDP 可靠传输在 Java 里怎么落地2.1 为什么选 UDP 而不是直接上 TCP课程设计里选 UDP 做可靠通讯表面看是自找麻烦实际有它的合理性。TCP 把可靠性、顺序、拥塞控制全包了你写出来的代码只有Socket和ServerSocket两个类根本看不到「确认」「重传」「超时」这些机制长什么样。而 UDP 只给你DatagramSocket和DatagramPacket剩下的全得自己搭。这套源码的价值就在这——它逼你把可靠传输的每个零件都亲手装一遍。从DataPacket.class这个类名能推断出作者没有直接把业务字符串丢进DatagramPacket而是先封装了一层自定义包结构。常见做法是包头放序列号seq、确认号ack、标志位SYN/ACK/FIN、数据长度包体放实际负载。这样接收端才能判断「这个包是不是我要的」「要不要回确认」「是不是重复包」。// DataPacket 的典型字段设计根据 class 名反推的结构 public class DataPacket { private int seq; // 序列号标识发送顺序 private int ack; // 确认号回应对方收到的 seq private int flag; // 标志位0数据 1确认 2连接请求 3断开 private byte[] data; // 实际业务负载 private long timestamp; // 发送时间戳用于计算 RTT // ... 序列化/反序列化方法 }参数说明seq每发一个数据包自增接收端靠它排序和去重ack只在确认包里有效值等于「我已连续收到 seq 之前的全部包」flag决定这个包走哪条处理分支timestamp是超时重传的判据。逻辑上发送方维护一个「已发送未确认」队列每发一包启动一个定时器超时未收到对应 ack 就重发。2.2 序列号、确认与超时重传的最小闭环可靠性的核心是一个闭环发→等确认→超时重发。这套源码里ClientConnectionThread和ServerMessageThread大概率分别承担客户端和服务端的收发线程。我一般会这样组织发送逻辑// 发送方带超时重传的发送循环 private static final int TIMEOUT 1000; // 超时阈值毫秒 private static final int MAX_RETRY 5; // 最大重传次数 public void sendReliable(DatagramSocket socket, InetAddress addr, int port, byte[] payload) throws Exception { int seq nextSeq; DataPacket packet new DataPacket(seq, 0, 0, payload, System.currentTimeMillis()); byte[] bytes packet.toBytes(); DatagramPacket dp new DatagramPacket(bytes, bytes.length, addr, port); for (int retry 0; retry MAX_RETRY; retry) { socket.send(dp); socket.setSoTimeout(TIMEOUT); try { byte[] buf new byte[1024]; DatagramPacket ackDp new DatagramPacket(buf, buf.length); socket.receive(ackDp); // 阻塞等确认 DataPacket ackPkt DataPacket.fromBytes(ackDp.getData()); if (ackPkt.getAck() seq) { return; // 确认收到退出 } } catch (SocketTimeoutException e) { // 超时进入下一轮重传 } } throw new RuntimeException(重传 MAX_RETRY 次仍未确认seq seq); }逻辑说明setSoTimeout让receive最多阻塞 1 秒超时抛异常后循环重发。MAX_RETRY防止无限重传拖死线程。这里有个容易翻车的点——socket.setSoTimeout是设在 socket 上的全局属性如果同一个 socket 既发又收超时值会互相干扰所以常见做法是发送和接收各用一个DatagramSocket或者用单独的接收线程。参数怎么调TIMEOUT设太小局域网里没事跨网段稍微抖一下就疯狂重传设太大丢包后恢复慢。经验值是局域网 200~500ms公网 1000~2000ms。MAX_RETRY一般 3~5 次再多说明链路已经不可用该报错而不是硬扛。2.3 用 XmlUtil 和 DAOImpl 看数据持久化与好友列表XmlUtil.class和DAOImpl.class这两个类暴露了这套系统的数据层设计。XmlUtil大概率负责把好友列表、聊天记录序列化成 XML 存本地DAOImpl则是数据访问接口的实现。为什么用 XML 而不是数据库课程设计场景下XML 不需要装 MySQL、不用配连接池一个文件读写就搞定交作业时老师双击就能跑。// XmlUtil 的典型用法读写好友列表 public class XmlUtil { public static void saveFriends(ListFriend friends, String filePath) { try (BufferedWriter writer new BufferedWriter(new FileWriter(filePath))) { writer.write(friends\n); for (Friend f : friends) { writer.write( friend ip\ f.getIp() \ port\ f.getPort() \ f.getName() /friend\n); } writer.write(/friends); } catch (IOException e) { e.printStackTrace(); } } }DAOImpl则把「增删好友」「更新在线状态」这些操作统一成方法delteFriend.class注意作者拼写成了 delte不是 delete和otherOnline.class就是它的调用方。这种分层在课设里算规范的了——界面层、业务层、数据层分开改起来不至于牵一发动全身。3. 客户端与服务端怎么跑起来从 DatagramSocket 到聊天窗口3.1 服务端启动流程与端口绑定服务端是整个系统的锚点它得先起来客户端才知道往哪发。从ServerMessageThread.class和ClientConnectionThread.class的命名看服务端为每个上线客户端开一个连接线程主线程负责监听和分发。// 服务端主循环接收并分发到处理线程 public class ChatServer { private static final int PORT 8888; private static MapString, ClientInfo onlineUsers new ConcurrentHashMap(); public static void main(String[] args) throws Exception { DatagramSocket serverSocket new DatagramSocket(PORT); System.out.println(服务端启动监听端口 PORT); byte[] buf new byte[2048]; while (true) { DatagramPacket packet new DatagramPacket(buf, buf.length); serverSocket.receive(packet); // 阻塞接收 DataPacket dp DataPacket.fromBytes(packet.getData()); // 交给连接线程处理避免阻塞主接收循环 new Thread(new ClientConnectionThread(dp, packet.getAddress(), packet.getPort(), serverSocket, onlineUsers)).start(); } } }逻辑说明主循环只做一件事——收包、解析、丢给线程池或新线程。onlineUsers用ConcurrentHashMap是因为多个连接线程会并发读写在线列表普通HashMap在多线程下会出问题。端口 8888 是常见约定实际部署时如果被占用改这里就行客户端对应改。参数说明buf大小 2048 字节决定了单个 UDP 包的上限。UDP 理论最大 65507 字节但实际网络里超过 MTU约 1500 字节就会分片分片丢一个整个包就废了。所以聊天消息一般控制在 1KB 以内大文件传输得在应用层自己分块。3.2 客户端登录、好友列表与消息收发客户端这边ChatClientFriendList.class管好友列表界面friendChat.class管单聊窗口otherOnline.class管在线用户刷新。启动顺序一般是先起一个接收线程监听服务端推送再发登录包然后拉好友列表。// 客户端启动接收线程 发送登录请求 public class ChatClient { private DatagramSocket socket; private InetAddress serverAddr; private static final int SERVER_PORT 8888; public void start() throws Exception { socket new DatagramSocket(); // 客户端用随机端口 serverAddr InetAddress.getByName(127.0.0.1); // 接收线程独立跑不阻塞界面 new Thread(new ClientReceiveThread(socket)).start(); // 发送登录包 DataPacket login new DataPacket(nextSeq, 0, 2, LOGIN:user1.getBytes(), System.currentTimeMillis()); byte[] data login.toBytes(); socket.send(new DatagramPacket(data, data.length, serverAddr, SERVER_PORT)); } }逻辑说明客户端DatagramSocket不指定端口系统随机分配这样多个客户端可以在同一台机器上跑而不冲突。接收线程必须独立否则界面会卡死。登录包用flag2标识服务端收到后把该用户加入onlineUsers再广播给其他在线用户。参数说明InetAddress.getByName(127.0.0.1)是本机测试用局域网联机改成服务端的实际 IP。nextSeq是客户端自己的序列号计数器和服务端的独立。3.3 好友上下线与消息转发的线程模型otherOnline.class和ServerMessageThread.class配合完成在线状态同步。常见做法是服务端维护onlineUsers映射用户名→IP端口当有人上线或下线遍历这个映射给每个在线用户发一个状态更新包。客户端收到后刷新ChatClientFriendList的显示。// 服务端广播在线状态变化 public void broadcastOnlineStatus(DatagramSocket socket, MapString, ClientInfo users) { StringBuilder sb new StringBuilder(ONLINE:); for (String name : users.keySet()) { sb.append(name).append(,); } byte[] data sb.toString().getBytes(); for (ClientInfo info : users.values()) { try { DataPacket dp new DataPacket(0, 0, 1, data, System.currentTimeMillis()); byte[] bytes dp.toBytes(); socket.send(new DatagramPacket(bytes, bytes.length, info.getAddress(), info.getPort())); } catch (IOException e) { // 单个用户发送失败不影响其他人 } } }逻辑说明广播时逐个发送单个失败只记录不中断这是 UDP 场景下的容错习惯。flag1表示这是状态通知包客户端据此区分是聊天消息还是系统通知。4. 避坑与排查UDP 可靠通讯最容易翻车的五个地方4.1 现象客户端能发不能收界面一直不刷新原因接收线程和发送共用了同一个DatagramSocket发送时setSoTimeout把超时设成了 1 秒接收线程的receive也跟着 1 秒超时频繁抛SocketTimeoutException被吞掉看起来就像收不到。解决发送和接收各用一个DatagramSocket或者接收线程里不要依赖setSoTimeout用独立的超时控制。4.2 现象局域网内正常换台机器就丢包严重原因TIMEOUT设得太短比如 200ms跨网段 RTT 波动大确认包还没回来就重传了导致接收端收到大量重复包。解决把TIMEOUT调到 1000ms 以上同时在接收端做去重——维护一个「已处理 seq 集合」重复 seq 直接丢弃并重发确认。4.3 现象中文消息收到是乱码原因getBytes()不指定字符集用的是平台默认编码Windows 上是 GBKLinux 上是 UTF-8跨平台就乱。解决发送端getBytes(StandardCharsets.UTF_8)接收端new String(data, StandardCharsets.UTF_8)两端统一。4.4 现象好友列表删了人重启后又回来了原因delteFriend.class只改了内存里的列表没调XmlUtil.saveFriends落盘或者落盘路径写的是相对路径工作目录一变就写到别处去了。解决删除后立即调DAOImpl的保存方法路径用System.getProperty(user.dir)拼绝对路径。4.5 现象服务端跑久了内存暴涨原因onlineUsers里下线的用户没清理或者每个连接都 new 一个线程但线程结束后没回收引用。解决客户端下线时发flag3的断开包服务端收到后从onlineUsers移除线程用线程池管理别无限 new。5. 进阶把这份课设源码改成能演示「丢包重传」的教学工具这套源码默认在局域网跑基本不丢包所以你根本看不到重传逻辑生效。想真正验证可靠性机制我一般会加一个「人为丢包」开关在服务端接收循环里随机丢弃一定比例的包然后观察客户端是否重传、最终消息是否完整。// 在服务端接收循环里注入丢包模拟弱网 private static final double LOSS_RATE 0.3; // 30% 丢包率 public static void main(String[] args) throws Exception { DatagramSocket serverSocket new DatagramSocket(PORT); byte[] buf new byte[2048]; Random random new Random(); while (true) { DatagramPacket packet new DatagramPacket(buf, buf.length); serverSocket.receive(packet); if (random.nextDouble() LOSS_RATE) { continue; // 直接丢弃不处理 } DataPacket dp DataPacket.fromBytes(packet.getData()); new Thread(new ClientConnectionThread(dp, packet.getAddress(), packet.getPort(), serverSocket, onlineUsers)).start(); } }把LOSS_RATE从 0 逐步调到 0.5你能亲眼看到客户端发送后等不到确认1 秒后重传重传第二次才成功。这时候再去看DataPacket里的seq和ack字段就完全不是背概念了。验证方法很简单——在发送端打印每次重传的 seq 和重试次数在接收端打印收到的 seq 列表对比一下就知道有没有重复、有没有丢。丢包率预期现象观察点0%无重传一次成功发送日志无 retry30%偶发重传 1~2 次retry 计数偶尔 050%频繁重传部分消息达 MAX_RETRY有异常抛出70%大量消息失败需调大 MAX_RETRY 或 TIMEOUT还有一个进阶玩法把TIMEOUT做成动态的根据每次确认的 RTT 算加权平均类似 TCP 的自适应重传。公式是SRTT α * SRTT (1-α) * RTTRTO SRTT * 2α 取 0.8~0.9。这样在 RTT 波动时不会因为固定超时值而误重传。改完之后你会发现同样 30% 丢包率下重传次数明显下降。从那以后我每次拿到这种「号称可靠」的 UDP 源码都强制先跑一遍人为丢包测试不看到重传日志就不认它真做了可靠性。希望这套拆解能帮到你把课设从「能跑」推到「知道为什么能跑」。本文还有配套的精品资源点击获取