1. 从一个“丢包”的深夜说起UDP 到底适合什么场景我第一次在生产环境里被 UDP 狠狠教育是做一个局域网设备状态上报的小系统。当时想得很简单设备每隔几秒往服务端发一个心跳包服务端收着就行用 UDP 多省事不用建连接、不用维护会话代码几行就能跑。结果上线第一天就发现后台统计到的在线设备数总比实际少那么几台偶尔还会冒出一两个“幽灵设备”——明明已经关机了状态却还挂在列表里。排查了大半天才反应过来UDP 不保证送达也不保证顺序丢一个包、乱一次序对“状态上报”这种场景就是致命的。这件事让我彻底明白一个道理UDP 不是“简化版的 TCP”它是一套完全不同的通信哲学。TCP 像打电话先拨号、对方接了才说话说的每句话对方都得“嗯”一声确认UDP 像往人群里扔纸条扔出去就不管了谁捡到算谁的捡到的顺序也可能跟你扔的顺序不一样。理解这一点你才能判断什么场景该用它、什么场景碰都别碰。这篇内容就是围绕Java Socket 网络编程中的 UDP展开把我在实际项目里踩过的坑、总结的套路、能直接抄的代码模板都摊开讲。它适合已经会写一点 Java、想搞明白网络通信底层逻辑的同学也适合做过 TCP 但一直没敢碰 UDP 的开发者。看完你至少能搞清楚三件事UDP 在 Java 里怎么用、为什么这么设计、以及真实项目里怎么把它用稳。2. 先搞懂 UDP 的脾气它和 TCP 到底差在哪2.1 用生活场景理解“无连接”这三个字很多人背概念都会说“UDP 是无连接的”但“无连接”到底意味着什么光背没用。我习惯用寄快递来类比。TCP 寄快递是这样的你先打电话给快递员快递员上门你俩确认地址、确认收件人、确认包裹没问题然后快递员拿走一路上每个中转站都扫码登记最后收件人签收你这边收到“已签收”的通知。整个过程有建立、有确认、有反馈。UDP 寄快递是这样的你把包裹往邮筒里一塞走人。邮筒不会告诉你包裹有没有被取走路上会不会丢收件人有没有收到。你唯一知道的就是“我塞进去了”。至于对方收没收到你得自己想办法——要么让对方收到后回你一条消息要么你干脆多塞几次。这个差别直接决定了 UDP 的两个核心特征开销小、速度快但不可靠。没有握手、没有确认、没有重传、没有拥塞控制头部只有 8 个字节TCP 是 20 字节起步所以它在对实时性要求高、能容忍少量丢包的场景里特别香。2.2 UDP 头部那 8 个字节里装了什么既然 UDP 这么“简陋”那它头部到底有什么其实就四个字段每个 2 字节字段作用实际意义源端口号发送方端口对方回消息时知道发给谁目的端口号接收方端口找到目标应用长度整个数据报长度包含头部最小 8 字节校验和数据完整性校验可选IPv4 下可为 0就这四样没了。没有序列号没有确认号没有窗口大小。这意味着 UDP 把“可靠性”这件事完全甩给了应用层。你想保证不丢就得自己在应用层加序号、加确认、加重传你想保证顺序就得自己排序。这也是为什么很多基于 UDP 的协议比如某些实时音视频传输方案都要在应用层做一大堆补偿逻辑。注意UDP 的校验和是可选的但在实际开发中强烈建议开启。有些网络设备会篡改数据而不更新校验和开启校验至少能帮你发现一部分损坏的包。2.3 什么时候必须用 UDP什么时候千万别用我总结了一个简单的判断标准你可以直接拿去用适合 UDP 的场景实时性优先丢一两帧无所谓语音通话、视频直播、在线游戏的位置同步请求-响应模式简单重发成本低DNS 查询、NTP 时间同步广播/组播局域网设备发现、服务公告自己能在应用层做可靠性保障有自定义协议栈的情况千万别用 UDP 的场景文件传输丢一个字节整个文件就废了支付、订单类业务丢一条消息可能就是资损需要严格顺序的数据流比如配置下发、指令序列大块数据传输UDP 单包有大小限制分片后丢一片全废我见过最离谱的用法是有人拿 UDP 传数据库备份文件理由是“TCP 太慢”。结果传十次成功一次剩下九次都在补传总耗时比 TCP 还长。这就是没搞懂 UDP 脾气的典型翻车。3. Java 里怎么玩 UDP核心 API 拆解3.1 DatagramSocket 和 DatagramPacket 这对搭档Java 把 UDP 通信封装成了两个类DatagramSocket负责“收发”DatagramPacket负责“装数据”。你可以把 Socket 理解成邮筒Packet 理解成信封。发送端的套路是创建DatagramSocket不指定端口就是随机端口把数据塞进DatagramPacket同时指定目标 IP 和端口调用socket.send(packet)关闭 socket接收端的套路是创建DatagramSocket并绑定监听端口准备一个空缓冲区包进DatagramPacket调用socket.receive(packet)这行代码会阻塞直到有包进来从 packet 里取出数据和发送方地址循环回到第 2 步继续收这里有个新手特别容易踩的坑receive方法用的DatagramPacket必须提前分配好缓冲区。如果你传一个没有 buffer 的 packet 进去会直接抛异常。而且缓冲区大小要合理太小了数据会被截断太大了浪费内存。一般设 1024 或 2048 字节够用具体看你的业务数据量。3.2 一个最小可运行的发送端和接收端先看发送端我把它写成一个可以反复发消息的小工具import java.net.DatagramPacket; import java.net.DatagramSocket; import java.net.InetAddress; import java.nio.charset.StandardCharsets; public class UdpSender { public static void main(String[] args) throws Exception { // 创建发送端 Socket不指定端口系统随机分配 try (DatagramSocket socket new DatagramSocket()) { String message hello udp; byte[] data message.getBytes(StandardCharsets.UTF_8); InetAddress target InetAddress.getByName(127.0.0.1); int targetPort 9999; DatagramPacket packet new DatagramPacket( data, data.length, target, targetPort); socket.send(packet); System.out.println(已发送: message); } } }再看接收端这里我加了一个循环让它能持续收包import java.net.DatagramPacket; import java.net.DatagramSocket; import java.nio.charset.StandardCharsets; public class UdpReceiver { public static void main(String[] args) throws Exception { int port 9999; try (DatagramSocket socket new DatagramSocket(port)) { byte[] buffer new byte[2048]; System.out.println(监听端口 port); while (true) { DatagramPacket packet new DatagramPacket(buffer, buffer.length); socket.receive(packet); String content new String( packet.getData(), packet.getOffset(), packet.getLength(), StandardCharsets.UTF_8); System.out.println(来自 packet.getAddress() : packet.getPort() - content); } } } }这段代码里有个细节值得单独说取数据时一定要用getOffset()和getLength()不要直接用getData()整个数组。因为receive每次会把数据填到 buffer 里但 buffer 是复用的上一次的残留数据可能还在后面。如果你直接new String(packet.getData())很可能把上次的尾巴也读出来出现“脏数据”。这个坑我在早期项目里踩过排查了半天才发现是缓冲区没清干净。3.3 为什么 receive 会“卡住”以及怎么优雅退出receive是阻塞方法没有数据来它就一直等。这在单线程模型里意味着你的程序会停在那里没法干别的事。解决办法有两个一是开独立线程收包主线程继续做别的。这是最常见的做法接收循环扔到一个专门的线程里跑。二是设置超时用socket.setSoTimeout(3000)这样receive最多等 3 秒超时会抛SocketTimeoutException你可以在 catch 里判断是否要继续循环。这个方式适合需要定期检查退出标志的场景。我一般推荐组合使用接收线程里设一个合理的超时比如 1 秒每次超时检查一下running标志为 false 就跳出循环。这样既能及时响应退出信号又不会因为频繁超时而浪费 CPU。socket.setSoTimeout(1000); while (running) { try { DatagramPacket packet new DatagramPacket(buffer, buffer.length); socket.receive(packet); // 处理数据 } catch (SocketTimeoutException e) { // 超时继续循环检查 running } }提示setSoTimeout设太小会导致频繁抛异常影响性能设太大退出不及时。1 秒左右是个比较平衡的值具体看你的业务对退出响应速度的要求。4. 把 UDP 用稳可靠性补偿的实战套路4.1 丢包不可怕可怕的是你不知道丢了UDP 本身不告诉你丢没丢所以第一件事就是在应用层加序号。每个包带一个自增的 seq接收端记录上一次收到的 seq如果发现跳号了就知道中间丢了。// 发送端 long seq 0; // 每次发送时 String payload seq | actualData; seq;接收端解析出 seq跟本地记录的lastSeq对比如果seq lastSeq 1正常更新 lastSeq如果seq lastSeq 1说明中间丢了包可以记录日志或触发补发请求如果seq lastSeq说明是重复包或乱序包按业务决定丢弃还是缓存这套机制不复杂但能让你对链路质量心里有数。我在一个设备上报系统里加了序号统计后才发现某个区域的网络丢包率高达 15%之前一直以为是设备本身有问题。4.2 需要确认时自己实现一个简单的 ACK如果业务要求“关键消息必须送达”那就得加确认机制。思路很直接发送方发完消息后等一个 ACK超时没收到就重发重发几次还不成功就报错。public boolean sendWithAck(DatagramSocket socket, DatagramPacket packet, int maxRetry) throws Exception { for (int i 0; i maxRetry; i) { socket.send(packet); try { socket.setSoTimeout(500); DatagramPacket ack new DatagramPacket(new byte[64], 64); socket.receive(ack); return true; // 收到 ACK } catch (SocketTimeoutException e) { // 超时重试 } } return false; }这里有几个参数需要根据实际情况调超时时间局域网可以设 100~200ms公网建议 500ms~1s重试次数一般 3 次够了太多会拖慢整体响应ACK 内容最好带上原消息的 seq避免 ACK 串包注意这种“停等”模式发一个等一个效率很低适合低频关键消息。高频场景要用滑动窗口但那就复杂了一般项目里不如直接用 TCP。4.3 广播和组播UDP 的独门绝技TCP 只能一对一UDP 可以一对多这是它不可替代的地方。Java 里实现广播很简单把目标地址设成广播地址就行InetAddress broadcastAddr InetAddress.getByName(255.255.255.255); DatagramPacket packet new DatagramPacket( data, data.length, broadcastAddr, 8888); socket.setBroadcast(true); // 必须开启广播权限 socket.send(packet);组播稍微复杂一点需要加入一个组播组InetAddress group InetAddress.getByName(230.0.0.1); MulticastSocket socket new MulticastSocket(8888); socket.joinGroup(group);组播地址范围是 224.0.0.0 到 239.255.255.255其中 224.0.0.0 到 224.0.0.255 是保留的别用。我在做局域网设备发现时用的就是组播设备启动后往组播组发一个“我上线了”服务端收到后记录比挨个 IP 扫描高效得多。通信方式目标数量典型场景Java 关键 API单播一对一客户端-服务端请求DatagramSocket广播一对全网段局域网公告setBroadcast(true)组播一对多按组设备发现、流媒体MulticastSocket5. 那些年我踩过的 UDP 坑问题排查实录5.1 包发出去了但对方收不到先查这三处这是最常见的问题我按排查优先级列一下第一查防火墙。UDP 没有连接状态很多防火墙对 UDP 的处理策略和 TCP 不一样可能直接静默丢弃。先在本地用127.0.0.1测通再换局域网 IP 测最后跨网段测一步步定位。第二查端口绑定。接收端new DatagramSocket(port)里的 port 必须和发送端的目标 port 一致。我见过有人发送端写 9999接收端写 9998查了一下午。第三查缓冲区大小。如果发送的数据超过接收端 buffer 大小包会被截断但不会报错。你收到的就是半截数据解析时各种诡异问题。发送端和接收端约定好最大包大小超过就分片。5.2 为什么本地测试好好的一上服务器就丢包本地回环接口几乎不丢包所以本地测试通过不代表线上没问题。上线后丢包通常有几个原因网络设备限速某些交换机或路由器对 UDP 有速率限制超过就丢MTU 问题UDP 包超过 MTU通常 1500 字节会被分片分片后丢一片整个包就废了。建议应用层控制单包在 1400 字节以内接收缓冲区溢出接收端处理太慢内核缓冲区满了新来的包直接丢。可以调大socket.setReceiveBufferSize()我一般会在接收端加一个统计每隔一段时间打印收包数、丢包数通过序号算这样能快速判断是网络问题还是程序问题。5.3 常见问题速查表现象可能原因排查方向完全收不到端口不一致/防火墙拦截本地回环测试、检查端口偶尔丢包网络抖动/缓冲区溢出加序号统计、调大缓冲区收到乱码编码不一致/缓冲区残留统一 UTF-8、用 getLength收到重复包网络重传/发送端重发用 seq 去重包被截断缓冲区太小调大 buffer 或分片广播收不到未开广播权限setBroadcast(true)实操心得排查 UDP 问题时抓包工具比日志管用得多。在接收端和发送端同时抓包对比“发出去了没”和“收到了没”能快速定位是发送侧、网络侧还是接收侧的问题。6. 一个完整的 UDP 实战案例局域网状态上报系统6.1 需求拆解和方案设计假设我们要做一个局域网内设备状态上报系统若干设备每隔 5 秒往服务端发一次状态设备 ID、CPU 使用率、内存使用率服务端收集并在控制台展示。要求能容忍少量丢包但要能发现设备离线。方案设计设备端用DatagramSocket定时发送状态包服务端用DatagramSocket绑定固定端口持续接收状态包格式设备ID|CPU|内存|时间戳|序号服务端维护一个Map设备ID, 最后上报时间超过 15 秒没上报就标记离线为什么选 UDP 而不是 TCP因为设备数量多、上报频率高TCP 的连接维护成本太高而且丢一两次状态上报不影响整体判断。这就是典型的“能容忍丢包”的场景。6.2 设备端实现要点设备端的核心是定时任务加发送逻辑public class DeviceReporter { private final String deviceId; private final String serverIp; private final int serverPort; private long seq 0; public void start() { ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(this::report, 0, 5, TimeUnit.SECONDS); } private void report() { try (DatagramSocket socket new DatagramSocket()) { String data deviceId | getCpuUsage() | getMemoryUsage() | System.currentTimeMillis() | (seq); byte[] bytes data.getBytes(StandardCharsets.UTF_8); DatagramPacket packet new DatagramPacket( bytes, bytes.length, InetAddress.getByName(serverIp), serverPort); socket.send(packet); } catch (Exception e) { // 记录日志不中断定时任务 } } }这里有个细节每次发送都新建 Socket 再关闭。对于低频上报5 秒一次来说这样最省心不用担心 Socket 状态。如果是高频发送建议复用一个 Socket减少资源开销。6.3 服务端实现要点服务端要处理并发接收和状态维护我用一个接收线程加一个定时检查线程public class StatusServer { private final MapString, Long lastReportTime new ConcurrentHashMap(); private volatile boolean running true; public void start() throws Exception { DatagramSocket socket new DatagramSocket(9999); socket.setSoTimeout(1000); // 接收线程 Thread receiver new Thread(() - { byte[] buffer new byte[2048]; while (running) { try { DatagramPacket packet new DatagramPacket(buffer, buffer.length); socket.receive(packet); String content new String( packet.getData(), packet.getOffset(), packet.getLength(), StandardCharsets.UTF_8); handleReport(content); } catch (SocketTimeoutException e) { // 正常超时继续 } catch (Exception e) { // 记录异常 } } }); receiver.start(); // 离线检查线程 Thread checker new Thread(() - { while (running) { long now System.currentTimeMillis(); lastReportTime.forEach((deviceId, lastTime) - { if (now - lastTime 15000) { System.out.println(设备离线: deviceId); } }); try { Thread.sleep(5000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }); checker.start(); } private void handleReport(String content) { String[] parts content.split(\\|); if (parts.length 5) return; String deviceId parts[0]; lastReportTime.put(deviceId, System.currentTimeMillis()); System.out.println(设备 deviceId CPU parts[1] 内存 parts[2]); } }这个实现里lastReportTime用了ConcurrentHashMap因为接收线程写、检查线程读必须保证线程安全。这是并发场景下的基本要求用普通 HashMap 会出问题。6.4 这个案例还能怎么扩展这套骨架可以往几个方向扩展加 ACK服务端收到后回一个 ACK设备端统计送达率加认证状态包里带一个简单的 token防止伪造上报加持久化把上报数据写到数据库或时序库做历史查询加告警设备离线或指标超阈值时触发通知我个人在实际项目里的体会是UDP 系统的复杂度不在“收发”本身而在“怎么知道通信质量好不好”。序号、ACK、统计日志这三样东西是让 UDP 系统从“能跑”变成“可控”的关键。没有它们出了问题你只能靠猜。最后再分享一个小技巧如果你不确定某个场景该不该用 UDP先用 TCP 实现一版跑一段时间看性能瓶颈在哪。如果瓶颈确实在连接维护上再考虑换 UDP 并补上可靠性机制。上来就用 UDP 硬扛往往会在后期付出更大的排查成本。