什么是 MQTT?
MQTT(Message Queuing Telemetry Transport)是一种轻量级、基于发布-订阅模式的消息传输协议,适用于资源受限的设备和低带宽、高延迟或不稳定的网络环境。它在物联网应用中广受欢迎,能够实现传感器、执行器和其它设备之间的高效通信。关于MQTT的更多介绍可以参考EMQ的《MQTT 协议入门:基础知识和快速教程》。本文将主要介绍设备接入 云鲸 MQTTBroker 的配置内容。
前置条件
设备已完成设备认证获得token。
MQTT 连接的基本概念
MQTT 连接由客户端向服务器端发起。任何运行了 MQTT 客户端库的程序或设备都是一个 MQTT 客户端,而 MQTT Broker 则负责接收客户端发起的连接,并将客户端发送的消息转发到另外一些符合条件的客户端。
客户端与服务器建立网络连接后,需要先发送一个 CONNECT
数据包给服务器。服务器收到 CONNECT
包后会回复一个 CONNACK
给客户端,客户端收到 CONNACK
包后表示 MQTT 连接建立成功。如果客户端在超时时间内未收到服务器的 CONNACK 数据包,就会主动关闭连接。
连接地址
均采用 mqtts(基于TCP/SSL的安全连接)统一由设备平台 设备分发接口 返回连接地址,字段其为
device_mqtt_url
客户端 ID(Client ID)
MQTT 服务器使用 Client ID 识别客户端,连接到服务器的每个客户端都必须要有唯一的 Client ID。如果客户端使用一个重复的 Client ID 连接至服务器,将会把已使用该 Client ID 连接成功的客户端踢下线。
格式:sweeper_/
${ProductId}
/${DeviceId}
用户名与密码(Username & Password)
MQTT 协议可以通过用户名和密码来进行相关的认证和授权,仅允许使用 mqtts 协议。
Username格式:/
${ProductId}
/${DeviceId}
Password格式:通过 设备认证接口 获取的token。
连接超时(Connect Timeout)
连接超时时长,收到服务器连接确认前的等待时间,等待时间内未收到连接确认则为连接失败。
目前扫地机为
60s
保活机制(KeepAlive)
保活周期,是一个以秒为单位的时间间隔。客户端在无报文发送时,将按 Keep Alive 设定的值定时向服务端发送心跳报文,确保连接不被服务端断开。
在连接建立成功后,如果服务器没有在 Keep Alive 的2倍
时间内收到来自客户端的任何包,则会认为和客户端之间的连接出现了问题,此时服务器便会断开和客户端的连接。
目前扫地机心跳周期为
60s
注意事项:待讨论看下能否调小至
10~5s
,并结合APP做一些定时获取机制,以提升对设备离线状态判断的准确性和用户体验。
客户端流程
在连接建立后,客户端需要确保, 自己任意两次 MQTT 协议包的发送间隔不超过 Keep Alive 的值,如果客户端当前处于空闲状态,没有可发送的包,则可以发送 PINGREQ
协议包。
当客户端发送 PINGREQ
协议包后,Broker 必须返回一个 PINGRESP
协议包,如果客户端在一个可靠的时间内,没有收到服务器的 PINGRESP
协议包,则说明当前存在半连接、或者 Broker 已经下线、或者出现了网络故障,这个时候,客户端应当关闭当前连接。
Broker 流程
在连接建立后,Broker 如果没有在 Keep Alive 的2倍
时间内,收到来自客户端的任何包,则会认为和客户端之间的连接出现了问题,此时 Broker 便会断开和客户端的连接。
如果 Broker 收到了来自客户端的 PINGREQ
协议包,需要回复一个 PINGRESP
协议包进行确认。
客户端接管机制
当 Broker 里存在半连接时,如果对应的客户端发起了重连或新的连接,则 Broker 会启动客户端接管机制:关闭旧的半连接,然后与客户端建立新的连接。
这种机制保证了客户端不会因为 Broker 里存在的半连接,导致无法进行重连。
更多细节可查看博客:MQTT 协议中的 Keep Alive 机制。
消息订阅 \ 发布
发布订阅模式(Publish-Subscribe Pattern)是一种消息传递模式,它将发送消息的客户端(发布者)与接收消息的客户端(订阅者)解耦,使得两者不需要建立直接的联系也不需要知道对方的存在。
MQTT 发布/订阅模式的精髓在于由一个被称为代理(Broker)的中间角色负责所有消息的路由和分发工作,发布者将带有主题的消息发送给代理,订阅者则向代理订阅主题来接收感兴趣的消息。
在 MQTT 中,主题和订阅无法被提前注册或创建,所以代理也无法预知某一个主题之后是否会有订阅者,以及会有多少订阅者,所以只能将消息转发给当前的订阅者,如果当前不存在任何订阅,那么消息将被直接丢弃。
更多介绍详见:MQTT 发布/订阅模式介绍
注意事项:MQTT 仅作为HTTP同类的通信协议,设备状态\事件上报与控制仅需对接物模型相关Topic即可。如无特殊要求,不建议采用 自定义Topic 去做类似的事情。
目前消息订阅与发布的限制如下:
限制项 | 描述 | 限制 |
---|---|---|
设备订阅Topic数 | 一个设备端的最大订阅数,超过订阅数的请求将会被直接拒绝。 客户端可以通过验证SUBACK消息,确认请求是否成功。 |
300个且必须在管控平台内录入 |
权限 | 设备只能对自己的Topic进行消息发布与订阅。 | 无 |
Topic长度 | Topic长度不能超过160字节,UTF-8编码字符。 | 建议不超过160 |
Topic类目 | 一个Topic中最多可包含多少个层级类目,即Topic中斜杠的最大数量。 | 建议不超过7,不支持通配符 |
QoS | 消息质量。使用 MQTT 协议的设备都运行在网络受限的环境下,而只依靠底层的 TCP 传输协议,并不能完全保证消息的可靠到达,其核心是设计了多种消息交互机制来提供不同的服务质量,来满足用户在各种场景下对消息可靠性的要求。 | 目前仅支持QoS 0 |
消息量限流 | 1. 一个客户端每秒最多可上报的QoS 0 消息数量。 2. 限流类型:消息量/秒。 |
最大30条/秒 |
消息报文大小 | 1. MQTT单个发布消息最大长度,超过此大小的发布请求会被直接拒绝。 2. 限流类型:单个消息长度。 |
最大1024kb |
常用工具
- MQTT 调试工具(MQTT X):EMQ 开源的一款跨平台 MQTT 5.0 客户端工具,它支持 macOS, Linux 并且支持自定义脚本模拟测试、MQTT 消息格式转换、日志记录等多个功能。https://mqttx.app/downloads
- 设备在线调试工具:用于更便捷地调试在线设备。模拟应用端向 AIoT云平台 发布控制指令、订阅设备状态\事件消息。——设备平台 25年规划。
- 设备模拟器:用于更便捷地调试应用程序。模拟设备端向 AIoT云平台 上报状态\事件,接收控制命令。——设备平台 25年规划。
最后编辑:陈勇琦 更新时间:2024-10-18 16:29