简介面向Java网络编程开发者这份资源聚焦于基于Netty框架的UDP客户端与SCANFISH-II型声呐系统数据对接内容涵盖UDP通信机制、JSON格式解析、控制命令封装与收发、以及向TCP转发应用推送数据等关键环节适合需要实现声呐数据采集、解析和转发的后端工程师作为参考。压缩包共包含944个文件主要类型包括Java源码、XML配置、HTML页面、JavaScript与CSS样式另有部分SQL脚本、文档说明和版本管理辅助文件方便查看项目整体结构与部署细节。资源整体大小约11.28MB目前已有582人学习下载。通过阅读项目源码能够理解Netty中Bootstrap的线程模型与事件循环配置、UDP通道处理器ChannelHandler的编写方式以及借助Jackson或Gson解析声呐JSON数据的代码实现结合项目内RuoYi-fast框架相关文件还可以学习如何将设备对接功能集成到成熟的后台管理系统中对后续二次开发与协议扩展具有实际参考价值。1. 声呐数据走 UDP为什么偏偏要 Netty 接一手SCANFISH-II 这类拖曳声呐往外吐数据时很少走 TCP原因很直接声呐要高频上报深度、航向、速度等参数TCP 的确认重传在这个场景下不是优点而是背压。UDP 无连接、延迟低代价是丢包、乱序、数据校验都得应用层自己补。而“自己补”这件事原生 java.net.DatagramSocket 那套循环读包模型撑不住要么阻塞在 receive 上要么手动维护线程池还得自己处理拆帧、CRC、命令下发对应关系。Netty 的优势不在“能收 UDP”而在把 UDP 当成一条流水线来管理Bootstrap 负责通道和线程模型ChannelHandler 只关注拆帧、解析、转发命令下发和状态应答复用同一条通道。这套思路解决了设备对接类项目里最难的“业务逻辑跟 Socket API 混在一起”的问题。适合正在做声呐、雷达、水文传感器等设备数据接入的 Java 开发者读完可以直接把骨架搬进自己的对接项目。2. 先搞清楚 UDP 客户端在 Netty 里的通道模型和 SCANFISH-II 帧格式2.1 NioDatagramChannel 才是 Netty 对 UDP 的抽象不是 NioUdpClientSocketChannel很多 UDP 对接资料里会出现NioUdpClientSocketChannel、NioUdpServerSocketChannel这类类名这是把 TCP 的客户端/服务端概念硬套到 UDP 上的口误。Netty 实际提供的 UDP 通道是NioDatagramChannel一个通道同时承担收发没有“连接”的概念。SCANFISH-II 声呐端往业务端所在 IP 的固定端口发数据业务端也通过同一个通道把控制命令发回声呐端地址所以只需要一个Bootstrap加一个NioDatagramChannel。这里的核心差异在于TCP 的ServerBootstrap要监听端口并接受连接每个连接对应一个SocketChannelUDP 没有连接建立过程Bootstrap.bind(0)绑定一个可用本地端口后通道就进入了收发状态。bind(0)表示让操作系统随机分配本地端口这是“UDP 客户端”的标准写法。再看几个组件的对应关系职责TCP 服务端TCP 客户端UDP 收发端引导类ServerBootstrapBootstrapBootstrap通道类型NioServerSocketChannelNioSocketChannelNioDatagramChannel接收方向ServerSocketChannel acceptSocketChannel readDatagramChannel read发送方向SocketChannel writeSocketChannel writeDatagramChannel write由此可见UDP 在 Netty 里的开发模型其实比 TCP 简单不需要childHandler所有 Handler 都挂在Bootstrap.handler()上。很多 Netty 面试八股里问“UDP 怎么区分客户端和服务端”答案就是 Netty 不区分只有收发双方。2.2 客户端 Bootstrap 参数配置EventLoopGroup 与 ChannelOption下面是一个可运行的 UDP 客户端骨架我一般会把声呐端的 IP 和端口放到配置文件里这里先写死便于演示EventLoopGroup group new NioEventLoopGroup(1); try { Bootstrap bootstrap new Bootstrap(); bootstrap.group(group) .channel(NioDatagramChannel.class) .option(ChannelOption.SO_BROADCAST, true) .option(ChannelOption.SO_RCVBUF, 1 * 1024 * 1024) .option(ChannelOption.SO_SNDBUF, 512 * 1024) .option(ChannelOption.SO_REUSEADDR, true) .handler(new SonarClientChannelInitializer()); Channel channel bootstrap.bind(0).sync().channel(); System.out.println(UDP 接收端口: ((InetSocketAddress) channel.localAddress()).getPort()); channel.closeFuture().await(); } finally { group.shutdownGracefully(); }NioEventLoopGroup(1)里的1是 EventLoop 线程数。UDP 通道是异步非阻塞的一个 EventLoop 可以管理大量 Channel声呐对接场景通常 1 个就够如果后续同时接入多台声呐或者要做 TCP 转发再适当调大并做好业务线程池隔离。SO_REUSEADDR保证重启客户端时不会因为 TIME_WAIT 类问题导致端口绑定失败UDP 下还可避免多实例绑定同一组播端口冲突。SO_RCVBUF设置的是 socket 接收缓冲区大小注意它只是给内核的一个建议值真实生效值受rmem_max限制后面第 4 章会专门讲。这里的参数对 SCANFISH-II 这种高频声呐很重要声呐数据包如果超过默认缓冲区数据报会被内核丢弃而 UDP 丢包不像 TCP 那样有内核重传应用层只能看到“某一帧莫名没了”。所以我会在一开始就把接收缓冲区调到 1MB后续再按实际包频次调整。2.3 SCANFISH-II 帧结构先定义好边界再写解析SCANFISH-II 的完整规约以设备手册为准但常见实现基本遵循“帧头 载荷长度 命令字 JSON 载荷 CRC16”的结构。我在对接时先把帧结构定义成表避免写代码时反复改偏移量偏移字段长度说明0frame_head2 字节固定 0xAB 0xCD2payload_len2 字节小端JSON 载荷字节数4cmd1 字节0x01 声呐数据0x02 状态0xF0 命令应答5payloadpayload_len 字节JSON 文本末尾crc162 字节对 payload 的 CRC16 校验帧头之后就是长度这样实现时可以先markReaderIndex()读取头部后发现长度不够就resetReaderIndex()丢弃避免把下一个数据包误当半包处理。UDP 下每个DatagramPacket对应一个 IP 数据报理论上不会出现 TCP 那种半个帧挂在那里的情况但声呐发送端可能因为分片重组失败导致包残缺所以防御性校验仍然要写。下一步就进入 Handler 实现。3. 在 ChannelHandler 里拆帧、解析 JSON 和下发命令3.1 Handler 分工单通道处理 UDP DatagramPacketSCANFISH-II 数据进入 Netty 后默认的入站对象是DatagramPacket需要从它的content()里拿ByteBuf。我建议把 Handler 拆成两层一层做帧边界和 CRC 校验一层做 JSON 转对象和应用逻辑。下面这个SonarDatagramHandler是核心包含拆帧、校验和初步分发public class SonarDatagramHandler extends SimpleChannelInboundHandlerDatagramPacket { private static final byte HEAD_0 (byte) 0xAB; private static final byte HEAD_1 (byte) 0xCD; private final ObjectMapper objectMapper new ObjectMapper() .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); Override protected void channelRead0(ChannelHandlerContext ctx, DatagramPacket packet) throws Exception { ByteBuf in packet.content(); if (in.readableBytes() 6) { return; } in.markReaderIndex(); if (in.readByte() ! HEAD_0 || in.readByte() ! HEAD_1) { return; } int payloadLen in.readUnsignedShort(); int cmd in.readUnsignedByte(); if (in.readableBytes() payloadLen 2) { in.resetReaderIndex(); return; } byte[] payload new byte[payloadLen]; in.readBytes(payload); int crcReceived in.readUnsignedShort(); if (crc16(payload) ! crcReceived) { return; } if (cmd 0x01) { dispatchSonarData(ctx, payload, packet.sender()); } else if (cmd 0xF0) { handleCommandAck(payload); } else { // 其他命令字按需要扩展 } } }这段代码有两个容易被忽略的点。第一markReaderIndex和resetReaderIndex配合使用可以在长度不足时把读指针恢复到帧头位置等待下一个DatagramPacket避免污染后续解析。第二CRC 校验失败直接返回不向上抛出异常因为声呐数据在复杂海况下偶发损坏是正常的协议本身就不要求重传记录一条 warn 日志后继续收下一包即可。SimpleChannelInboundHandler会在channelRead0返回后自动释放DatagramPacket所以不要在这个 Handler 里直接把packet传到另一个线程否则对象可能已被释放。需要异步处理时要把ByteBuf中的字节数组复制出来再交给业务线程这正是下一节要做的事情。3.2 Jackson 把声呐 JSON 映射成 SonarDataPacket声呐的 JSON 载荷字段通常包括设备编号、深度、航向、频率、速度、时间戳等。先定一个普通 POJOpublic class SonarDataPacket { private String deviceId; private double depth; private double heading; private double frequency; private double speed; private long timestamp; private boolean valid; // getter / setter 省略 }然后在dispatchSonarData里用 Jackson 做转换private void dispatchSonarData(ChannelHandlerContext ctx, byte[] payload, InetSocketAddress sender) throws JsonProcessingException { SonarDataPacket data objectMapper.readValue(payload, SonarDataPacket.class); if (!data.isValid()) { return; } ctx.executor().execute(() - forwardToTcpApp(data)); }这里的objectMapper配置很关键FAIL_ON_UNKNOWN_PROPERTIES必须设成false。声呐固件升级后很可能新增字段如果保持默认的true一个未知字段就会导致整条 JSON 解析失败数据链路直接断开。另外我把forwardToTcpApp通过ctx.executor().execute提交回 EventLoop 执行避免直接在channelRead0里做网络转发而阻塞通道。如果转发逻辑很重应该丢到独立业务线程池第 4 章会写具体做法。3.3 下行控制命令复用同一个 NioDatagramChannelSCANFISH-II 不是单向广播业务端可能需要下发开始采集、暂停、换频等命令。命令格式和上行帧一致只是cmd不同。发送方法可以这样封装public void sendCommand(Channel channel, InetSocketAddress sonarAddress, byte cmd, byte[] params) { ByteBuf buf channel.alloc().buffer(); buf.writeByte((byte) 0xAB); buf.writeByte((byte) 0xCD); buf.writeShort(params.length 1); buf.writeByte(cmd); buf.writeBytes(params); buf.writeShort(crc16(params)); channel.writeAndFlush(new DatagramPacket(buf, sonarAddress)) .addListener(future - { if (!future.isSuccess()) { log.error(下发命令失败: {}, future.cause().toString()); } }); }注意DatagramPacket的第二个参数是目标InetSocketAddress。UDP 客户端即使之前没有“连接”也能通过同一个通道向任意地址发包。ByteBuf的分配使用channel.alloc().buffer()而不是Unpooled.buffer()这样可以利用 Netty 的池化分配器减少高频命令发送时的对象创建压力。命令下发和服务端收到回执之间没有 TCP 那种对应关系所以回执里必须携带命令序号一般放在 JSON payload 的cmdId字段里否则无法判断是哪条命令的应答。对接时我会在handleCommandAck里做一个ConcurrentHashMapLong, CompletableFuturebyte[]把命令下发和应答关联起来。4. 对接 TCP 转发 App 前先处理 EventLoop 阻塞、丢包和抓包问题4.1 EventLoop 被阻塞是声呐对接最常见的隐形故障Netty 的 EventLoop 既是 IO 线程又是事件循环线程channelRead0里的所有代码都在 EventLoop 上执行。如果在解析或转发时做数据库写入、第三方 HTTP 调用、大对象 JSON 序列化这几个毫秒的阻塞会被放大EventLoop 无法及时处理后续到达的 UDP 包内核缓冲区渐渐被填满然后开始丢包。SCANFISH-II 高频上报时这种问题表现为“Web 后端看起来正常但声呐数据断断续续”。解决办法是把耗时业务从 EventLoop 挪走。常见做法是在ChannelInitializer中为 Handler 指定独立的DefaultEventExecutorGroupDefaultEventExecutorGroup businessGroup new DefaultEventExecutorGroup(8); pipeline.addLast(decoder, new SonarFrameDecoder()); pipeline.addLast(businessGroup, sonarHandler, new SonarDatagramHandler());pipeline.addLast(EventExecutorGroup, name, handler)会让该 Handler 内的回调在指定的业务线程池中执行而不会被 EventLoop 阻塞。注意Handler 一旦被多线程调用就不能再用Sharable标注并在内部持有可变的成员状态。上面的SonarDatagramHandler里的objectMapper是线程安全的但如果有自定义的累计缓冲字段就要在每次channelRead0里用局部变量或者改用ChannelHandler.Sharable加锁否则会出现并发问题。4.2 丢包先从内核缓冲区查起应用层一切正常但 Wireshark 能看到重传或丢包时第一步查内核 socket 缓冲区上限sysctl net.core.rmem_max sysctl net.core.rmem_defaultNetty 里设置的SO_RCVBUF如果超过net.core.rmem_max内核会强制截断到上限。临时调大sysctl -w net.core.rmem_max8388608 sysctl -w net.core.rmem_default8388608持久化则写入/etc/sysctl.confnet.core.rmem_max 8388608 net.core.rmem_default 8388608修改完执行sysctl -p生效。这里有一个容易踩的坑SO_RCVBUF设置的是单个 socket 的接收缓冲区而内核实际还会做两倍翻倍处理所以不要误以为设了 1MB 就一定是 1MB。声呐数据包大小和频次要按真实设备估算假设每包 512 字节、每 10ms 一包一秒钟就是约 51KB1MB 缓冲区能扛住短暂的消费抖动如果频次翻倍缓冲区就要相应加大。4.3 用 Wireshark 定位 UDP 乱序和包间隔异常排查声呐 UDP 问题时Wireshark 比日志有用。打开抓包后筛选声呐端口udp.port 9000然后在“列首选项”里增加一列frame.time_delta_displayed它能显示当前包与上一个包的时间间隔。正常声呐上报节奏应该非常均匀比如固定 10ms 一包。如果看到间隔波动如 0.0001、0.023、0.001、0.098说明应用消费不过来数据在内核缓冲排队。如果间隔均匀但实际丢包再检查是不是 IP 分片ip.flags.mf 1 || ip.frag_offset 0SCANFISH-II 如果一帧 JSON 超过 1400 字节发送端 IP 层会分片。UDP 分片后只要有一片丢失整个数据报就会被丢弃应用层根本收不到。这时优先建议设备端缩包体或者用多包协议而不是超大 UDP 报文。4.4 TCP 转发 App 的桥接实现SCANFISH-II 数据最终要给 TCP 转发 App 用所以业务线程把解析出的SonarDataPacket通过一个 TCP 服务端推给 App。这个过程同样可以用 Netty 的ServerBootstrap与 UDP 客户端放在同一个进程里ServerBootstrap tcpBootstrap new ServerBootstrap(); tcpBootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childOption(ChannelOption.TCP_NODELAY, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(65535, 0, 4, 0, 4)); ch.pipeline().addLast(new TcpForwardHandler()); } }); Channel tcpServer tcpBootstrap.bind(9100).sync().channel();和 UDP 侧最大的差异出现在LengthFieldBasedFrameDecoderTCP 是字节流不拆帧就会出现粘包半包问题。App 端每帧的格式我一般定义为“4 字节长度 JSON”这个长度字段正好能被解码器识别。UDP 侧没有流式粘包但可能有“一包多帧”所以前面写的是按帧头长度字段逐帧解析TCP 侧必须把拆帧当成头等大事否则 App 端看到的 JSON 全是断的。桥接时还需要维护当前连接的ChannelGroupChannelGroup tcpClients new DefaultChannelGroup(GlobalEventExecutor.INSTANCE);新 TCP 连接加入断开时移除forwardToTcpApp只是把 JSON 字符串写到组内所有 Channel。声呐数据对实时性要求高App 掉线时不建议在 UDP 侧做本地重排队列直接丢弃即可真正需要可靠性的命令应答走单独的请求响应通道更好。5. 联调验证网络调试助手模拟声呐再用 iperf3 压测接收链路先把声呐端用一个工具顶替掉。Windows 上用网络调试助手创建 UDP Server监听 9000 端口手动发送一帧十六进制数据AB CD 00 12 01 7B 22 64 65 70 74 68 22 3A 31 32 2E 35 7D C5 A3其中00 12是 JSON 载荷长度 1801是声呐数据命令字后面是{depth:12.5}的 ASCII 码最后两个字节是 CRC16。客户端启动后日志里应该打印出 depth12.5。确认基本流程后再用真实网络环境验证。Wireshark 过滤条件可以同时看两段链路udp.port 9000 || tcp.port 9100左侧是声呐 UDP 入站右侧是转发给 App 的 TCP 出站。对比两条流的包节奏能确认转发是否实时。如果 TCP 侧明显慢于 UDP 侧瓶颈在forwardToTcpApp的线程模型优先检查是否有阻塞调用。最后做接收链路压测。用 iperf3 打流时不要把流量直接打给声呐客户端端口因为 iperf3 的 UDP 包格式不是 SCANFISH-II 帧进不了业务解析链。先在接收机启动 iperf3 服务端监听 9000iperf3 -s -p 9000发送端打流 20Mbps、持续 30 秒iperf3 -u -c 192.168.1.100 -p 9000 -b 20M -t 30重点看Jitter和Lost/Total Datagrams两列。Lost比例超过 0.1% 时先确认是不是交换机开启了广播风暴抑制再把网卡中断合并调低。声呐本身不会因为网络打流而变得可靠压测的意义在于验证当前主机在满负荷网络下还能不能顺序处理高频数据报。实际对接 SCANFISH-II 时命令下发频率不要高于 2Hz部分固件对太密集的指令请求会自动忽略收到cmd0xF0应答前只保留最近一条待确认命令其余直接丢弃。本文还有配套的精品资源点击获取 Netty UDP客户端开发实战：声呐数据接入与TCP转发
简介面向Java网络编程开发者这份资源聚焦于基于Netty框架的UDP客户端与SCANFISH-II型声呐系统数据对接内容涵盖UDP通信机制、JSON格式解析、控制命令封装与收发、以及向TCP转发应用推送数据等关键环节适合需要实现声呐数据采集、解析和转发的后端工程师作为参考。压缩包共包含944个文件主要类型包括Java源码、XML配置、HTML页面、JavaScript与CSS样式另有部分SQL脚本、文档说明和版本管理辅助文件方便查看项目整体结构与部署细节。资源整体大小约11.28MB目前已有582人学习下载。通过阅读项目源码能够理解Netty中Bootstrap的线程模型与事件循环配置、UDP通道处理器ChannelHandler的编写方式以及借助Jackson或Gson解析声呐JSON数据的代码实现结合项目内RuoYi-fast框架相关文件还可以学习如何将设备对接功能集成到成熟的后台管理系统中对后续二次开发与协议扩展具有实际参考价值。1. 声呐数据走 UDP为什么偏偏要 Netty 接一手SCANFISH-II 这类拖曳声呐往外吐数据时很少走 TCP原因很直接声呐要高频上报深度、航向、速度等参数TCP 的确认重传在这个场景下不是优点而是背压。UDP 无连接、延迟低代价是丢包、乱序、数据校验都得应用层自己补。而“自己补”这件事原生 java.net.DatagramSocket 那套循环读包模型撑不住要么阻塞在 receive 上要么手动维护线程池还得自己处理拆帧、CRC、命令下发对应关系。Netty 的优势不在“能收 UDP”而在把 UDP 当成一条流水线来管理Bootstrap 负责通道和线程模型ChannelHandler 只关注拆帧、解析、转发命令下发和状态应答复用同一条通道。这套思路解决了设备对接类项目里最难的“业务逻辑跟 Socket API 混在一起”的问题。适合正在做声呐、雷达、水文传感器等设备数据接入的 Java 开发者读完可以直接把骨架搬进自己的对接项目。2. 先搞清楚 UDP 客户端在 Netty 里的通道模型和 SCANFISH-II 帧格式2.1 NioDatagramChannel 才是 Netty 对 UDP 的抽象不是 NioUdpClientSocketChannel很多 UDP 对接资料里会出现NioUdpClientSocketChannel、NioUdpServerSocketChannel这类类名这是把 TCP 的客户端/服务端概念硬套到 UDP 上的口误。Netty 实际提供的 UDP 通道是NioDatagramChannel一个通道同时承担收发没有“连接”的概念。SCANFISH-II 声呐端往业务端所在 IP 的固定端口发数据业务端也通过同一个通道把控制命令发回声呐端地址所以只需要一个Bootstrap加一个NioDatagramChannel。这里的核心差异在于TCP 的ServerBootstrap要监听端口并接受连接每个连接对应一个SocketChannelUDP 没有连接建立过程Bootstrap.bind(0)绑定一个可用本地端口后通道就进入了收发状态。bind(0)表示让操作系统随机分配本地端口这是“UDP 客户端”的标准写法。再看几个组件的对应关系职责TCP 服务端TCP 客户端UDP 收发端引导类ServerBootstrapBootstrapBootstrap通道类型NioServerSocketChannelNioSocketChannelNioDatagramChannel接收方向ServerSocketChannel acceptSocketChannel readDatagramChannel read发送方向SocketChannel writeSocketChannel writeDatagramChannel write由此可见UDP 在 Netty 里的开发模型其实比 TCP 简单不需要childHandler所有 Handler 都挂在Bootstrap.handler()上。很多 Netty 面试八股里问“UDP 怎么区分客户端和服务端”答案就是 Netty 不区分只有收发双方。2.2 客户端 Bootstrap 参数配置EventLoopGroup 与 ChannelOption下面是一个可运行的 UDP 客户端骨架我一般会把声呐端的 IP 和端口放到配置文件里这里先写死便于演示EventLoopGroup group new NioEventLoopGroup(1); try { Bootstrap bootstrap new Bootstrap(); bootstrap.group(group) .channel(NioDatagramChannel.class) .option(ChannelOption.SO_BROADCAST, true) .option(ChannelOption.SO_RCVBUF, 1 * 1024 * 1024) .option(ChannelOption.SO_SNDBUF, 512 * 1024) .option(ChannelOption.SO_REUSEADDR, true) .handler(new SonarClientChannelInitializer()); Channel channel bootstrap.bind(0).sync().channel(); System.out.println(UDP 接收端口: ((InetSocketAddress) channel.localAddress()).getPort()); channel.closeFuture().await(); } finally { group.shutdownGracefully(); }NioEventLoopGroup(1)里的1是 EventLoop 线程数。UDP 通道是异步非阻塞的一个 EventLoop 可以管理大量 Channel声呐对接场景通常 1 个就够如果后续同时接入多台声呐或者要做 TCP 转发再适当调大并做好业务线程池隔离。SO_REUSEADDR保证重启客户端时不会因为 TIME_WAIT 类问题导致端口绑定失败UDP 下还可避免多实例绑定同一组播端口冲突。SO_RCVBUF设置的是 socket 接收缓冲区大小注意它只是给内核的一个建议值真实生效值受rmem_max限制后面第 4 章会专门讲。这里的参数对 SCANFISH-II 这种高频声呐很重要声呐数据包如果超过默认缓冲区数据报会被内核丢弃而 UDP 丢包不像 TCP 那样有内核重传应用层只能看到“某一帧莫名没了”。所以我会在一开始就把接收缓冲区调到 1MB后续再按实际包频次调整。2.3 SCANFISH-II 帧结构先定义好边界再写解析SCANFISH-II 的完整规约以设备手册为准但常见实现基本遵循“帧头 载荷长度 命令字 JSON 载荷 CRC16”的结构。我在对接时先把帧结构定义成表避免写代码时反复改偏移量偏移字段长度说明0frame_head2 字节固定 0xAB 0xCD2payload_len2 字节小端JSON 载荷字节数4cmd1 字节0x01 声呐数据0x02 状态0xF0 命令应答5payloadpayload_len 字节JSON 文本末尾crc162 字节对 payload 的 CRC16 校验帧头之后就是长度这样实现时可以先markReaderIndex()读取头部后发现长度不够就resetReaderIndex()丢弃避免把下一个数据包误当半包处理。UDP 下每个DatagramPacket对应一个 IP 数据报理论上不会出现 TCP 那种半个帧挂在那里的情况但声呐发送端可能因为分片重组失败导致包残缺所以防御性校验仍然要写。下一步就进入 Handler 实现。3. 在 ChannelHandler 里拆帧、解析 JSON 和下发命令3.1 Handler 分工单通道处理 UDP DatagramPacketSCANFISH-II 数据进入 Netty 后默认的入站对象是DatagramPacket需要从它的content()里拿ByteBuf。我建议把 Handler 拆成两层一层做帧边界和 CRC 校验一层做 JSON 转对象和应用逻辑。下面这个SonarDatagramHandler是核心包含拆帧、校验和初步分发public class SonarDatagramHandler extends SimpleChannelInboundHandlerDatagramPacket { private static final byte HEAD_0 (byte) 0xAB; private static final byte HEAD_1 (byte) 0xCD; private final ObjectMapper objectMapper new ObjectMapper() .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); Override protected void channelRead0(ChannelHandlerContext ctx, DatagramPacket packet) throws Exception { ByteBuf in packet.content(); if (in.readableBytes() 6) { return; } in.markReaderIndex(); if (in.readByte() ! HEAD_0 || in.readByte() ! HEAD_1) { return; } int payloadLen in.readUnsignedShort(); int cmd in.readUnsignedByte(); if (in.readableBytes() payloadLen 2) { in.resetReaderIndex(); return; } byte[] payload new byte[payloadLen]; in.readBytes(payload); int crcReceived in.readUnsignedShort(); if (crc16(payload) ! crcReceived) { return; } if (cmd 0x01) { dispatchSonarData(ctx, payload, packet.sender()); } else if (cmd 0xF0) { handleCommandAck(payload); } else { // 其他命令字按需要扩展 } } }这段代码有两个容易被忽略的点。第一markReaderIndex和resetReaderIndex配合使用可以在长度不足时把读指针恢复到帧头位置等待下一个DatagramPacket避免污染后续解析。第二CRC 校验失败直接返回不向上抛出异常因为声呐数据在复杂海况下偶发损坏是正常的协议本身就不要求重传记录一条 warn 日志后继续收下一包即可。SimpleChannelInboundHandler会在channelRead0返回后自动释放DatagramPacket所以不要在这个 Handler 里直接把packet传到另一个线程否则对象可能已被释放。需要异步处理时要把ByteBuf中的字节数组复制出来再交给业务线程这正是下一节要做的事情。3.2 Jackson 把声呐 JSON 映射成 SonarDataPacket声呐的 JSON 载荷字段通常包括设备编号、深度、航向、频率、速度、时间戳等。先定一个普通 POJOpublic class SonarDataPacket { private String deviceId; private double depth; private double heading; private double frequency; private double speed; private long timestamp; private boolean valid; // getter / setter 省略 }然后在dispatchSonarData里用 Jackson 做转换private void dispatchSonarData(ChannelHandlerContext ctx, byte[] payload, InetSocketAddress sender) throws JsonProcessingException { SonarDataPacket data objectMapper.readValue(payload, SonarDataPacket.class); if (!data.isValid()) { return; } ctx.executor().execute(() - forwardToTcpApp(data)); }这里的objectMapper配置很关键FAIL_ON_UNKNOWN_PROPERTIES必须设成false。声呐固件升级后很可能新增字段如果保持默认的true一个未知字段就会导致整条 JSON 解析失败数据链路直接断开。另外我把forwardToTcpApp通过ctx.executor().execute提交回 EventLoop 执行避免直接在channelRead0里做网络转发而阻塞通道。如果转发逻辑很重应该丢到独立业务线程池第 4 章会写具体做法。3.3 下行控制命令复用同一个 NioDatagramChannelSCANFISH-II 不是单向广播业务端可能需要下发开始采集、暂停、换频等命令。命令格式和上行帧一致只是cmd不同。发送方法可以这样封装public void sendCommand(Channel channel, InetSocketAddress sonarAddress, byte cmd, byte[] params) { ByteBuf buf channel.alloc().buffer(); buf.writeByte((byte) 0xAB); buf.writeByte((byte) 0xCD); buf.writeShort(params.length 1); buf.writeByte(cmd); buf.writeBytes(params); buf.writeShort(crc16(params)); channel.writeAndFlush(new DatagramPacket(buf, sonarAddress)) .addListener(future - { if (!future.isSuccess()) { log.error(下发命令失败: {}, future.cause().toString()); } }); }注意DatagramPacket的第二个参数是目标InetSocketAddress。UDP 客户端即使之前没有“连接”也能通过同一个通道向任意地址发包。ByteBuf的分配使用channel.alloc().buffer()而不是Unpooled.buffer()这样可以利用 Netty 的池化分配器减少高频命令发送时的对象创建压力。命令下发和服务端收到回执之间没有 TCP 那种对应关系所以回执里必须携带命令序号一般放在 JSON payload 的cmdId字段里否则无法判断是哪条命令的应答。对接时我会在handleCommandAck里做一个ConcurrentHashMapLong, CompletableFuturebyte[]把命令下发和应答关联起来。4. 对接 TCP 转发 App 前先处理 EventLoop 阻塞、丢包和抓包问题4.1 EventLoop 被阻塞是声呐对接最常见的隐形故障Netty 的 EventLoop 既是 IO 线程又是事件循环线程channelRead0里的所有代码都在 EventLoop 上执行。如果在解析或转发时做数据库写入、第三方 HTTP 调用、大对象 JSON 序列化这几个毫秒的阻塞会被放大EventLoop 无法及时处理后续到达的 UDP 包内核缓冲区渐渐被填满然后开始丢包。SCANFISH-II 高频上报时这种问题表现为“Web 后端看起来正常但声呐数据断断续续”。解决办法是把耗时业务从 EventLoop 挪走。常见做法是在ChannelInitializer中为 Handler 指定独立的DefaultEventExecutorGroupDefaultEventExecutorGroup businessGroup new DefaultEventExecutorGroup(8); pipeline.addLast(decoder, new SonarFrameDecoder()); pipeline.addLast(businessGroup, sonarHandler, new SonarDatagramHandler());pipeline.addLast(EventExecutorGroup, name, handler)会让该 Handler 内的回调在指定的业务线程池中执行而不会被 EventLoop 阻塞。注意Handler 一旦被多线程调用就不能再用Sharable标注并在内部持有可变的成员状态。上面的SonarDatagramHandler里的objectMapper是线程安全的但如果有自定义的累计缓冲字段就要在每次channelRead0里用局部变量或者改用ChannelHandler.Sharable加锁否则会出现并发问题。4.2 丢包先从内核缓冲区查起应用层一切正常但 Wireshark 能看到重传或丢包时第一步查内核 socket 缓冲区上限sysctl net.core.rmem_max sysctl net.core.rmem_defaultNetty 里设置的SO_RCVBUF如果超过net.core.rmem_max内核会强制截断到上限。临时调大sysctl -w net.core.rmem_max8388608 sysctl -w net.core.rmem_default8388608持久化则写入/etc/sysctl.confnet.core.rmem_max 8388608 net.core.rmem_default 8388608修改完执行sysctl -p生效。这里有一个容易踩的坑SO_RCVBUF设置的是单个 socket 的接收缓冲区而内核实际还会做两倍翻倍处理所以不要误以为设了 1MB 就一定是 1MB。声呐数据包大小和频次要按真实设备估算假设每包 512 字节、每 10ms 一包一秒钟就是约 51KB1MB 缓冲区能扛住短暂的消费抖动如果频次翻倍缓冲区就要相应加大。4.3 用 Wireshark 定位 UDP 乱序和包间隔异常排查声呐 UDP 问题时Wireshark 比日志有用。打开抓包后筛选声呐端口udp.port 9000然后在“列首选项”里增加一列frame.time_delta_displayed它能显示当前包与上一个包的时间间隔。正常声呐上报节奏应该非常均匀比如固定 10ms 一包。如果看到间隔波动如 0.0001、0.023、0.001、0.098说明应用消费不过来数据在内核缓冲排队。如果间隔均匀但实际丢包再检查是不是 IP 分片ip.flags.mf 1 || ip.frag_offset 0SCANFISH-II 如果一帧 JSON 超过 1400 字节发送端 IP 层会分片。UDP 分片后只要有一片丢失整个数据报就会被丢弃应用层根本收不到。这时优先建议设备端缩包体或者用多包协议而不是超大 UDP 报文。4.4 TCP 转发 App 的桥接实现SCANFISH-II 数据最终要给 TCP 转发 App 用所以业务线程把解析出的SonarDataPacket通过一个 TCP 服务端推给 App。这个过程同样可以用 Netty 的ServerBootstrap与 UDP 客户端放在同一个进程里ServerBootstrap tcpBootstrap new ServerBootstrap(); tcpBootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childOption(ChannelOption.TCP_NODELAY, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(65535, 0, 4, 0, 4)); ch.pipeline().addLast(new TcpForwardHandler()); } }); Channel tcpServer tcpBootstrap.bind(9100).sync().channel();和 UDP 侧最大的差异出现在LengthFieldBasedFrameDecoderTCP 是字节流不拆帧就会出现粘包半包问题。App 端每帧的格式我一般定义为“4 字节长度 JSON”这个长度字段正好能被解码器识别。UDP 侧没有流式粘包但可能有“一包多帧”所以前面写的是按帧头长度字段逐帧解析TCP 侧必须把拆帧当成头等大事否则 App 端看到的 JSON 全是断的。桥接时还需要维护当前连接的ChannelGroupChannelGroup tcpClients new DefaultChannelGroup(GlobalEventExecutor.INSTANCE);新 TCP 连接加入断开时移除forwardToTcpApp只是把 JSON 字符串写到组内所有 Channel。声呐数据对实时性要求高App 掉线时不建议在 UDP 侧做本地重排队列直接丢弃即可真正需要可靠性的命令应答走单独的请求响应通道更好。5. 联调验证网络调试助手模拟声呐再用 iperf3 压测接收链路先把声呐端用一个工具顶替掉。Windows 上用网络调试助手创建 UDP Server监听 9000 端口手动发送一帧十六进制数据AB CD 00 12 01 7B 22 64 65 70 74 68 22 3A 31 32 2E 35 7D C5 A3其中00 12是 JSON 载荷长度 1801是声呐数据命令字后面是{depth:12.5}的 ASCII 码最后两个字节是 CRC16。客户端启动后日志里应该打印出 depth12.5。确认基本流程后再用真实网络环境验证。Wireshark 过滤条件可以同时看两段链路udp.port 9000 || tcp.port 9100左侧是声呐 UDP 入站右侧是转发给 App 的 TCP 出站。对比两条流的包节奏能确认转发是否实时。如果 TCP 侧明显慢于 UDP 侧瓶颈在forwardToTcpApp的线程模型优先检查是否有阻塞调用。最后做接收链路压测。用 iperf3 打流时不要把流量直接打给声呐客户端端口因为 iperf3 的 UDP 包格式不是 SCANFISH-II 帧进不了业务解析链。先在接收机启动 iperf3 服务端监听 9000iperf3 -s -p 9000发送端打流 20Mbps、持续 30 秒iperf3 -u -c 192.168.1.100 -p 9000 -b 20M -t 30重点看Jitter和Lost/Total Datagrams两列。Lost比例超过 0.1% 时先确认是不是交换机开启了广播风暴抑制再把网卡中断合并调低。声呐本身不会因为网络打流而变得可靠压测的意义在于验证当前主机在满负荷网络下还能不能顺序处理高频数据报。实际对接 SCANFISH-II 时命令下发频率不要高于 2Hz部分固件对太密集的指令请求会自动忽略收到cmd0xF0应答前只保留最近一条待确认命令其余直接丢弃。本文还有配套的精品资源点击获取