Update README.md
This commit is contained in:
Natsume1710
+105
-4
@@ -49,10 +49,111 @@ recv();
|
||||
|
||||
## 物联网协议栈
|
||||
|
||||
### MQTT
|
||||
- 轻量级发布-订阅协议，常用于设备与云平台交互
|
||||
- QoS 等级、主题结构、客户端连接
|
||||
- 常见平台支持：EMQX、OneNet、阿里云 IoT
|
||||
#### MQTT 协议详解
|
||||
|
||||
**MQTT (Message Queuing Telemetry Transport)** 是一种**轻量级、发布/订阅模式**的消息传输协议。它专为**资源受限的设备**（如物联网 IoT 设备）以及**低带宽、高延迟或不稳定网络**环境而设计。因其高效、可靠地传输少量数据的能力，MQTT 在物联网领域得到了广泛应用。
|
||||
|
||||
|
||||
#### 1. 核心概念与架构
|
||||
|
||||
MQTT 协议由以下三个主要组件构成：
|
||||
|
||||
* **发布者 (Publisher)**：产生并发送消息的客户端设备或应用程序。发布者只负责将消息发送到**主题（Topic）**，不关心谁会接收消息。
|
||||
* **订阅者 (Subscriber)**：接收消息的客户端设备或应用程序。订阅者通过**订阅一个或多个主题**来表明对哪些消息感兴趣。
|
||||
* **消息代理/服务器 (Broker)**：MQTT 协议的核心。它负责接收发布者发送的消息，并根据消息的**主题**将消息路由到所有订阅了该主题的客户端。Broker 还处理客户端的连接、断开、订阅、取消订阅等请求，并管理会话状态。
|
||||
|
||||
**工作流程概览：**
|
||||
|
||||
* 客户端（发布者或订阅者）与 MQTT Broker 建立 **TCP 连接**。
|
||||
* 发布者将消息发送给 Broker，消息包含一个**主题**和一个**有效载荷（Payload）**。
|
||||
* Broker 接收到消息后，根据消息的**主题**，将其转发给所有订阅了该主题的订阅者。
|
||||
* 订阅者接收到 Broker 转发的消息。
|
||||
|
||||
#### 2. 发布/订阅 (Publish/Subscribe) 模式
|
||||
|
||||
这是 MQTT 与传统请求/响应（Request/Response，如 HTTP）模式最显著的区别，也是其优势所在：
|
||||
|
||||
* **解耦性：** 发布者和订阅者之间无需直接知道对方的存在，它们只与 Broker 通信。这使得系统更加灵活、可伸缩、易于维护。
|
||||
* **异步通信：** 消息是异步发送和接收的，发布者无需等待订阅者的响应。这对于实时性要求不高但需要持续传输数据的场景非常有效。
|
||||
* **一对多通信：** 一个发布者发送的消息可以同时被多个订阅者接收，非常适合广播和通知场景。
|
||||
* **主题 (Topic)：**
|
||||
* MQTT 使用主题来分类和路由消息。主题是层级的字符串，例如 `home/livingroom/temperature` 或 `factory/line1/machine/status`。
|
||||
* 主题支持**通配符**：
|
||||
* `+`：**单层通配符**，表示一个层级。例如 `home/+/temperature` 可以匹配 `home/livingroom/temperature` 和 `home/bedroom/temperature`。
|
||||
* `#`：**多层通配符**，表示零或多层。例如 `home/#` 可以匹配 `home/livingroom/temperature`、`home/bedroom/light` 以及 `home` 下的所有子主题。
|
||||
|
||||
#### 3. 服务质量等级 (Quality of Service - QoS)
|
||||
|
||||
MQTT 提供三种 QoS 等级，以满足不同场景下对消息可靠性的要求，实现发布者与 Broker、Broker 与订阅者之间的消息传递保证：
|
||||
|
||||
* **QoS 0: At Most Once (最多一次)**
|
||||
* 消息发送后即“即发即弃”，不保证消息一定能到达，也不会重试。
|
||||
* **优点：** 传输速度最快，开销最小。
|
||||
* **适用场景：** 对实时性要求高、偶尔丢失消息可以接受的场景，如环境传感器数据、非关键性日志等。
|
||||
|
||||
* **QoS 1: At Least Once (至少一次)**
|
||||
* 消息至少会被送达一次，但可能会重复送达。
|
||||
* Broker 在收到消息后会发送确认包（PUBACK）。如果发布者在规定时间内未收到 PUBACK，会重发消息。
|
||||
* **优点：** 保证消息不丢失，适用于重要但不介意重复的消息。
|
||||
* **适用场景：** 命令控制、重要警报，但上层应用需要处理消息重复。
|
||||
|
||||
* **QoS 2: Exactly Once (只交付一次)**
|
||||
* 消息只会被送达一次，保证不丢失也不重复。这是最高级的 QoS。
|
||||
* 通过四次握手（PUBLISH, PUBREC, PUBREL, PUBCOMP）实现。
|
||||
* **优点：** 最高可靠性，保证消息的唯一性和完整性。
|
||||
* **适用场景：** 金融交易、计费数据、关键控制命令等对可靠性有严格要求的场景。
|
||||
* **缺点：** 传输开销最大，效率最低。
|
||||
|
||||
#### 4. 会话管理与持久会话 (Session Management & Persistent Sessions)
|
||||
|
||||
* **Clean Session (清洁会话)：**
|
||||
* 当客户端连接 Broker 时，可以设置 `Clean Session` 标志为 `true` 或 `false`。
|
||||
* **`Clean Session = true` (非持久会话/瞬时会话)：** 客户端每次连接都是一个新的会话。断开连接后，Broker 会清除该客户端的所有订阅和未发送的消息。当客户端重新连接时，会话是全新的，需要重新订阅。
|
||||
* **`Clean Session = false` (持久会话)：** 客户端断开连接后，Broker 会保存其会话状态，包括订阅列表、QoS 1 和 QoS 2 未发送/未确认的消息。当客户端以相同的 `Client ID` 重新连接时，会话会恢复，Broker 会发送离线期间的消息。
|
||||
* **应用：** 持久会话对于网络不稳定、设备可能频繁掉线的物联网场景非常有用，可以确保设备即使离线也能收到重要的离线消息。
|
||||
|
||||
#### 5. 遗嘱消息 (Last Will and Testament - LWT)
|
||||
|
||||
* 客户端在连接 Broker 时，可以注册一条“遗嘱消息”（Will Message）。
|
||||
* 如果客户端在非正常断开连接（如设备故障、网络中断）而没有主动发送 DISCONNECT 报文，Broker 就会自动发布这条预先注册的遗嘱消息到指定的主题。
|
||||
* **作用：** 允许其他客户端（通过订阅该遗嘱主题）感知到某个设备意外离线，从而可以采取相应措施（如状态更新、报警）。
|
||||
|
||||
#### 6. 安全性 (Security)
|
||||
|
||||
MQTT 本身运行在 TCP/IP 协议之上，其安全性主要通过以下层级来保障：
|
||||
|
||||
* **传输层安全 (TLS/SSL)：** 这是最常见的安全方式。MQTT 可以通过 TCP/TLS（即 MQTT over SSL/TLS）进行加密通信，确保数据在传输过程中的机密性和完整性，防止窃听和篡改。
|
||||
* **应用层认证与授权：**
|
||||
* **用户名/密码认证：** 客户端在连接 Broker 时提供用户名和密码进行身份验证。
|
||||
* **客户端证书认证：** 更高级别的认证方式，通过 X.509 客户端证书进行双向身份验证。
|
||||
* **ACL (Access Control List) 授权：** Broker 根据配置的 ACL 规则，限制客户端只能发布或订阅特定的主题，防止未经授权的访问和操作。
|
||||
* **MQTT 5.0 的增强安全特性：** MQTT 5.0 引入了更多安全功能，如增强认证机制、会话过期、用户属性等，进一步提升了协议的安全性。
|
||||
|
||||
#### 7. MQTT 协议包结构 (Control Packet Structure)
|
||||
|
||||
MQTT 控制报文由三部分组成：
|
||||
|
||||
* **固定报头 (Fixed Header)**：所有 MQTT 控制报文都包含，占 1-5 个字节。包含：
|
||||
* **报文类型 (Message Type)**：4 位，表示报文的类型（如 CONNECT, PUBLISH, SUBSCRIBE 等）。
|
||||
* **标志位 (Flags)**：4 位，根据报文类型有不同含义（如 QoS 等级、DUP 标志等）。
|
||||
* **剩余长度 (Remaining Length)**：可变长度编码，表示可变报头和有效载荷的总长度。
|
||||
* **可变报头 (Variable Header)**：部分报文包含，根据报文类型不同而不同。例如，PUBLISH 报文的可变报头包含主题名和报文标识符。
|
||||
* **有效载荷 (Payload)**：部分报文包含，承载实际数据。例如，PUBLISH 报文的有效载荷就是实际要传输的应用数据。
|
||||
|
||||
由于其紧凑的报文结构和二进制有效载荷，MQTT 在数据传输效率上远优于 HTTP 等协议，尤其适用于数据量小、通信频繁的物联网场景。
|
||||
|
||||
#### 8. MQTT vs HTTP (在 IoT 领域)
|
||||
|
||||
| 特性 | MQTT | HTTP |
|
||||
| :----------- | :------------------------------------------- | :---------------------------------------------- |
|
||||
| **通信模式** | **发布/订阅 (Pub/Sub)**，异步，双向 | **请求/响应 (Request/Response)**，同步，单向 |
|
||||
| **连接状态** | **长连接 (Stateful)**，连接建立后可发送多条消息 | **短连接 (Stateless)**，每次请求通常建立新连接 |
|
||||
| **消息开销** | **轻量级**，最小报文头 2 字节，效率高 | **相对重**，报文头较大，多为文本格式 |
|
||||
| **实时性** | **推送 (Push)**，消息实时送达 | **轮询 (Pull)**，客户端定时请求获取更新，非实时 |
|
||||
| **功耗** | 低（长连接减少频繁建连开销） | 高（频繁建连、断连） |
|
||||
| **适用场景** | 资源受限设备、低带宽、频繁数据传输、消息推送 | Web 应用、大数据传输、文件下载、一次性请求 |
|
||||
|
||||
**总结：** MQTT 因其轻量、高效、发布/订阅模式和灵活的 QoS，成为物联网设备间通信的理想选择。它很好地解决了 HTTP 在资源受限和网络不稳定环境下的痛点。
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user