MQTT是一种机器对机器(M2M)/”物联网 “连接协议。它设计初衷是用于极轻量级的发布/订阅消息传输。它适于于远程连接环境,需要少量代码交互并且网络带宽很稀缺的场景。例如,通过卫星链路来连接传感器与代理服务器,与医疗服务提供商的偶尔数据连接,以及在一系列家庭自动化和小型设备场景中。它也是移动应用的理想选择,因为它体积小、功耗低、数据包最小化,并能有效地将信息分配给一个或多个接收器。
MQTT.ORG
MQTT是Message Queuing Telemetry Transport的缩写。它是一种轻量级的消息传递协议,用于客户端需要较小的代码占用,并连接到不可靠的网络或带宽资源有限的网络的情况下。它主要用于机器对机器(M2M)通信或物联网类型的连接。
历程
MQTT最初是由Andy Stanford-Clark博士和Arlen Nipper在1999年创建的。该通信方法的最初目的是允许石油和天然气行业使用的监测设备向远程服务器发送数据。在许多情况下,这种监测设备被用于偏远的地方,在那里,任何类型的固定电话、有线连接或无线电传输连接都很难或不可能建立。当时,这种情况下唯一的选择是卫星通信,这种通信非常昂贵,而且根据使用数据的多少来计费。由于现场有数以千计的传感器,行业需要一种通信形式,能够提供足够可靠的数据使用,同时使用最少的带宽。
2013年,MQTT在结构化信息标准推进组织(OASIS)下被标准化为开源。OASIS仍然管理着MQTT标准。
MQTT架构
MQTT运行在TCP/IP之上,采用PUSH/SUBSCRIBE拓扑结构。在MQTT架构中,有两种类型的系统:客户端和代理。代理就是服务器,用于客户端通信。代理接收来自客户端的通信并将这些通信发送给其他客户端。客户端之间不直接通信,而是连接到代理。每个客户端可以是发布者,也可以是订阅者,或者两者都是。
MQTT是一个事件驱动的协议。没有周期性或持续的数据传输。这使传输保持在最低限度。客户端只有在有信息要发送时才会发布,而代理只有在新数据到达时才会向订阅者发送信息。
与HTTP协议的对比
HTTP | MQTT | |
设计方向 | 以文档为中心 | 以数据为中心 |
形式 | 请求/响应 | 发布/订阅 |
传输层协议 | TCP/IP | TCP/IP |
安全机制 | HTTPS | TLS |
复杂度 | 相对复杂 | 简单 |
消息大小 | 大,基于文本描述了内容 | 小,压缩的头信息只占2比特 |
服务等级 | 不区分,所有消息相同 | 3种服务传输等级 |
数据发布 | 1对1 | 1对0,1对1,1对多 |
性能对比
MQTT以物联网场景的数据传输方面对比HTTP有明显的优势,以下实验数据供参考(Power Profiling: HTTPS Long Polling vs. MQTT with SSL, on Android):
每小时耗电量 | 每小时消息量 | 消息传达 | |
3G环境 | |||
HTTPS | 18.43% | 1708 | 240/1024 |
MQTT | 16.13% | 160278 | 1024/1024 |
WIFI | |||
HTTPS | 3.45% | 2628 | 524/1024 |
MQTT | 4.23% | 263314 | 1024/1024 |
另外参考以下实验:MQTT VS HTTPS PERFORMANCE ON AWS IOT CORE。MQTT的性能优势,只有大量连续数据时才可以体现(比如多个仪表数据的连续传递)。
尺寸(Bytes) | 发送时间(ms) | |
2B大小的消息发送1次 | ||
MQTT Q0 | 10476 | 143.677 |
HTTP | 9616 | 87.461 |
10B大小的消息发送10次 | ||
MQTT Q0 | 14605 | 142.41 |
HTTP | 99000 | 785.981 |
50B大小的消息发送10次 | ||
MQTT Q0 | 28957 | 170.552 |
HTTP | 113130 | 1008.473 |
安全机制
MQTT协议的最初目标是在昂贵的、不可靠的通信线路上尽可能地实现最小和最有效的数据传输。因此,在MQTT的设计和实施过程中,安全性并不是首要考虑的问题。
当然,有一些安全选项可供选择,但代价是更多的数据传输量和消耗。
- 网络安全–如果网络本身够安全,那MQTT数据的传输安全性就不这么重要了。网络内部不会有不安全行为,除非是不良行为者或其他网络渗透。
- 用户名和密码–MQTT确实允许客户与代理建立连接时使用用户名和密码。不幸的是,用户名和密码是以明文形式传输的。在1999年,这已经绰绰有余,因为拦截卫星通信基本上是一个不重要的传感器读数将是非常困难的。然而,今天,拦截各类无线网络通信都不难,这使得这种认证完全没有用处。 许多用例需要用户名和密码,不是为了防止恶意行为者,而是为了避免无意的连接。
- SSL/TLS – 既然运行在TCP/IP之上,通过SSL/TLS的自然是一种可行的方案。但不幸的是,这会给原本轻量级的通信增加了大量的开销。
MQTT v5.0标准更新
2019年4月3日,OASIS发布了MQTT v5.0官方标准。
MQTT v5.0的新增以下以主要功能。
- 原因代码 — — 最初,如果发生故障,MQTT根本不采取任何行动。失败本身是唯一的错误代码。在5.0版本中,确认现在支持使用返回原因代码,它可以为失败提供一个用户看的懂的原因。当然,使用返回代码会略微增加占用空间。
- 共享订阅–代理上某个特定主题的订阅者太多,会造成负载问题。共享订阅允许在客户端之间平衡负载。
- 消息过期 – 如果消息在设定的时间内没有传递,可以设置为删除。这可以防止旧的、过期的消息被发送给在一段时间内断开连接的订户。
- 主题别名–主题本身的名称可能会变得太长,以至于损害协议的小足迹。现在,当重复使用相同的主题时,主题字符串可以用一个数字代替。
Pingback: MQTT协议的消息传递可靠性和持续性 – 数字基座