物联网 基于netty控制报文结构(报文分类)
简述
从搭建一个能工作的 MQTT 应用出发，以下 6 种报文 是最核心、最常用的，它们覆盖了连接、发布、订阅、心跳和断开的基本流程
一个最小 MQTT 应用需要的报文交互流程
客户端 服务端
|-------- CONNECT (clientId) -------->|
|<------- CONNACK (成功) -------------|
|-------- SUBSCRIBE (topic, qos) ---->|
|<------- SUBACK (qos granted) -------|
|-------- PUBLISH (topic, payload) -->|
|<------- (消息转发给订阅者) ---------|
|-------- PINGREQ ------------------->|
|<------- PINGRESP -------------------|
|-------- DISCONNECT ---------------->|
7 种报文（CONNECT、CONNACK、SUBSCRIBE、SUBACK、PUBLISH、PINGREQ/PINGRESP、DISCONNECT），就能开发出功能完整的 MQTT 客户端或简易 Broker，满足绝大多数物联网数据采集和控制场景
分类如下
| 分类 | 报文 | 方向 | 作用 |
|---|---|---|---|
| 连接与握手 | CONNECT | C→S | 客户端发起连接，携带协议名、版本、Keep Alive、遗嘱、用户名密码 |
| CONNACK | S→C | 服务端确认连接结果（成功/失败） | |
| 发布与接收 | PUBLISH | C↔S | 发布应用消息（可带 QoS 和保留标志） |
| 订阅与取消 | SUBSCRIBE | C→S | 订阅一个或多个主题，请求 QoS |
| SUBACK | S→C | 服务端确认订阅，返回授予的 QoS | |
| 心跳保活 | PINGREQ | C→S | 客户端发送心跳请求 |
| PINGRESP | S→C | 服务端响应心跳 | |
| 断开连接 | DISCONNECT | C→S | 客户端正常断开（可选） |
报文结构
| 报文 | 固定头 | 可变头 | 有效载荷 / 备注 |
|---|---|---|---|
| CONNECT | 类型=1，标志位=0 | 协议名 "MQTT" + 协议级别(4) + 连接标志(1字节) + Keep Alive(2字节) | 客户端标识符（必须），可选：遗嘱主题/消息、用户名、密码 |
| CONNACK | 类型=2，标志位=0，剩余长度=2 | 当前会话标志(1字节) + 返回码(1字节) | 返回码：0=成功，1~5 表示错误 |
| PUBLISH | 类型=3，标志位含 DUP、QoS、RETAIN | 主题名（UTF-8），QoS>0 时有报文标识符(2字节) | 应用消息（二进制） |
| SUBSCRIBE | 类型=8，标志位=2（固定） | 报文标识符(2字节) | 一个或多个“主题过滤器+QoS要求”对 |
| SUBACK | 类型=9，标志位=0 | 与 SUBSCRIBE 相同的报文标识符 | 返回码列表（0/1/2 成功，0x80 失败） |
| PINGREQ / PINGRESP | PINGREQ=0xC0，PINGRESP=0xD0，剩余长度=0 | 无 | 无 |
| DISCONNECT | 0xE0，剩余长度=0 | 无 | 无 |