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

MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)

一种针对移动终端设备的基于TCP/IP的发布/订阅协议
可以连接大量的远程传感器和控制设备
MQTT的特点是可以保持长连接,具有一定的实时性
要保持长连接,那么就要不时地发送心跳包,这就不会省电

特点:
使用发布/订阅消息模式,提供一对多的消息发布,解除应用程序耦合
有三种消息发布服务质量(QoS):
“至多一次”,消息发布完全依赖底层 TCP/IP 网络,会发生消息丢失或重复,这一级别可用于对采集数据要求不严格的情况
“至少一次”,确保消息到达,但消息可能会重复发生
“只有一次”,确保消息只到达一次,这一级别可用于要求严格如涉及计费系统的情况,消息重复或丢失都是不允许的
MQTT中有3个角色:
发布者Publisher
订阅者Subscriber
代理Broker
MQTT这种结构替代了传统的客户端/服务器模型,可以实现以下解耦:
空间解耦,发布者和订阅者不需要知道对方
时间解耦,发布者和订阅者不需要同时运行(离线消息)
同步解耦,发布和接收都是异步通讯,无需停止任何处理

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

在这里插入图片描述
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除了可以应用于物联网领域,在手机消息推送、在线聊天等领域都可以有所作为。

作者:安现锋
原文链接:https://blog.csdn.net/anxianfeng55555/article/details/80908795

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值