1 MQTT介绍
MQTT(Message Queuing Telemetry Transport)是一个轻量级的消息传输协议,设计用于低带宽和不可靠的网络环境中。它在物联网(IoT)和移动应用领域广受欢迎,因其简单性和高效性在资源受限的设备上特别有用。以下是对MQTT的详细介绍:
1.1 MQTT的基本概念
-
轻量级协议: MQTT是一个轻量级的发布/订阅(publish/subscribe)消息协议,适用于带宽有限、延迟高、不稳定的网络环境。
-
客户端-服务器架构: MQTT协议基于客户端-服务器架构。客户端向服务器(称为MQTT代理或经纪人)发布消息,并订阅感兴趣的主题来接收消息。
1.2 核心特性
-
发布/订阅模式: 在这种模式下,消息的发送者(发布者)和接收者(订阅者)不需要直接相连,它们通过主题进行通信。
-
轻量级消息: MQTT设计了非常小的控制包,以减少网络流量和设备资源消耗。
-
质量等级(Quality of Service, QoS): 提供三种消息交付质量等级,确保在不同的网络环境下满足不同的消息传输需求。
-
持久会话: 支持持久会话,即使客户端断开连接,一旦重连,也能接收到未接收的消息。
1.3 协议操作
-
连接(Connect): 客户端通过发送CONNECT消息到MQTT代理来建立连接。
-
发布(Publish): 客户端可以发布消息到一个特定的主题。
-
订阅(Subscribe): 客户端订阅一个或多个主题,以接收发布到这些主题的消息。
-
断开(Disconnect): 客户端发送DISCONNECT消息断开与MQTT代理的连接。
1.4 应用场景
-
物联网(IoT): 在IoT领域,MQTT用于连接各种资源受限的设备,如传感器、智能家居设备等。
-
移动应用: 由于其低功耗特性,MQTT在移动应用中用于推送通知和即时消息。
-
远程监控: 在远程监控系统中,MQTT用于传输实时监控数据。
-
车联网: 在车联网应用中,MQTT用于车辆和基础设施之间的通信。
1.5 技术优势
-
效率高: MQTT的设计最小化了网络带宽的需求和设备的电量消耗。
-
易于实现: 协议简单,易于在各种设备上实现。
-
可靠性: 支持不同等级的消息传递保证,从而提高通信的可靠性。
-
安全性: 可以通过SSL/TLS实现数据的加密和安全通信。
1.6 发展和挑战
-
标准化: MQTT已被OASIS标准化,为版本5.0和更高版本添加了更多的特性。
-
安全性挑战: 随着在IoT中的广泛应用,确保数据安全和隐私成为一个重要的挑战。
-
集成和互操作性: 与其他通信协议和平台的集成以及跨平台的互操作性是发展的关键。
MQTT以其轻量级、高效率和易于实现的特性,在物联网和移动应用领域得到了广泛应用。随着技术的发展,MQTT将继续发挥其在低带宽和不稳定网络环境下的通信优势,并在保证安全性和可靠性方面面临新的挑战和机遇。
2 MQTT消息订阅
2.1 SUBSCRIBE
一般来讲,客户端在成功建立TCP连接之后,发送CONNECT消息,在得到服务器端授权允许建立彼此连接的CONNACK消息之后,客户端会发送SUBSCRIBE消息,订阅感兴趣的Topic主题列表(至少一个主题),一个完整示范如下:
Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
---|---|---|---|---|---|---|---|---|---|---|
Fixed header/固定头部 | ||||||||||
byte 1 | Message Type(8) | DUP flag | QoS level | RETAIN | ||||||
1 | 0 | 0 | 0 | 0 | 0 | 1 | x | |||
byte 2 | Remaining Length | |||||||||
Variable header/可变头部 | ||||||||||
Message Identifier | ||||||||||
byte 1 | Message ID MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
byte 2 | Message ID LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | |
Playload/消息体 | ||||||||||
Topic name | ||||||||||
byte 1 | Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
byte 2 | Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | |
byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | |
byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | |
byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | |
Requested QoS | ||||||||||
byte 6 | Requested QoS (1) | x | x | x | x | x | x | 0 | 1 | |
Topic Name | ||||||||||
byte 7 | Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
byte 8 | Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | |
byte 9 | 'c' (0x63) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | |
byte 10 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | |
byte 11 | 'd' (0x64) | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | |
Requested QoS | ||||||||||
byte 12 | Requested QoS (2) | x | x | x | x | x | x | 1 | 0 |
固定头部
Qos Level,可根据实际情况进行调整为0/1/2等。一般设为0表示最多一次。客户端可设置OoS Level值。 DUP flag,值为0表示第一次发送。
可变头部
因为上面示范QoS level值为1,因此需要客户端传递消息ID,16位,无符号的short类型。
消息体
订阅的主题名称采用修改版UTF-8编码,然后紧跟着对应的QoS值。下面的次序,可能更为形象:
Topic name | "a/b" |
Requested QoS | 1 |
Topic name | "c/d" |
Requested QoS | 2 |
订阅者的Topic name支持通配符#和+ :
- #支持一个主题内任意级别话题
- +只匹配一个主题级别的通配符
eg:
finance/stock/#
finance/sotkc/ibm/+
都是有效,更具体规则,请参阅协议附加部分。
在服务器接收处理时,按照顺序读取即可:
String topicName = readUTF();
int qosVal = read();
服务器可以发送QoS不大于客户端设置OoS的消息,尤其是服务器不提供良好的持久化机制的时候。
2.2 SUBACK
服务器会对发出SUBSCRIBE的消息返回一个确认消息。
Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
---|---|---|---|---|---|---|---|---|---|
Fixed header/固定头部 | |||||||||
byte 1 | Message type (9) | DUP flag | QoS flags | RETAIN | |||||
1 | 0 | 0 | 1 | x | x | x | x | ||
byte 2 | Remaining Length | ||||||||
Variable header/可变头部 | |||||||||
Message Identifier | |||||||||
byte 1 | Message ID MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
byte 2 | Message ID LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
Playload/消息体 | |||||||||
byte 1 | Granted QoS (0) | x | x | x | x | x | x | 0 | 0 |
byte 1 | Granted QoS (2) | x | x | x | x | x | x | 1 | 0 |
可变头部
Message Identifier,服务器需要附加,客户端需要处理。
消息体
QoS,为服务器根据实际情况授予的QoS级别列表,和客户端发送的SUBSCRIBE的订阅Topic Name顺序完全一致。
客户端订阅几个TOPIC,服务器端一一给出各个TOPIC的QoS具体值。
2.3 UNSUBSCRIBE
服务器需要支持客户端取消订阅功能,UNSUBSCRIBE消息格式和SUBSCRIBE消息格式差不多,除了消息类型不同,消息体中没有了QoS字节,其它没有区别。
Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
---|---|---|---|---|---|---|---|---|---|---|
Fixed header/固定头部 | ||||||||||
byte 1 | Message Type(10) | DUP flag | QoS level | RETAIN | ||||||
1 | 0 | 1 | 0 | 0 | 0 | 1 | x | |||
byte 2 | Remaining Length | |||||||||
Variable header/可变头部 | ||||||||||
Message Identifier | ||||||||||
byte 1 | Message ID MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
byte 2 | Message ID LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | |
Playload/消息体 | ||||||||||
Topic name | ||||||||||
byte 1 | Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
byte 2 | Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | |
byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | |
byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | |
byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | |
Topic Name | ||||||||||
byte 6 | Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
byte 7 | Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | |
byte 8 | 'c' (0x63) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | |
byte 9 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | |
byte 10 | 'd' (0x64) | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 |
可变头部的消息ID的出现还是由固定头部的QoS Level(1)决定是否存在。
一般来讲,客户端发布退订,服务器端需要返回退订确认。
MQTT没讲是否允许客户端退订所有TOPIC。
2.4 UNSUBACK
服务器返回的UNSUBSCRIBE消息UNSUBACK相应很简单,没有消息体。
Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
---|---|---|---|---|---|---|---|---|---|
Fixed header/固定头部 | |||||||||
byte 1 | Message type (9) | DUP flag | QoS flags | RETAIN | |||||
1 | 0 | 1 | 1 | x | x | x | x | ||
byte 2 | Remaining length (2) | ||||||||
0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | ||
Variable header/可变头部 | |||||||||
Message Identifier | |||||||||
byte 1 | Message ID MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
byte 2 | Message ID LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
3 小结
订阅部分,共有四个消息,分别一一对应。
命令 | 响应 | 备注 | 建议 |
---|---|---|---|
SUBSCRIBE | SUBACK | 协议没有涉及最多运行订阅TOPIC数目,隐藏的隐患 | 建议至多10个 |
UNSUBSCRIBE | UNSUBACK | 是否可以退订所有订阅,不详 | 建议保留至少一个Topic |