MQTT介绍及与其他协议的比较

短命女 2022-10-14 14:57 447阅读 0赞

**MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）**

一种针对移动终端设备的基于TCP/IP的发布/订阅协议，可以连接大量的远程传感器和控制设备。

MQTT的特点是可以保持长连接，具有一定的实时性，要保持长连接，那么就要不时地发送心跳包，这就不会省电。

**特点：**

使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合

有三种消息发布服务质量(QoS)：

>  *  “至多一次”，消息发布完全依赖底层 TCP/IP 网络，会发生消息丢失或重复，这一级别可用于对采集数据要求不严格的情况
>  *  “至少一次”，确保消息到达，但消息可能会重复发生
>  *  “只有一次”，确保消息只到达一次，这一级别可用于要求严格如涉及计费系统的情况，消息重复或丢失都是不允许的

**MQTT中有3个角色：**

>  *  发布者Publisher
>  *  订阅者Subscriber
>  *  代理Broker

MQTT这种结构替代了传统的客户端/服务器模型，可以实现以下解耦：

>  *  空间解耦，发布者和订阅者不需要知道对方
>  *  时间解耦，发布者和订阅者不需要同时运行（离线消息）
>  *  同步解耦，发布和接收都是异步通讯，无需停止任何处理

**MQTT协议的中心是MQTT服务器或代理 (broker)：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE5NzM0NTk3_size_16_color_FFFFFF_t_70][]

**MQTT与其他协议**

目前各大平台都开始支持MQTT协议，MQTT相比其他协议有什么优势呢？物联网设备能不能用其他的协议呢？下面是MQTT与其他部分协议的比较，给大家作为参考。

**MQTT与TCP Socket**

虽然MQTT运行于TCP层之上，看起来这两者之间根本没有比较性，但笔者觉得还是有必要叙述一番，因为大多数从事硬件或嵌入式开发的工程师，都是直接在TCP层上通信的。从事嵌入式开发工作的人都应该知道LwIP，LwIP是一套用于嵌入式系统的开放源代码TCP/IP协议栈，LwIP在保证嵌入式产品拥有完整的TCP/IP功能的同时，又能保证协议栈对处理器资源的有限消耗，其运行一般仅需要几十KB的RAM和40KB左右的ROM。

也就是说，只要是嵌入式产品使用了LwIP，就支持TCP/IP协议栈，进而可以使用MQTT协议。

由于TCP协议有粘包和分包问题，所以传输数据时需要自定义协议，如果传输的数据报超过MSS（最大报文段长度），一定要给协议定义一个消息长度字段，确保接收端能通过缓冲完整收取消息。一个简单的协议定义：消息头部+消息长度+消息正文。

当然，使用MQTT协议则不需要考虑这个问题，这些MQTT都已经处理好了，MQTT最长可以一次性发送256MB数据，不用考虑粘包分包的问题。

总之，TCP和MQTT本身并不矛盾，只不过基于Socket开发需要处理更多的事情，而且大多数嵌入式开发模块本身也只会提供Socket接口供厂家自定义协议。

**MQTT与HTTP**

HTTP最初的目的是提供一种发布和接收HTML页面的方法，主要用于Web。HTTP是典型的C/S通讯模式：请求从客户端发出，服务端只能被动接收，一条连接只能发送一次请求，获取响应后就断开连接。该协议最早是为了适用Web浏览器的上网浏览场景而设计的，目前在PC、手机、Pad等终端上都应用广泛。由于这样的通信特点，HTTP技术在物联网设备中很难实现设备的反向控制，不过非要实现也不是不行，下面看一下Web端的例子。

目前，在微博等SNS网站上有海量用户公开发布的内容，当发布者发布消息，数据传到服务器更新时，就需要给关注者尽可能的实时更新内容。Web网站基于HTTP协议，使用HTTP协议探测服务器上是否有内容更新，就必须频繁地让客户端请求服务器进行确认。在浏览器中要实现这种效果，可以使用Comet技术，Comet是基于HTTP长连接的“服务器推”技术，主要有两种实现模型：基于AJAX的长轮询（long-polling）方式和基于Iframe及htmlfile的流（streaming）方式。这两种技术模型在这里不详细展开，有兴趣的读者可以查阅相关资料。

如果要实现设备的反向控制，可能就要用到前面提到的Comet技术。由于需要不断的请求服务器，会导致通信开销非常大，加上HTTP冗长的报文头，在节省流量上实在没有优势。

当然，如果只是单纯地让设备定时上报数据而不做控制，也是可以使用HTTP协议的。

**MQTT与XMPP**

最有可能与MQTT竞争的是XMPP协议。XMPP（可扩展通讯与表示协议）是一项用于实时通讯的开放技术，它使用可扩展标记语言（XML）作为交换信息的基本格式。其优点是协议成熟、强大、可扩展性强。目前主要应用于许多聊天系统中，在消息推送领域，MQTT和XMPP互相竞争。下面列举MQTT与XMPP各自的特性：

XMPP协议基于繁重的XML，报文体积大且交互繁琐；而MQTT协议固定报头只有两个字节，报文体积小、编解码容易；

XMPP基于JID的点对点消息传输；MQTT协议基于主题(Topic)发布\\订阅模式，消息路由更为灵活；

XMPP协议采用XML承载报文，二进制必须进行Base64编码或其他方式处理；MQTT协议未定义报文内容格式，可以承载JSON、二进制等不同类型报文，开发者可以针对性的定义报文格式；

MQTT协议支持消息收发确认和QoS保证，有更好的消息可靠性保证；而XMPP主协议并未定义类似机制；

在嵌入式设备开发中大多使用的是C语言开发，C语言解析XML是非常困难的。MQTT基于二进制实现且未定义报文内容格式，可以很好的兼顾嵌入式C语言开发者；而XMPP基于XML，开发者需要配合协议格式，不能灵活开发。

综上所述，在嵌入式设备中，由于需要一个灵巧简洁，对设备开发者和服务端开发者都友好的协议，MQTT比XMPP更具有优势。

**MQTT与CoAP**

CoAP也是一个能与MQTT竞争的协议。其模仿HTTP的REST模型，服务端以URI方式创建资源，客户端可以通过GET、PUT、POST、DELETE方式访问这些资源，并且协议风格也和HTTP极为相似，例如一个设备有温度数据，那么这个温度可以被描述为：

CoAP://:/sensors/temperature 其中为设备的IP，为端口。

不过，如果使用CoAP可能会让物联网后台的情况变得复杂，比如MQTT可以实现一个最简单的IoT架构：Device + MQTT服务器 + APP，手机端或Web端可以直接从MQTT服务器订阅想要的主题。而CoAP可能需要这样的架构：CoAP + Web + DataBase + App，使用CoAP必须经过DataBase才能转给第三方。

至于CoAP和MQTT孰优孰劣，这里不作定论。不过目前来说，CoAP资料还是略少。而且，MQTT除了可以应用于物联网领域，在手机消息推送、在线聊天等领域都可以有所作为。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE5NzM0NTk3_size_16_color_FFFFFF_t_70]: /images/20221014/5037f074e1bc4ae8a0c71e42c62422ad.png