MQTT协议之消息订阅

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