1. 项目概述：为什么在2024年还要深挖 Netty + UDP 这个组合？

Netty UDP——这四个字乍看像一句技术黑话，但背后藏着大量真实业务场景里被反复踩坑、又反复重写的通信底层逻辑。我从2015年开始做物联网网关中间件，经手过几十个用 UDP 做设备直连的项目，其中超过七成在初期都绕不开 Netty。不是因为“高大上”，而是因为——原生 JDK 的 DatagramChannel 太原始，写一个能扛住每秒万级报文、不丢包、不乱序、可热插拔编解码器、还能和 Spring Boot 容器生命周期对齐的 UDP 服务，光靠new DatagramSocket()写三天也写不完，更别说压测时发现的缓冲区溢出、线程阻塞、GC 频繁这些隐形炸弹。

你搜到的那些热搜词，比如“netty粘包处理”“udp网络调试”“wireshark如何筛选出udp前后两包的时间间隔”，其实全是同一个问题的不同切面：UDP 本身无连接、无确认、无重传、无序号，它只负责把包发出去，至于对方收没收到、是不是重复了、是不是拼错了——全得你自己兜底。而 Netty 的价值，恰恰在于它把这套“兜底工程”标准化、模块化、可观测化了。它不是替代 UDP，而是让 UDP 可以被真正工程化地使用。

举个最典型的例子：某智能充电桩项目，终端用 ESP32 模组通过 UDP 上报心跳（64 字节纯二进制），要求 30 秒超时断连、支持 5 万台设备并发、单机 CPU 占用低于 15%。如果用传统DatagramSocket+ExecutorService手撸，你会卡在三个地方：一是多线程读取时receive()调用阻塞导致线程池耗尽；二是没有统一的 ByteBuf 内存池，小包高频收发引发频繁 GC；三是无法像 TCP 那样天然按连接隔离上下文，设备 ID 只能靠解析报文头提取，一旦解析失败就整条链路崩掉。而 Netty 的NioDatagramChannel+EventLoopGroup+ChannelPipeline三件套，直接把这三个痛点拆解成可配置、可替换、可监控的组件。

所以这篇内容不是讲“Netty 怎么启动 UDP 服务”的 Hello World，而是聚焦于：一个有生产经验的工程师，在真实项目中面对 UDP 场景时，如何用 Netty 构建一套稳定、可观测、易维护、能上线的通信骨架。它适合三类人：正在做 IoT/音视频/游戏实时通信的后端开发；准备 Netty 面试题、但只背过“TCP 粘包”却说不清 UDP 如何防丢包的候选人；以及被“两台电脑 UDP 通信用网络调试助手连不通”卡住一整天的嵌入式联调同学。接下来所有内容，全部来自我们线上灰度环境的真实配置、Wireshark 抓包分析截图、JVM GC 日志片段，以及被客户凌晨三点电话叫醒后改出来的第 7 版UdpServerHandler。

2. 整体架构设计与核心选型逻辑：为什么不用 Spring Integration UDP？为什么坚持用 NIO 而非 EPOLL？

2.1 不选 Spring Integration UDP 的三个硬伤

很多 Spring Boot 开发者第一反应是“Spring 官方不是有UdpInboundGateway吗？直接配个@Bean不就完了？”——我试过，而且在线上跑过两周，最后删得比写得还快。原因很实在：

• 第一，线程模型不可控。UdpInboundGateway底层封装的是DatagramSocket，它默认使用SimpleAsyncTaskExecutor，每次receive()都新建线程。当设备心跳包频率升到 10Hz，单机 5000 台设备时，线程数瞬间飙到 5 万+，JVM 直接 OOM。你没法像 Netty 那样指定EventLoopGroup的线程数并复用。

• 第二，无内存池管理。它把DatagramPacket的byte[]直接扔给业务逻辑，而byte[]是堆内对象。我们实测过：每秒 2 万次 128 字节包，GC Young Gen 每 3 秒触发一次，ParNew时间平均 80ms，延迟毛刺直接破 500ms。Netty 的PooledByteBufAllocator可以复用 Direct Buffer，把这部分开销压到微秒级。

• 第三，Pipeline 缺失导致协议耦合严重。UdpInboundGateway只提供MessageConverter接口，你得自己写fromBytes()和toBytes()，但设备报文往往带 CRC 校验、变长字段、TLV 结构，这些逻辑如果全塞进 converter，代码会变成“if-else 泥潭”。而 Netty 的ChannelPipeline允许你分层：UdpChecksumHandler→UdpTlvDecoder→UdpDeviceAuthHandler→UdpBusinessHandler，每一层只干一件事，单元测试好写，线上出问题也能快速定位在哪一层挂了。

提示：如果你只是做内部工具、日志上报这类低频 UDP 场景，UdpInboundGateway完全够用。但凡涉及设备直连、实时指令下发、QoS 要求 > 99.9%，请立刻切换到 Netty。

2.2 NIO vs EPOLL：为什么在 Linux 生产环境仍首选 NIO

Netty 支持NioDatagramChannel和EpollDatagramChannel两种传输实现。网上很多教程鼓吹“EPOLL 性能吊打 NIO”，但我们线上集群（CentOS 7.9 + Kernel 5.10）压测结果恰恰相反：在 10G 网卡、单机 2 万并发 UDP 连接下，NioDatagramChannel的 P99 延迟稳定在 12ms，而EpollDatagramChannel在流量突增时会出现 300ms+ 的尖峰。原因在于：

• EPOLL 的epoll_wait()对 UDP 的适配存在固有缺陷。TCP 是流式协议，epoll_wait()可以精准返回“有数据可读”的 socket；但 UDP 是报文式协议，内核 socket buffer 里可能堆积上百个包，epoll_wait()只告诉你“这个 fd 有数据”，却不告诉你有多少个包、每个包多大。Netty 的EpollDatagramChannel为避免饥饿，必须在一次事件循环中尽可能多地recv()，这就导致单次eventLoop执行时间不可控，影响其他 channel 的调度。

• NIO 的Selector虽然有“惊群”问题，但 Netty 已做了深度优化。从 Netty 4.1.42 开始，NioEventLoop引入了selectNow()+wakeup()的混合策略：空轮询时主动selectNow()触发一次无阻塞检查，避免select()长时间阻塞；同时wakeup()调用被优化为Unsafe指令，开销极低。我们在压测中观察到，NioEventLoop的 CPU 占用曲线非常平滑，而EpollEventLoop在流量高峰时会出现周期性 20% 的 CPU 尖峰。

• NIO 的兼容性是硬需求。我们的部分边缘节点运行在国产化 ARM 服务器（麒麟 V10 + 鲲鹏 920）上，内核未开启epoll支持，EpollDatagramChannel直接抛UnsatisfiedLinkError。而NioDatagramChannel是纯 Java 实现，零依赖，部署即用。

所以我们的选型结论很明确：除非你明确知道自己的业务是“超低延迟 + 超高吞吐 + 全量可控内核参数”，否则NioDatagramChannel是更稳、更省心、更易排障的选择。这也是为什么我们线上所有 UDP 服务，bootstrap.channel(NioDatagramChannel.class)这行代码写了上百遍，从未动过。

2.3 EventLoopGroup 的线程数怎么定？不是越多越好

EventLoopGroup是 Netty 的心脏，但它的线程数配置是最大误区来源。很多人看到“高性能”就盲目设成Runtime.getRuntime().availableProcessors() * 2，结果发现 CPU 占用 90%、延迟飙升。真相是：UDP 的EventLoopGroup线程数，应该由“单线程能处理的最大报文吞吐量”决定，而不是 CPU 核数。

我们做过一组对照实验：同一台 16 核服务器，分别用 4/8/16/32 个线程的NioEventLoopGroup启动 UDP 服务，持续发送 100 字节心跳包，测量 P99 延迟和 GC 次数：

最优解出现在 8 线程。原因在于：每个NioEventLoop线程要处理Selector.select()、recv()、decode()、handler()四个阶段。当线程数过多，Selector的锁竞争加剧（SelectorImpl内部有publicKeys和selectedKeys两个HashSet，多线程操作需加锁），反而拖慢整体吞吐。而 8 线程刚好匹配我们单核能稳定处理 2500 QPS 的实测能力（16 核 × 2500 = 4 万 QPS，覆盖业务峰值 3.5 万）。

实操心得：线程数公式建议为min(8, Runtime.getRuntime().availableProcessors())。如果你的服务器是 32 核以上，也不要盲目加到 16，先用 8 线程压测，看NioEventLoop的pendingTasks是否持续 > 1000（可通过 JMX 查看io.netty.channel.nio.NioEventLoop#pendingTasks），再逐步增加。

3. 核心细节解析与实操要点：从启动到上线，每个环节的生死线

3.1 UDP Server 启动的 5 个关键配置项，少一个都可能上线即故障

Netty UDP 服务的启动代码看似简单，但Bootstrap的每个.option()都是血泪教训换来的。下面这 5 个配置，是我们线上所有 UDP 服务的标配，缺一不可：

Bootstrap bootstrap = new Bootstrap(); bootstrap.group(new NioEventLoopGroup(8)) // ① 显式指定线程数，不依赖默认值 .channel(NioDatagramChannel.class) .option(ChannelOption.SO_BROADCAST, true) // ② 必须开启广播，否则局域网设备发现失败 .option(ChannelOption.SO_RCVBUF, 1024 * 1024) // ③ 接收缓冲区设为 1MB，防突发流量丢包 .option(ChannelOption.SO_SNDBUF, 1024 * 1024) // ④ 发送缓冲区同理，避免 `send()` 阻塞 .option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT) // ⑤ 强制使用内存池 .handler(new ChannelInitializer<NioDatagramChannel>() { @Override protected void initChannel(NioDatagramChannel ch) throws Exception { ChannelPipeline p = ch.pipeline(); p.addLast(new UdpChecksumHandler()); // 校验层 p.addLast(new UdpTlvDecoder()); // 解析层 p.addLast(new UdpDeviceAuthHandler()); // 认证层 p.addLast(new UdpBusinessHandler()); // 业务层 } });

逐条解释其不可替代性：

• ①group(new NioEventLoopGroup(8))：必须显式传入EventLoopGroup实例。如果写成group(new NioEventLoopGroup())，Netty 会用Runtime.getRuntime().availableProcessors() * 2创建线程，线上 32 核机器直接起 64 个线程，Selector锁竞争让延迟翻倍。我们曾因此被客户投诉“设备心跳超时率 15%”，查了三天才发现是这里。

• ②SO_BROADCAST, true：这是 UDP 设备自动发现的基石。很多 IoT 设备（如 Zigbee 网关）启动时会向255.255.255.255:9999发送广播包宣告自身存在。如果服务端没开广播，永远收不到这第一声“你好”。注意：生产环境防火墙需放行 UDP 广播（iptables -A INPUT -p udp -d 255.255.255.255 -j ACCEPT）。

• ③SO_RCVBUF, 1024 * 1024：接收缓冲区大小。Linux 默认是 212992 字节（约 208KB），在 10G 网卡下，千兆网卡满速时 1 秒能塞 125MB 数据，缓冲区瞬间溢出，内核直接丢包。设为 1MB 是经过我们压测验证的安全值：在 2 万设备 30 秒心跳（约 666 QPS）下，缓冲区占用率峰值 < 40%。

• ④SO_SNDBUF, 1024 * 1024：发送缓冲区同理。当服务端需要批量回复 ACK 或下发指令时，如果缓冲区太小，channel.writeAndFlush()会阻塞，拖慢整个EventLoop。我们曾遇到过因SO_SNDBUF过小，导致指令下发延迟从 5ms 涨到 200ms 的事故。

• ⑤ALLOCATOR, PooledByteBufAllocator.DEFAULT：强制内存池。PooledByteBufAllocator会预分配 Direct Buffer 内存块，并用Recycler对象池管理ByteBuf实例。实测对比：用UnpooledByteBufAllocator时，每秒 1 万包 GC 频率 12 次；用Pooled后降为 0.3 次，ParNew时间从 60ms 降到 2ms。

注意：SO_RCVBUF和SO_SNDBUF的值不能瞎设。Linux 内核有net.core.rmem_max和net.core.wmem_max限制，设太大内核会静默截断。执行sysctl net.core.rmem_max查看上限，我们的生产服务器已调为16777216（16MB）。

3.2 UDP 的“粘包”不存在？那为什么还要处理“半包”？

这是 Netty UDP 最大的认知陷阱。“TCP 粘包”是经典问题，但很多人误以为“UDP 不会粘包，所以不用处理”。错！UDP 不会“粘”，但会“断”——当报文长度超过 MTU（通常 1500 字节），IP 层会自动分片，而 UDP 层完全感知不到。你的DatagramChannel收到的，可能是某个大报文的第 2 片，也可能是第 1 片和第 3 片的组合（因为 IP 分片可能乱序到达）。这就是“半包”。

我们的真实案例：某安防摄像头用 UDP 上传 H.264 关键帧（I 帧），单帧 2800 字节。网络路径中某台交换机 MTU 为 1400，IP 层将其分为 2 片（1400 + 1400）。但第二片在网络中延迟了 50ms，先到的第一片被UdpTlvDecoder当作完整报文解析，CRC 校验失败，直接丢弃。结果就是视频花屏、关键帧丢失。

解决方案是：在ChannelPipeline中加入UdpFragmentHandler，基于 IP 分片标识（IPv4 的Identification字段 +Flags+Fragment Offset）重组分片。Netty 本身不提供此功能，需自行实现。核心逻辑如下：

• 维护一个ConcurrentHashMap<Short, FragmentBuffer>，key 是 IP 包的Identification字段（16 位），value 是FragmentBuffer对象，包含List<Fragment>和int totalLength。
• 每收到一个 UDP 包，先解析 IP 头，若Flags & 0x01 != 0（MF 标志置位）或Fragment Offset != 0，则为分片包，存入对应FragmentBuffer。
• 当FragmentBuffer中所有分片收齐（sum(fragment.length) == totalLength），合并为完整ByteBuf，传递给下一层。
• 设置超时清理：每个FragmentBuffer附带expireTime = System.nanoTime() + 100_000_000L（100ms），超时未收齐则丢弃，防内存泄漏。

实操心得：分片重组必须在ChannelHandler的channelRead()中完成，不能放到业务线程池。因为分片属于同一 IP 包，必须由同一个EventLoop处理，否则ConcurrentHashMap的并发安全无法保证。我们曾因把重组逻辑放到@Async方法里，导致分片被不同线程处理，FragmentBuffer状态错乱，内存暴涨。

3.3 如何让 UDP 具备“连接感”？DeviceContext 的生命周期管理

UDP 无连接，但业务需要“连接感”：设备上线要初始化上下文，心跳超时要清理资源，指令下发要找到目标设备。如果每次channelRead()都去数据库查设备信息，QPS 上不去；如果全放内存，又怕 OOM。我们的方案是：用Channel.attr()绑定DeviceContext，并配合IdleStateHandler实现自动生命周期管理。

// 在 ChannelInitializer 中添加 p.addLast(new IdleStateHandler(0, 0, 30)); // 读空闲 30 秒触发事件 p.addLast(new UdpDeviceContextHandler()); // 自定义 handler，处理 IdleStateEvent

UdpDeviceContextHandler的核心逻辑：

• channelActive()时，从DatagramPacket解析出设备 MAC 或 SN，查询缓存获取DeviceContext，存入channel.attr(DEVICE_CTX_KEY).set(ctx)。
• userEventTriggered()监听IdleStateEvent：若state == READER_IDLE，说明 30 秒没收到心跳，调用ctx.onTimeout()清理资源（如关闭 MQTT 会话、释放内存缓存），然后channel.close()。
• channelInactive()时，确保DeviceContext的onClose()被调用，释放所有关联资源。

这样，每个NioDatagramChannel实例就成为一个轻量级“虚拟连接”，DeviceContext的创建、保活、销毁全部由 Netty 生命周期驱动，无需额外定时任务。我们线上单机管理 5 万台设备，DeviceContext对象平均生命周期 2.3 小时，内存占用稳定在 1.2GB，GC 压力极小。

提示：DeviceContext中不要存大对象（如图片缓存、音频流）。我们曾把设备最新抓拍图存进DeviceContext，结果 5 万台设备每台存 100KB 图片，内存直接爆到 500GB。正确做法是存deviceId -> cacheKey映射，图片走 Redis 或本地文件系统。

4. 实操过程与核心环节实现：从 Wireshark 抓包到线上压测的完整闭环

4.1 用 Wireshark 精准定位 UDP 丢包：不只是看“no response”

Wireshark 是 UDP 排查的黄金标准，但很多人只会过滤udp.port == 9999，然后看有没有回包。这远远不够。真正的丢包定位，需要三层分析：

第一层：IP 层分片分析
过滤表达式：ip.flags.mf == 1 or ip.frag_offset != 0
作用：找出所有被分片的包。如果服务端收不到完整报文，先看这里是否大量分片，且分片顺序错乱（ip.frag_offset不连续）。我们曾发现某运营商网络对大于 1200 字节的 UDP 包强制分片，且第二片丢包率高达 8%，最终通过SO_RCVBUF调大 + 应用层分包解决。

第二层：UDP 层校验和分析
过滤表达式：udp.checksum_bad == 1
作用：识别因网络干扰导致的校验失败。UDP 校验和是可选的，但 Netty 默认开启。如果大量checksum_bad，说明物理链路有问题（网线老化、光衰过大），需联系网络运维。

第三层：应用层时序分析
这是最关键的一步。UDP 无序号，但我们可以用业务字段构造逻辑时序。例如，设备心跳包中有一个seq字段（4 字节递增）。在 Wireshark 中右键该字段 → “Apply as Column”，新增一列显示seq。然后按此列排序，观察是否出现跳变（如 100 → 105），跳变超过阈值（如 > 3）即判定为丢包。我们用此法准确定位出某款 4G 模组在弱信号下seq会重复发送，导致服务端误判为重放攻击。

实操技巧：Wireshark 的“IO Graphs”功能可画出 UDP 流量热力图。设置 Y 轴为udp.length，X 轴为时间，能直观看到“突发大包潮”——这往往是设备固件 bug 的征兆（如内存泄漏导致缓存积压后一次性爆发）。

4.2 用 iperf3 精准打流：不只是测带宽，更要测 UDP 的稳定性

iperf3 -u -c <server> -b 100M -t 60是常见命令，但它只告诉你“带宽 95Mbps”，对 UDP 服务毫无意义。真正有用的参数组合是：

# 模拟真实设备心跳：每秒 1000 个 128 字节包，持续 5 分钟 iperf3 -u -c 192.168.1.100 -b 1000K -l 128 -t 300 -i 10 --udp-write-timeout=1000000 # 关键参数解读： # -b 1000K：目标速率 1000Kbps ≈ 1000 * 1024 / 8 / 128 ≈ 1000 包/秒 # -l 128：包长 128 字节，匹配设备心跳包 # -i 10：每 10 秒输出一次统计，观察波动 # --udp-write-timeout=1000000：写超时 1 秒，防客户端卡死

关注输出中的三个核心指标：

• Jitter (ms)：抖动值。TCP 服务可以忽略，但 UDP 必须 < 5ms。如果 jitter > 20ms，说明网络拥塞或服务端处理不及时。我们曾因此发现UdpBusinessHandler中一个同步 Redis 查询耗时 15ms，拖垮了整个 pipeline。

• Lost/Total：丢包率。线上服务要求 < 0.1%。如果iperf3显示丢包，先检查服务端SO_RCVBUF是否足够，再用ss -uln查看Recv-Q是否持续 > 0（表示内核缓冲区满）。

• Datagrams：实际发送包数。如果远小于理论值（1000 包/秒 × 300 秒 = 30 万），说明客户端网卡或驱动有问题。我们遇到过某品牌笔记本无线网卡在 UDP 高频发送时，驱动会主动限速。

注意：iperf3的-b参数是“尽力而为”，不是硬限速。要精确控制发包速率，需用tc（Traffic Control）在客户端限速：tc qdisc add dev wlan0 root tbf rate 1000kbit burst 32kbit latency 700ms。

4.3 Spring Boot 3.x + Netty + MQTT 的物联网实战：充电桩指令下发的 7 步落地

“springboot 3.x + netty + mqtt 实战物联网智能充电桩”是热搜词，也是我们刚交付的项目。核心诉求：充电桩上报状态（UDP），后台下发充电指令（MQTT），要求指令 5 秒内触达。难点在于：UDP 和 MQTT 是异构协议，如何保证指令不丢失、不错发、可追溯？我们走了 7 步：

Step 1：定义统一设备标识
放弃用 IP+Port 作为设备 ID（UDP 无连接，IP 可能变），采用vendorId + deviceId组合（如tesla_charger_001），存入 Redis 的device:onlineSet。设备上线时SADD device:online tesla_charger_001，心跳超时SREM。

Step 2：UDP 接收层透传设备 ID
UdpTlvDecoder解析出deviceId后，不走业务逻辑，直接存入channel.attr(DEVICE_ID_KEY)，并转发给MqttCommandRouter。

Step 3：构建 MQTT 指令路由中心

@Component public class MqttCommandRouter { private final Map<String, CompletableFuture<MqttCommandResult>> pendingCommands = new ConcurrentHashMap<>(); public CompletableFuture<MqttCommandResult> sendCommand(String deviceId, MqttCommand cmd) { String reqId = UUID.randomUUID().toString(); CompletableFuture<MqttCommandResult> future = new CompletableFuture<>(); pendingCommands.put(reqId, future); // 发布 MQTT 指令，主题为 command/{deviceId}/{reqId} mqttClient.publish("command/" + deviceId + "/" + reqId, cmd.toJson().getBytes()); return future; } }

Step 4：MQTT 订阅指令响应主题
服务端订阅response/+/#，收到响应后提取reqId，complete()对应的CompletableFuture。

Step 5：UDP 层注入指令超时机制
UdpBusinessHandler中，收到设备状态后，调用MqttCommandRouter.sendCommand()，并设置future.orTimeout(5, TimeUnit.SECONDS)。超时则记录告警，触发人工介入。

Step 6：指令幂等与重试
MQTT 指令消息体包含reqId和timestamp。充电桩固件收到指令后，先查本地lastReqId缓存，若重复则直接 ACK，不执行。服务端对超时指令，最多重试 2 次（间隔 1s），重试时reqId不变。

Step 7：全链路追踪埋点
在UdpBusinessHandler.channelRead()、MqttCommandRouter.sendCommand()、MQTT callback三个节点打日志，用traceId串联。日志格式：[traceId] [deviceId] [step] [status] [costMs]。线上问题 3 分钟内可定位到是 UDP 解析失败，还是 MQTT 网络超时，还是充电桩固件未响应。

这套方案上线后，指令端到端成功率 99.992%，P95 延迟 2.3 秒，完全满足 SLA。

5. 常见问题与排查技巧实录：那些让你凌晨三点爬起来的 UDP 坑

5.1 “两台电脑 UDP 通信使用网络调试助手，死活连不通” —— 90% 是这 5 个原因

这是最常被问的问题。我们整理了 100+ 次远程协助记录，按发生概率排序：

实操心得：第一步永远是telnet或nc测试端口通不通。nc -uvz 192.168.1.100 9999，如果显示Connection to 192.168.1.100 9999 port [udp/9999] succeeded!，说明网络层通畅，问题一定在应用层（代码或助手配置）。

5.2 “nacos 中有用到 netty 吗？”—— 深挖 Nacos 2.x 的 UDP 心跳机制

Nacos 2.x 确实用了 Netty UDP，但仅用于服务实例的心跳探测（Health Check），而非主注册协议。其原理是：

• Nacos Server 启动时，创建NioEventLoopGroup和NioDatagramChannel，监听7848端口（可配）。
• Client SDK 每 5 秒向 Server 的7848端口发送一个 UDP 包，内容为instanceId + timestamp + checksum。
• Server 收到后，不回复，只更新该实例的lastHeartbeatTime。如果 15 秒未收到，则标记为不健康。

为什么用 UDP？因为心跳是“尽力而为”的探测，不需要 TCP 的可靠传输，UDP 的轻量性能支撑百万级实例心跳。但注意：Nacos 的服务发现、配置推送等核心功能，依然走 HTTP/gRPC（TCP）。UDP 只是健康检查的补充，不影响主流程。

我们曾因误以为 Nacos 用 UDP 传服务列表，导致在防火墙只开了7848端口，结果服务调用全部失败。正确做法是：8848（HTTP）、9848（gRPC）、7848（UDP 心跳）三个端口全开。

5.3 “查看电脑关闭 udp 服务”—— 本质是查哪些进程占用了 UDP 端口

Windows 下执行：

netstat -ano -p UDP | findstr :9999 # 输出类似：UDP 0.0.0.0:9999 *:* 12345 # 然后查 PID 12345 对应的进程：tasklist | findstr 12345

Linux 下执行：

sudo lsof -iUDP:9999 # 或 sudo ss -ulpn | grep :9999

如果发现是systemd或avahi-daemon占用了端口，不要强行 kill，而是修改你的服务端口。avahi-daemon是 Zeroconf 服务，关闭它会影响局域网设备发现。

避坑技巧：开发时用0.0.0.0:0让系统自动分配空闲端口，打印日志Started UDP server on /0.0.0.0:XXXX，避免端口冲突。线上再固定端口。

5.4 “netty websocket 怎么做鉴权”—— UDP 和 WebSocket 是两套体系，别混了

这是典型的概念混淆。WebSocket 是基于 TCP 的应用层协议，而 UDP 是网络层协议，二者无直接关系。Netty 中WebSocketServerProtocolHandler只能用在NioSocketChannel（TCP）上，无法用于 `NioDatagramChannel