通信协议设计与实现 ​

设备报文到云端服务之间那条看不见的「路」。这个项目是为一套设备体系设计私有二进制协议并实现完整协议栈：帧格式、编解码、粘包拆包、心跳保活、加密校验。做之前觉得「不就是把字节拼一起」，做完才知道协议设计是用最少的花销买最大的确定性。

一、为什么要私有协议 ​

现成协议（HTTP/MQTT/CoAP）不是不能用，但在我们的场景里【待补充：具体场景约束，如带宽、算力、成本】：

• 报文头开销大：HTTP 头动辄几百字节，设备每报一次数据光头就吃掉大半流量
• 解析成本高：文本协议的解析对低算力设备不友好
• 定制需求：需要设备认证、通道复用、自定义重传策略

所以走了私有二进制协议：头开销压到个位数字节，解析是纯字节操作，协议行为完全可控。

二、协议设计 ​

1. 帧格式 ​

┌──────┬──────┬──────┬──────┬─────────┬─────────────┬───────┐
│ MAGIC│ VER  │ FLAGS│ CMD  │ SEQ     │ BODY        │ CRC16 │
│ 2B   │ 1B   │ 1B   │ 1B   │ 2B      │ 0~N B       │ 2B    │
└──────┴──────┴──────┴──────┴─────────┴─────────────┴───────┘

设计取舍（每一字段都有存在理由）：

一个反直觉的决策：没有 LENGTH 字段也能工作（靠 CMD 确定定长/变长），但最后还是加了——变长帧没有长度字段，解析器在拿到完整帧前无法预分配缓冲，内存受限的设备上这是致命的。

2. 协议行为设计 ​

帧格式只是静态部分，协议的「行为」设计更关键：

• 心跳：30 秒间隔，3 次未响应判定断链。心跳帧捎带状态摘要（不额外花流量）
• 请求-响应：SEQ 配对，超时 5 秒重试、最多 3 次；对端用相同 SEQ 回 ACK 防重复执行
• 分包：大报文按 MTU 分片，带片偏移与总片数，乱序到达可重组
• 握手加密：设备首次接入用预置密钥协商会话密钥，之后会话级对称加密【待补充：实际加密方案】

三、实现要点（Java/Netty 侧） ​

服务端协议栈基于 Netty【待补充：实际技术栈】，核心是三个自定义组件：

1. 拆包器：对抗粘包半包 ​

public class ProtocolFrameDecoder extends ByteToMessageDecoder {
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
        // 1. 不够一个最小帧头，等更多字节
        if (in.readableBytes() < HEADER_SIZE) return;
        // 2. 扫描 MAGIC（可能从流中间开始）
        int start = indexOfMagic(in);
        if (start < 0) { in.skipBytes(in.readableBytes() - 1); return; }
        in.skipBytes(start);
        // 3. 长度字段就绪后预判整帧
        int frameLen = in.getUnsignedShort(start + LEN_OFFSET) + HEADER_SIZE;
        if (in.readableBytes() < frameLen) return; // 半包，等
        // 4. 整帧就绪，切出独立 ByteBuf 传给下一站
        out.add(in.readRetainedSlice(frameLen));
    }
}

关键点：readRetainedSlice 零拷贝切帧；每个分支都要考虑「字节还没到齐」的情况——协议解析代码 80% 的行数都在处理「不完整」。

2. 状态机 ChannelHandler ​

连接生命周期（未认证 → 已认证 → 会话中）建模成显式状态机，未认证连接只接受握手指令，其他指令一律丢弃——非法状态下的请求直接拒绝，而不是靠下游业务代码自己判断。

3. 序号去重 ​

设备弱网重发是常态，服务端维护滑动窗口内的 SEQ 集合，重复序号的指令「回放上次响应」而不是重新执行——幂等是重传协议的另一半，没有幂等的重传等于把指令放大 N 倍。

四、测试：协议质量是测出来的 ​

• 一致性测试：同一组字节流，Java/C/Rust【待补充：实际语言组合】三端实现各自解码，结果必须一致——跨端实现是协议文档含糊之处的照妖镜
• 故障注入：随机截断、复制、翻转字节，断言解析器永不崩溃、错误帧必被 CRC 拦截
• 压力与抖动：万级连接 + 随机网络延迟抖动下验证重传与去重的正确性

五、收获 ​

协议设计的本质是在最不可靠的信道上定义确定性的对话规则。字段怎么省、状态怎么定义、失败怎么兜底，每一个决定都要问「对面坏掉时会怎样」。这套思维直接迁移到了后面的物联网和总线项目——它们共享同一个内核：为故障而设计。