mqtt协议无“mqtts”标准名称，实为mqtt over tls；需先完成tls握手，再按v3.1.1/v5.0规范解析二进制流，重点处理可变长度编码、粘包及版本差异。
MQTT协议本身不定义“MQTTS”这个标准名称
实际中不存在叫 MQTTS 的独立协议；你看到的很可能是对 MQTT over TLS（即 TLS 加密通道上的 MQTT）的误写或简写。真正要解析的是 MQTT 协议数据包，只是它跑在 SSL/TLS 连接之上——加密层由网络栈（如 OpenSSL、mbedTLS）负责解密，应用层拿到的仍是原始 MQTT 二进制流。
所以关键不是“解析 MQTTS”，而是：确保 TLS 握手成功后，从 socket 读出的字节流符合 MQTT v3.1.1 或 v5.0 协议规范，并按其固定结构逐字段提取。
从 TCP 流中可靠提取完整 MQTT 数据包
MQTT 包是变长的，首字节含类型+标志，第二起是剩余长度（最多 4 字节编码），必须先读够长度才能解析。常见错误是直接 recv() 一次就处理，导致粘包或截断。
- 用循环
recv()拿到至少 2 字节，解出remaining length字段（按 MQTT 规范的可变字节整数格式） - 再循环读取对应字节数，直到收满整个包（注意：
remaining length不含首 2 字节） - 不要依赖单次系统调用返回全部数据；TCP 是字节流，没有消息边界
- 若用
boost::asio，可用async_read配合transfer_exactly(N)；裸 socket 则需自己维护缓冲区和状态机
手动解析 CONNECT/PUBLISH/CONNACK 等报文头
所有 MQTT 报文都以固定结构开头：fixed header（2–5 字节） + 可选 variable header + 可选 payload。例如 PUBLISH：
// 示例：解析 PUBLISH 固定头（伪代码） uint8_t first_byte = buf[0]; uint8_t type = (first_byte & 0xF0) >> 4; // 3 = PUBLISH uint8_t qos = (first_byte & 0x06) >> 1; // QoS level bool retain = first_byte & 0x01; uint32_t remaining_len = decode_mqtt_length(buf + 1); // 自行实现可变字节解码
重点注意：
-
decode_mqtt_length()必须按规范处理每个字节低 7 位、最高位是否置 1 来判断是否继续读 -
CONNECT的variable header含 protocol name/level、clean session、keepalive，顺序和长度严格固定 -
PUBLISH的variable header含 topic name（带长度前缀）、packet id（QoS > 0 时存在） - 忽略未识别的标志位或字段，但不能跳过已知长度字段，否则后续解析全错
用现成库比手撕更稳，但得清楚它在哪介入
像 paho.mqtt.c++ 或 mosquittopp 这类 C++ 封装，本质是在 TLS 层之上做了协议解析和状态管理。它们不帮你做 TLS 握手，但会把解密后的二进制流喂给内部 parser。
如果你需要深度定制（比如只解析特定字段、做流量审计、不响应 PUBACK），就得绕过高层 API，直接对接底层 socket 并自己解析——此时必须严格遵循 MQTT v3.1.1 Section 2 的字节布局定义，一个 bit 都不能错。
最容易被忽略的是：MQTT v5.0 引入了 property 字段（length-prefixed map），它出现在多个报文的 variable header 末尾，且长度可变；v3.1.1 没这东西。混用版本解析逻辑会导致 payload 偏移错乱。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
