企业官网建设流程全解析

简介：本资源是面向Java开发者与短信网关集成工程师的CMPP3.0协议实战实现包，聚焦中国移动短信平台对接中的核心难点——长连接管理、GBK编码处理、心跳保活、多线程收发及状态查询等关键环节。压缩包共17个文件，含14个Java源码（覆盖ConnectionManager、CmppClient、MessageEncoder/Decoder、定时器任务等核心模块）、2个说明类txt文档（含配置说明与流程注解）以及1个MsgConfig.properties配置文件，整体仅23KB，轻量精炼，便于快速导入学习与二次开发。已有949人下载学习，适合中高级Java工程师深入理解电信级协议集成逻辑。读者可直接复用完整TCP通信骨架、标准化消息编解码逻辑、健壮的心跳与重连策略，以及清晰的日志跟踪与异常处理范式，显著降低CMPP3.0对接落地门槛。

1. CMPP 3.0 Java 实现：不是封装个 HTTP 就能发短信的黑匣子，而是要亲手捏住连接状态、心跳节奏和报文序列号的通信底盘

你有没有试过用某“一键短信 SDK”往三大运营商网关发消息，结果测试环境通、生产环境隔两小时就断连、重发消息重复计费、状态报告永远收不到？这不是你代码写得差，而是掉进了「把 CMPP 当 HTTP 用」的认知陷阱。CMPP 3.0 是中国移动定义的七号信令级短信网关协议，它不是 REST API，而是一套带长连接、双向心跳、严格报文序号（Sequence_Id）、状态机驱动、需主动维护链路生命周期的 TCP 底层协议。这份cmpp3.0_JAVA_实现资源，不是 Demo 级玩具，而是一个可嵌入生产系统的、完整覆盖 CMPP 3.0 协议栈的 Java 工程：从 CMPP_ConnectReq/Resp 的鉴权握手，到 CMPP_Submit 提交短信、CMPP_Deliver 接收上行、CMPP_ActiveTest 心跳保活，再到 CMPP_Terminate 主动拆链——所有字段按《CMPP3.0 协议规范 V3.6.0》逐字节对齐，含完整 TLV 扩展字段解析逻辑。适合正在对接省移动/集团网关、需要自主可控链路管理、或被第三方 SDK 坑过三次以上的后端工程师。它不帮你做业务路由，但给你一把能拧开每个报文字节的螺丝刀。

2. 协议栈分层与核心类设计：为什么不用 Netty 而坚持原生 NIO + 自研编解码器？

CMPP 3.0 不是简单的请求-响应模型，它要求客户端必须：
✅ 每 30 秒内主动发送CMPP_ActiveTest并在 30 秒内收到CMPP_ActiveTestResp，否则网关强制断链；
✅ 所有请求报文的Sequence_Id必须单调递增且全局唯一（非线程安全，需原子计数）；
✅CMPP_Submit提交后，必须等待CMPP_SubmitResp返回才能发下一条（串行化），但CMPP_Deliver上行消息是服务端主动推送，需独立线程异步处理；
✅ 报文体含Msg_Content（GB2312 编码）、Dest_terminal_Id（最多 100 个手机号）、TP_pid/TP_udhi等 12+ 可选字段，且部分字段长度动态依赖前序字段值（TLV 结构）。

常见误区是直接套用 Spring Boot WebMVC 或 OkHttp 发“POST 请求”，这根本无法满足长连接、心跳、序号强约束等刚性要求。本实现采用Java NIO + Selector 多路复用，而非 Netty，原因很实在：Netty 的 ChannelPipeline 在处理 CMPP 这种“固定包头+变长体+TLV嵌套”的二进制协议时，容易因LengthFieldBasedFrameDecoder配置偏差导致粘包/半包，而 CMPP 对字节偏移零容忍（比如Status字段必须严格位于报文第 12–15 字节）。我们选择裸写ByteBuffer解析，把协议细节完全暴露给开发者——这是血泪经验：某次线上故障，就是 Netty 自动截断了 TLV 中的LinkID字段，导致状态报告无法关联原始提交。

2.1 核心类职责划分：从CMPPConnection到CMPPMessageEncoder

整个工程以CMPPConnection为通信中枢，它持有一个SocketChannel和一个Selector，并启动两个守护线程：

• HeartbeatThread：每 28 秒（预留 2 秒网络抖动余量）调用sendActiveTest()，超时未收到响应则触发重连；
• ReceiveThread：阻塞于selector.select()，收到数据后交由CMPPMessageDecoder.decode()解析。

CMPPMessageEncoder是关键——它不返回byte[]，而是直接向ByteBuffer写入。例如CMPPConnectRequest的编码逻辑：

public void encode(CMPPConnectRequest req, ByteBuffer buffer) { // 包头：总长度（4字节）= 40 + authString.length() + 1 int bodyLen = 40 + req.getAuthString().length() + 1; buffer.putInt(bodyLen); // Total_Length buffer.putInt(CMPPConstants.CMPP_CONNECT); // Command_Id buffer.putInt(0); // Sequence_Id —— 此处留空，由 Connection 层统一分配 buffer.putInt(req.getSourceAddr()); // Source_Addr buffer.put(req.getAuthString().getBytes(StandardCharsets.ISO_8859_1)); // Auth_String, ISO-8859-1 buffer.put((byte) 0x00); // Reserved buffer.putInt(req.getVersion()); // Version: 0x30 for 3.0 }

注意：Auth_String必须用ISO_8859-1编码（非 UTF-8），这是 CMPP 3.0 强制规定。运营商网关校验时若发现字节长度不符（如 UTF-8 下中文占 3 字节，而协议要求 1 字节），直接拒绝连接。此处getAuthString()返回的是MD5(source_addr + shared_secret + timestamp)的十六进制字符串，长度恒为 32 字符。

2.2 Sequence_Id 的原子管理：为什么用AtomicLong而非synchronized？

CMPP 协议要求：同一 TCP 连接内，所有请求报文的Sequence_Id必须严格递增，且不能重复。它不仅是请求标识，更是网关做流量控制、防重放的核心依据。若Sequence_Id错乱，网关会返回CMPP_SUBMIT_RESP状态码20（消息实体错误），但不会告诉你错在哪——这是最玄学的翻车点。

本实现中，CMPPConnection持有一个private final AtomicLong sequenceId = new AtomicLong(0)。每次调用send()方法前，执行：

long seq = sequenceId.incrementAndGet(); if (seq > 0x7FFFFFFF) { // 溢出保护：CMPP 规定 Sequence_Id 为 signed int sequenceId.set(1L); seq = 1L; } message.setHeaderSequenceId(seq);

提示：AtomicLong比synchronized更轻量，且避免了锁竞争。曾在线上压测中发现，当 QPS > 500 时，synchronized块导致send()平均延迟飙升至 12ms，而AtomicLong稳定在 0.3ms。溢出重置逻辑必须存在——某次凌晨 3 点自动重连后，Sequence_Id从0x7FFFFFFF跳到负数，导致后续所有提交被网关静默丢弃，排查耗时 4 小时。

2.3 TLV 字段解析器：如何安全读取Dest_terminal_Id这种变长数组？

CMPP_Submit报文中，Dest_terminal_Id是一个 TLV（Tag-Length-Value）结构：Tag=0x0005，Length表示后续Value字节数，Value是多个手机号拼接的 GB2312 字符串（无分隔符）。标准写法是先读 2 字节 Tag，再读 2 字节 Length，最后按 Length 读取 Value。但问题在于：Length字段本身可能被网络抖动截断，或网关误发错误长度。

本实现的TLVParser采用防御式解析：

public List<String> parseDestTerminalIds(ByteBuffer buffer) { List<String> list = new ArrayList<>(); while (buffer.hasRemaining()) { if (buffer.remaining() < 4) break; // Tag(2)+Length(2) 至少需 4 字节 short tag = buffer.getShort(); if (tag != 0x0005) break; // 非目标 Tag，退出 int length = buffer.getShort() & 0xFFFF; // 转为无符号 if (length == 0 || buffer.remaining() < length) { log.warn("Invalid TLV length {} for Dest_terminal_Id", length); break; } byte[] bytes = new byte[length]; buffer.get(bytes); String content = new String(bytes, StandardCharsets.GB2312); // 按 21 字节/号码切分（CMPP 规定手机号最大 21 字符） for (int i = 0; i < content.length(); i += 21) { int end = Math.min(i + 21, content.length()); list.add(content.substring(i, end).trim()); } } return list; }

关键点：buffer.getShort()读取的是大端序（Big-Endian），CMPP 协议强制要求；& 0xFFFF是为了将short转为int时避免符号扩展（如0xFFFF→-1）；手机号切分逻辑必须存在——网关返回的Dest_terminal_Id是连续字符串，不加切分会导致13812345678139876543210被当成一个号码。

3. 连接建立与心跳保活：从CMPP_Connect到CMPP_ActiveTest的全链路状态机

CMPP 连接不是“连上就完事”，而是一个需持续维护的状态机。本实现将连接生命周期划分为DISCONNECTED→CONNECTING→HANDSHAKING→ESTABLISHED→HEARTBEAT_FAILED→DISCONNECTED六个状态，全部由CMPPConnection内部volatile State state控制，并通过synchronized块保证状态变更原子性。任何状态异常（如心跳超时、收到CMPP_TERMINATE）都会触发onConnectionLost()回调，由上层决定是否重连。

3.1CMPP_Connect握手流程：鉴权失败的 3 种真实原因

CMPP_Connect是整个链路的第一道门，其CMPP_ConnectResp返回码直接决定能否进入业务阶段。本实现中，connect()方法会：

1. 创建CMPPConnectRequest，填充Source_Addr（企业代码，6位数字）、Shared_Secret（与网关协商的密钥）、Version（0x30）；
2. 计算Auth_String = MD5(source_addr + shared_secret + timestamp)，取其十六进制字符串；
3. 发送报文，等待CMPP_ConnectResp（超时 10 秒）；
4. 解析响应：Status字段为0表示成功，非0则记录具体错误码。

常见失败码及根因：

避坑 / 常见问题 / 排查 / 注意
现象 1：CMPP_ConnectResp.Status = 2，但确认账号密码无误
→ 原因：Shared_Secret在配置文件中被 IDE 自动 trim 掉了末尾空格（如"abc123 "→"abc123"），而网关侧保留空格。
→ 解决：打印sharedSecret.getBytes(StandardCharsets.ISO_8859_1).length，确认为预期字节数（通常 8 或 16）。

现象 2：连接成功后 1 分钟内自动断开，日志显示No response for ActiveTest
→ 原因：客户端ActiveTest发送间隔设为 30 秒，但网关侧配置的KeepAliveTimeout为 25 秒，且未开启ActiveTestResp回复。
→ 解决：联系网关管理员确认KeepAliveTimeout值，将客户端心跳间隔设为timeout - 3秒（如 22 秒）。

现象 3：CMPP_Submit发送后，CMPP_SubmitResp的Msg_Id全为0
→ 原因：CMPP_ConnectResp中Status=0，但Version字段被网关忽略，实际走的是 CMPP 2.0 流程，而 2.0 的Msg_Id是 8 字节，本实现按 3.0 解析为 4 字节导致错位。
→ 解决：在CMPPConnectResponse.decode()中增加if (version == 0x20) { useCmpp20Mode = true; }分支，切换解析逻辑。

现象 4：多线程并发调用send()，部分请求Sequence_Id重复
→ 原因：AtomicLong.incrementAndGet()被正确调用，但CMPPMessage对象被复用，setHeaderSequenceId()覆盖了前一次值。
→ 解决：CMPPMessage设计为不可变对象（Immutable），每次send()都new一个新实例，禁止复用。

现象 5：CMPP_Deliver上行消息中Msg_Content乱码，显示为??
→ 原因：Msg_Content字段编码为 GB2312，但ByteBuffer.get()后直接new String(bytes)默认用平台编码（Linux 为 UTF-8）。
→ 解决：强制指定new String(bytes, StandardCharsets.GB2312)，并在CMPPDeliverRequest.decode()中加入charset参数校验。

3.2 心跳保活机制：ActiveTest不是“发个包就行”，而是状态同步信号

CMPP_ActiveTest看似简单（Command_Id=0x00000008，无报文体），但它承担着三重责任：

1. 链路存活探测：证明客户端仍在线；
2. 时间同步锚点：网关可能据此调整自身超时计时器；
3. 状态清零信号：某些网关在收到ActiveTest后，会清空内部待重发队列。

本实现的HeartbeatThread不仅定时发送，还做了三重保障：

• 发送前检查connection.getState() == ESTABLISHED，避免向断连状态发包；
• 发送后启动ScheduledFuture，15 秒未收到ActiveTestResp则标记heartbeatFailed = true；
• 连续 3 次心跳失败，触发onConnectionLost(ConnectionLossReason.HEARTBEAT_TIMEOUT)。

关键代码：

private void sendActiveTest() { if (state != State.ESTABLISHED) return; CMPPActiveTestRequest req = new CMPPActiveTestRequest(); req.setHeaderSequenceId(sequenceId.incrementAndGet()); try { encoder.encode(req, writeBuffer); writeBuffer.flip(); channel.write(writeBuffer); writeBuffer.clear(); lastHeartbeatTime = System.currentTimeMillis(); heartbeatFailed = false; } catch (IOException e) { log.error("Failed to send ActiveTest", e); onConnectionLost(ConnectionLossReason.SOCKET_WRITE_ERROR); } }

注意：lastHeartbeatTime用于计算“距上次心跳已过去多久”，是判断是否该重发的依据；heartbeatFailed是 volatile 变量，供ReceiveThread在收到ActiveTestResp时置为false，形成双向状态同步。

3.3 断连重连策略：指数退避 + 最大重试次数，拒绝“狂轰滥炸”

无脑重连是压垮网关的元凶。本实现采用带 jitter 的指数退避（Exponential Backoff with Jitter）：

• 初始重连间隔：1 秒；
• 每次失败后：nextDelay = min(60, currentDelay * 2 + random(0, 1000))毫秒；
• 最大重试次数：5 次；
• 第 5 次失败后，停止重试，抛出CMPPConnectionException("Max retry exceeded")，交由上层告警。

ReconnectTask类封装此逻辑：

public class ReconnectTask implements Runnable { private final CMPPConnection connection; private final AtomicInteger retryCount = new AtomicInteger(0); private final Random jitter = new Random(); public void run() { int count = retryCount.incrementAndGet(); if (count > 5) { throw new CMPPConnectionException("Max retry exceeded"); } long baseDelay = (long) Math.pow(2, count - 1) * 1000; // 1s, 2s, 4s... long jitterDelay = jitter.nextLong(1000); // 0-999ms long delay = Math.min(60_000, baseDelay + jitterDelay); try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } connection.connect(); // 执行重连 } }

提示：Math.pow(2, count - 1)生成 1, 2, 4, 8, 16 秒的基线；jitter避免多客户端在同一时刻重连造成雪崩；Math.min(60_000, ...)限制最大等待为 60 秒，防止无限等待。

4. 短信提交与状态报告：CMPP_Submit的 7 个必填字段与CMPP_Deliver的异步分发

CMPP_Submit是业务核心，但它的字段规则比想象中更苛刻。本实现严格遵循《CMPP3.0 协议规范》，将CMPPSubmitRequest设计为 Builder 模式，强制校验关键字段：

CMPPSubmitRequest request = CMPPSubmitRequest.builder() .destTerminalId("13812345678") // 必填：接收方手机号 .msgContent("【签名】测试短信") // 必填：GB2312 编码，含签名（运营商要求） .serviceId("10690123456") // 必填：SP 服务代码，12位数字 .feeType("01") // 必填："01"表示按条计费 .feeCode("000000") // 必填：资费代码，6位 .tpPid((byte) 0) // 必填：短消息类型，0=普通短信 .tpUdhi((byte) 0) // 必填：用户数据头标志，0=无UDH .msgFmt((byte) 15) // 必填：信息格式，15=GB2312 .build();

4.1CMPP_Submit字段详解：哪些能空，哪些必须填？

CMPP 3.0 中CMPP_Submit共 18 个字段，但生产环境真正必填的只有 7 个（其余可设默认值）。本实现validate()方法会校验：

注意：Msg_Content必须含签名，且签名格式为【XXX】（中文全角括号），运营商网关会校验签名合法性；Service_Id必须与Source_Addr在网关备案一致，否则返回Status=3（非法源地址）。

4.2CMPP_SubmitResp解析：如何从Result和Msg_Id关联原始请求？

CMPP_SubmitResp返回两个关键信息：

• Result：0=成功，非 0 为错误码（如1=未知错误，2=消息结构错）；
• Msg_Id：网关分配的 8 字节唯一 ID，用于后续查询状态报告或上行匹配。

本实现通过RequestMap维护未完成请求：

private final Map<Long, CompletableFuture<CMPPSubmitResponse>> requestMap = new ConcurrentHashMap<>(); // 发送前 long seq = sequenceId.incrementAndGet(); CompletableFuture<CMPPSubmitResponse> future = new CompletableFuture<>(); requestMap.put(seq, future); // 收到 CMPP_SubmitResp 后 CMPPSubmitResponse resp = decoder.decodeSubmitResp(buffer); CompletableFuture<CMPPSubmitResponse> f = requestMap.remove(resp.getHeaderSequenceId()); if (f != null) f.complete(resp);

提示：ConcurrentHashMap保证高并发下的线程安全；remove()原子性确保一个响应只触发一个complete()，避免CompletableFuture被多次完成导致IllegalStateException。

4.3CMPP_Deliver上行处理：为什么必须用独立线程池？

CMPP_Deliver是网关主动推送的上行消息（用户回复），它不对应任何客户端请求，且可能在任意时刻到达。若在ReceiveThread中直接处理，会阻塞心跳和提交响应的接收。因此，本实现启动DeliverExecutor线程池（核心线程数 = CPU 核数）：

private final ExecutorService deliverExecutor = Executors.newFixedThreadPool( Runtime.getRuntime().availableProcessors(), r -> { Thread t = new Thread(r, "CMPP-Deliver-Handler"); t.setDaemon(true); return t; } ); // ReceiveThread 中 if (commandId == CMPPConstants.CMPP_DELIVER) { CMPPDeliverRequest deliver = decoder.decodeDeliver(buffer); deliverExecutor.submit(() -> handleDeliver(deliver)); }

handleDeliver()方法负责：

• 解析Msg_Content（GB2312）；
• 提取Src_terminal_Id（用户手机号）；
• 调用deliverCallback.onDeliver(deliver)通知业务层；
• 发送CMPP_DeliverResp确认接收（Result=0）。

避坑 / 常见问题 / 排查 / 注意
现象 1：CMPP_Deliver收到后，CMPP_DeliverResp未发送，网关反复重发同一条上行
→ 原因：handleDeliver()中业务逻辑抛出未捕获异常，导致deliverExecutor线程终止，后续上行无人处理。
→ 解决：在deliverExecutor.submit()外层加try-catch(Throwable)，确保sendDeliverResp()总被执行。

现象 2：Msg_Content中的中文显示为?，但日志打印字节数组确认是 GB2312
→ 原因：log.info("content: {}", deliver.getMsgContent())调用了toString()，而String构造时未指定 charset。
→ 解决：日志中显式写new String(deliver.getMsgContentBytes(), StandardCharsets.GB2312)。

现象 3：同一用户连续回复两条，CMPP_DeliverResp发送顺序错乱，网关认为第一条未确认
→ 原因：deliverExecutor是无序线程池，sendDeliverResp()未加锁，导致 TCP 写入乱序。
→ 解决：CMPPConnection持有一个private final Object deliverRespLock = new Object()，sendDeliverResp()必须synchronized(deliverRespLock)。

现象 4：Src_terminal_Id解析出 21 位字符串，但实际手机号只有 11 位，后面是乱码
→ 原因：Dest_terminal_IdTLV 解析逻辑被复用，但Src_terminal_Id是定长 21 字节，需new String(bytes, 0, 11, StandardCharsets.US_ASCII)截取。
→ 解决：CMPPDeliverRequest.decode()中单独处理Src_terminal_Id，按 ASCII 截取前 11 字节。

现象 5：CMPP_Deliver频率突增，线程池队列满，新上行被丢弃
→ 原因：Executors.newFixedThreadPool()的LinkedBlockingQueue容量为Integer.MAX_VALUE，OOM 风险高。
→ 解决：改用new ThreadPoolExecutor(core, max, keepAlive, TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000))，队列满时拒绝策略设为CallerRunsPolicy。

5. 生产环境部署与监控：从 JVM 参数到自定义 Metrics 埋点

这份cmpp3.0_JAVA_实现不是实验室玩具，它被某高校短信平台稳定运行 3 年，日均处理 200 万+ 条短信。上线前，必须完成三件事：JVM 调优、连接池隔离、关键指标埋点。

5.1 JVM 参数调优：为什么-XX:+UseG1GC是底线？

CMPP 客户端是典型的 I/O 密集型应用：大量ByteBuffer分配/回收、频繁的SocketChannel.read/write、心跳定时任务。我们实测对比了 CMS、Parallel、G1 三种 GC：

G1 的优势在于：

• 可预测停顿（-XX:MaxGCPauseMillis=50）；
• 大内存友好（堆 > 4G 时 CMS 易失败）；
• Region 粒度回收，避免大对象引发 Full GC。

推荐启动参数：

java -Xms4g -Xmx4g \ -XX:+UseG1GC \ -XX:MaxGCPauseMillis=50 \ -XX:+UseStringDeduplication \ -XX:+AlwaysPreTouch \ -Dfile.encoding=GBK \ -jar cmpp-client.jar

注意：-Dfile.encoding=GBK确保System.getProperty("file.encoding")返回GBK，避免new String(bytes)默认用 UTF-8；-XX:+AlwaysPreTouch提前触碰所有内存页，减少运行时 page fault。

5.2 连接池隔离：为什么一个网关故障不能拖垮整个系统？

某次生产事故：A 省网关因机房断电不可用，客户端重连失败后疯狂重试，耗尽线程池，导致 B 省、C 省网关的连接也全部超时。根源在于所有网关共用一个ExecutorService。本实现改为按网关域名隔离连接池：

public class CMPPConnectionPool { private final Map<String, CMPPConnection> connections = new ConcurrentHashMap<>(); private final Map<String, ScheduledExecutorService> heartbeats = new ConcurrentHashMap<>(); public CMPPConnection getConnection(String host, int port) { String key = host + ":" + port; return connections.computeIfAbsent(key, k -> { CMPPConnection conn = new CMPPConnection(host, port); ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor( r -> new Thread(r, "CMPP-Heartbeat-" + key) ); heartbeats.put(key, scheduler); return conn; }); } }

每个网关独占一个ScheduledExecutorService，故障时只影响自身心跳线程，不影响其他网关。

5.3 自定义 Metrics 埋点：5 个必须监控的黄金指标

没有监控的 CMPP 客户端等于盲人开车。我们在CMPPConnection中注入MeterRegistry（Micrometer），埋点以下指标：

示例埋点代码：

private final Timer submitTimer; private final Counter deliverCounter; public void onDeliver(CMPPDeliverRequest deliver) { deliverCounter.increment(); // ... 业务逻辑 } public void onSendSubmit(CMPPSubmitRequest req) { Timer.Sample sample = Timer.start(meterRegistry); // 发送逻辑 sample.stop(submitTimer); }

提示：cmpp.heartbeat.missed是最灵敏的链路健康指标——它比connection.state更早发现问题（状态还是 ESTABLISHED，但心跳已开始丢失）。

6. 故障复盘与终极验证技巧：用 Wireshark 抓包比对每一个字节，是我每次上线前的后悔药

去年双十二前夜，某电商短信通道突发 30% 提交失败，CMPP_SubmitResp.Status=1（消息结构错），但所有字段校验都通过。我们花了 6 小时，最终靠 Wireshark 抓包定位：Msg_Content字段末尾多了一个\0字节。原因是String.getBytes(StandardCharsets.GB2312)返回的字节数组，被ByteBuffer.put(byte[])写入后，buffer.position()比预期多 1，导致后续字段整体偏移。这个 bug 在单元测试里永远测不出，因为测试用的是内存ByteBuffer，而真实网络传输会暴露字节对齐问题。

从此，我养成了一个铁律：每次协议升级、每次网关版本变更、每次上线新功能，必须用 Wireshark 抓包，与《CMPP3.0 协议规范》附录 A 的报文样例逐字节比对。这不是矫情，是 CMPP 开发者的生存本能。

6.1 Wireshark 过滤与解码：如何让 CMPP 报文“开口说话”

Wireshark 默认不识别 CMPP，需手动配置解码：

1. 启动 Wireshark，过滤tcp.port == 7890（CMPP 默认端口）；
2. 右键 TCP 流 →Follow → TCP Stream，确认看到十六进制数据；
3. 新建Decode As规则：TCP port 7890 → CMPP（需提前安装 CMPP 解码插件，或手动设置tcp.port == 7890为Raw）；
4. 关键字段定位：
   • Total_Length：报文前 4 字节，大端序；
   • Command_Id：第 4–7 字节，如00 00 00 01=CMPP_CONNECT；
   • Sequence_Id：第 8–11 字节；
   • Msg_Content：从Msg_Fmt字段后开始，长度由Msg_Length字段（CMPP_Submit中

本文还有配套的精品资源，点击获取