第 1 章 · 02 协议总览与报文家族
文档摘要
第 1 章 · 02 协议总览与报文家族 本节摘要:本节搭出 MQTT 的协议骨架:两种角色(客户端/服务端)、三种语义角色(发布者/订阅者/代理)、以及全部 14 种控制报文的家族图谱。这 14 种报文就是 MQTT 的全部"词汇表"——后续所有章节都在拆解它们。读完本节,你应当能默写出 14 种报文的名称、方向与一句话职责。 学习目标 阅读完本节,你应当能够: 区分"客户端/服务端"与"发布者/订阅者"两组角色概念。 默写 14 种控制报文名称,并说出每种报文的传输方向。 解释"控制报文"与"应用消息"两个概念的区别。 一、两种角色 MQTT 协议里只有两种角色: 角色 | 说明 客户端 Client | 使用 MQTT 的程序或设备。
第 1 章 · 02 协议总览与报文家族
本节摘要:本节搭出 MQTT 的协议骨架:两种角色(客户端/服务端)、三种语义角色(发布者/订阅者/代理)、以及全部 14 种控制报文的家族图谱。这 14 种报文就是 MQTT 的全部"词汇表"——后续所有章节都在拆解它们。读完本节,你应当能默写出 14 种报文的名称、方向与一句话职责。
学习目标
阅读完本节,你应当能够:
- 区分"客户端/服务端"与"发布者/订阅者"两组角色概念。
- 默写 14 种控制报文名称,并说出每种报文的传输方向。
- 解释"控制报文"与"应用消息"两个概念的区别。
一、两种角色
MQTT 协议里只有两种角色:
| 角色 | 说明 |
|---|---|
| 客户端 Client | 使用 MQTT 的程序或设备。它通过网络连接到服务端,可以发布应用消息、订阅主题以接收消息、取消订阅、断开连接。一个客户端既可以是发布者也可以是订阅者。 |
| 服务端 Server(常称 Broker/代理) | 运行 MQTT 服务的程序,负责接受客户端连接、处理订阅、转发消息、维护会话状态。 |
注意术语:发布者/订阅者(Pub/Sub) 描述的是消息语义角色,而客户端/服务端描述的是协议对等方角色。同一个客户端可以同时是发布者和订阅者;而"服务端"绝不发布应用消息——它只做路由和转发。
二、发布/订阅模型:三个角色一台戏
发布/订阅模型的核心价值是解耦:
- 空间解耦:发布者与订阅者互相不认识,不需要知道对方的地址。
- 时间解耦:发布者离线时,服务端可以为它缓存消息(通过会话与 QoS 机制,第 4 章详述)。
- 一对多:一条消息发布一次,所有匹配主题的订阅者都能收到,不需要发布者逐个分发。
三、控制报文:MQTT 的全部词汇
MQTT 协议通过交换控制报文(Control Packet) 通信。协议一共定义了 14 种控制报文,每种由固定报头首字节的"报文类型"字段(高 4 位)唯一标识:
| 类型值 | 报文名称 | 方向 | 一句话职责 |
|---|---|---|---|
| 0 | 保留 | — | 协议规定必须为 0(禁止使用) |
| 1 | CONNECT | 客户端→服务端 | 客户端请求建立连接(唯一入口) |
| 2 | CONNACK | 服务端→客户端 | 服务端确认连接结果 |
| 3 | PUBLISH | 双向 | 发布应用消息(唯一携带应用数据的报文) |
| 4 | PUBACK | 双向 | 发布确认(QoS 1 的回应) |
| 5 | PUBREC | 双向 | 发布收到(QoS 2 第一步) |
| 6 | PUBREL | 双向 | 发布释放(QoS 2 第二步) |
| 7 | PUBCOMP | 双向 | 发布完成(QoS 2 第三步) |
| 8 | SUBSCRIBE | 客户端→服务端 | 请求订阅主题过滤器 |
| 9 | SUBACK | 服务端→客户端 | 确认订阅,逐条返回最大 QoS |
| 10 | UNSUBSCRIBE | 客户端→服务端 | 请求退订主题过滤器 |
| 11 | UNSUBACK | 服务端→客户端 | 确认退订 |
| 12 | PINGREQ | 客户端→服务端 | 心跳请求(保活) |
| 13 | PINGRESP | 服务端→客户端 | 心跳响应 |
| 14 | DISCONNECT | 客户端→服务端 | 优雅断开连接 |
💡 记忆技巧:报文家族可以按生命周期分组——
连接组:CONNECT/CONNACK;
消息组:PUBLISH + PUBACK/PUBREC/PUBREL/PUBCOMP(一主四从);
订阅组:SUBSCRIBE/SUBACK/UNSUBSCRIBE/UNSUBACK;
维持组:PINGREQ/PINGRESP/DISCONNECT。
共 14 种,不多不少。
注意两个关键性质:
- CONNECT 必须是客户端发出的第一条报文;服务端收到第二条 CONNECT 属于协议错误。
- DISCONNECT 必须是客户端发出的最后一条报文,发送后必须关闭网络连接。
- PUBLISH 是唯一能传输应用消息(用户数据)的报文,其余报文都是"管理报文"。
四、应用消息与控制报文
两个易混淆的概念:
- 应用消息(Application Message):应用层真正要传输的数据,即"一条业务数据"。它由 PUBLISH 报文承载,并关联一个主题(Topic) 和服务质量(QoS)。
- 控制报文(Control Packet):协议的"信封",包括 CONNECT 等 14 种。应用消息只是其中 PUBLISH 报文携带的"内容"。
打个比方:控制报文是快递流程(下单/揽收/派送/签收),应用消息是包裹里的货物。快递流程每一步都有单据,但只有"派送"这一步真正搬运货物。
小结
MQTT 的全部行为,就是14 种控制报文在不同角色间的流动。记住这个家族图谱,你就拥有了阅读后续章节的地图:第 2 章讲所有报文的通用格式,第 3 章逐个拆解,第 4 章讲这些报文在协议流程中怎么配合。