手机网站淘宝客,网站新闻审核怎么做,网页设计入门图片,大企业网站建设多少钱MQTT是什么#xff1f;
MQTT#xff08;Message Queuing Telemetry Transport#xff0c;消息队列遥测传输协议#xff09;#xff0c;是一种基于发布/订阅#xff08;Publish/Subscribe#xff09;模式的轻量级通讯协议#xff0c;该协议构建于TCP/IP协议上#xff…MQTT是什么
MQTTMessage Queuing Telemetry Transport消息队列遥测传输协议是一种基于发布/订阅Publish/Subscribe模式的轻量级通讯协议该协议构建于TCP/IP协议上由IBM在1999年发布目前最新版本为v3.1.1。MQTT最大的优点在于可以以极少的代码和有限的带宽为远程设备提供实时可靠的消息服务。做为一种低开销、低带宽占用的即时通讯协议MQTT在物联网、小型设备、移动应用等方面有广泛的应用。
当然在物联网开发中MQTT不是唯一的选择与MQTT互相竞争的协议有XMPP和CoAP协议等文章末尾会有一个比较和说明。
MQTT是哪一层的协议
众所周知TCP/IP参考模型可以分为四层应用层、传输层、网络层、链路层。TCP和UDP位于传输层应用层常见的协议有HTTP、FTP、SSH等。MQTT协议运行于TCP之上属于应用层协议因此只要是支持TCP/IP协议栈的地方都可以使用MQTT。
MQTT消息格式
每条MQTT命令消息的消息头都包含一个固定的报头有些消息会携带一个可变报文头和一个负荷。消息格式如下 固定报文头 | 可变报文头 | 负荷 固定报文头Fixed Header
MQTT固定报文头最少有两个字节第一字节包含消息类型Message Type和QoS级别等标志位。第二字节开始是剩余长度字段该长度是后面的可变报文头加消息负载的总长度该字段最多允许四个字节。
剩余长度字段单个字节最大值为二进制0b0111 111116进制0x7F。也就是说单个字节可以描述的最大长度是127字节。为什么不是256字节呢因为MQTT协议规定单个字节第八位最高位若为1则表示后续还有字节存在第八位起“延续位”的作用。
例如数字64编码为一个字节十进制表示为64十六进制表示为0×40。数字321652*128编码为两个字节重要性最低的放在前面第一个字节为651281930xC1第二个字节是20x02表示2×128。
由于MQTT协议最多只允许使用四个字节表示剩余长度如表1并且最后一字节最大值只能是0x7F不能是0xFF所以能发送的最大消息长度是256MB而不是512MB。 表1
可变报文头Variable Header
可变报文头主要包含协议名、协议版本、连接标志Connect Flags、心跳间隔时间Keep Alive timer、连接返回码Connect Return Code、主题名Topic Name等后面会针对主要部分进行讲解。
有效负荷Payload
Payload直译为负荷可能让人摸不着头脑实际上可以理解为消息主体body。
当MQTT发送的消息类型是CONNECT连接、PUBLISH发布、SUBSCRIBE订阅、SUBACK订阅确认、UNSUBSCRIBE取消订阅时则会带有负荷。
MQTT的主要特性
MQTT的消息类型Message Type
固定报文头中的第一个字节包含连接标志Connect Flags连接标志用来区分MQTT的消息类型。MQTT协议拥有14种不同的消息类型如表2可简单分为连接及终止、发布和订阅、QoS 2消息的机制以及各种确认ACK。至于每一个消息类型会携带什么内容这里不多阐述。 表2
消息质量QoS
MQTT消息质量有三个等级QoS 0QoS 1和 QoS 2。
QoS 0最多分发一次。消息的传递完全依赖底层的TCP/IP网络协议里没有定义应答和重试消息要么只会到达服务端一次要么根本没有到达。QoS 1至少分发一次。服务器的消息接收由PUBACK消息进行确认如果通信链路或发送设备异常或者指定时间内没有收到确认消息发送端会重发这条在消息头中设置了DUP位的消息。QoS 2只分发一次。这是最高级别的消息传递消息丢失和重复都是不可接受的使用这个服务质量等级会有额外的开销。 通过下面的例子可以更深刻的理解上面三个传输质量等级。
比如目前流行的共享单车智能锁智能锁可以定时使用QoS level 0质量消息请求服务器发送单车的当前位置如果服务器没收到也没关系反正过一段时间又会再发送一次。之后用户可以通过App查询周围单车位置找到单车后需要进行解锁这时候可以使用QoS level 1质量消息手机App不断的发送解锁消息给单车锁确保有一次消息能达到以解锁单车。最后用户用完单车后需要提交付款表单可以使用QoS level 2质量消息这样确保只传递一次数据否则用户就会多付钱了。
遗愿标志Will Flag
在可变报文头的连接标志位字段Connect Flags里有三个Will标志位Will Flag、Will QoS和Will Retain Flag这些Will字段用于监控客户端与服务器之间的连接状况。如果设置了Will Flag就必须设置Will QoS和Will Retain标志位消息主体中也必须有Will Topic和Will Message字段。
那遗愿消息是怎么回事呢服务器与客户端通信时当遇到异常或客户端心跳超时的情况MQTT服务器会替客户端发布一个Will消息。当然如果服务器收到来自客户端的DISCONNECT消息则不会触发Will消息的发送。 因此Will字段可以应用于设备掉线后需要通知用户的场景。
连接保活心跳机制Keep Alive Timer
MQTT客户端可以设置一个心跳间隔时间Keep Alive Timer表示在每个心跳间隔时间内发送一条消息。如果在这个时间周期内没有业务数据相关的消息客户端会发一个PINGREQ消息相应的服务器会返回一个PINGRESP消息进行确认。如果服务器在一个半1.5心跳间隔时间周期内没有收到来自客户端的消息就会断开与客户端的连接。心跳间隔时间最大值大约可以设置为18个小时0值意味着客户端不断开。
MQTT其他特点
异步发布/订阅实现
发布/订阅模式解耦了发布消息的客户发布者与订阅消息的客户订阅者之间的关系这意味着发布者和订阅者之间并不需要直接建立联系。 这个模式有以下好处
发布者与订阅者只需要知道同一个消息代理即可发布者和订阅者不需要直接交互发布者和订阅者不需要同时在线。
由于采用了发布/订阅实现MQTT可以双向通信。也就是说MQTT支持服务端反向控制设备设备可以订阅某个主题然后发布者对该主题发布消息设备收到消息后即可进行一系列操作。
二进制格式实现
MQTT基于二进制实现而不是字符串比如HTTP和XMPP都是基于字符串实现。由于HTTP和XMPP拥有冗长的协议头部而MQTT固定报文头仅有两字节所以相比其他协议发送一条消息最省流量。
MQTT的安全
由于MQTT运行于TCP层之上并以明文方式传输这就相当于HTTP的明文传输使用Wireshark可以完全看到MQTT发送的所有消息消息指令一览无遗如图1所示。 图1 Wireshark抓取MQTT数据包
这样可能会产生以下风险
设备可能会被盗用客户端和服务端的静态数据可能是可访问的可能会被修改协议行为可能有副作用如计时器攻击拒绝服务攻击通信可能会被拦截、修改、重定向或者泄露虚假控制报文注入。
作为传输协议MQTT仅关注消息传输提供合适的安全功能是开发者的责任。安全功能可以从三个层次来考虑——应用层、传输层、网络层。
应用层在应用层上MQTT提供了客户标识Client Identifier以及用户名和密码可以在应用层验证设备。传输层类似于HTTPSMQTT基于TCP连接也可以加上一层TLS传输层使用TLS加密是确保安全的一个好手段可以防止中间人攻击。客户端证书不但可以作为设备的身份凭证还可以用来验证设备。网络层如果有条件的话可以通过拉专线或者使用VPN来连接设备与MQTT代理以提高网络传输的安全性。
认证
MQTT支持两种层次的认证
应用层MQTT支持客户标识、用户名和密码认证传输层传输层可以使用TLS除了加密通讯还可以使用X509证书来认证设备。
客户标识
MQTT客户端可以发送最多65535个字符作为客户标识Client Identifier一般来说可以使用嵌入式芯片的MAC地址或者芯片序列号。虽然使用客户标识来认证可能不可靠但是在某些封闭环境或许已经足够了。
用户名和密码
MQTT协议支持通过CONNECT消息的username和password字段发送用户名和密码。
用户名及密码的认证使用起来非常方便不过由于它们是以明文形式传输所以使用抓包工具就可以轻易的获取。
一般来说使用客户标识、用户名和密码已经足够了比如支持MQTT协议连接的OneNET云平台就是使用了这三个字段作为认证。如果感觉还不够安全还可以在传输层进行认证。
在传输层认证
在传输层认证是这样的MQTT代理在TLS握手成功之后可以继续发送客户端的X509证书来认证设备如果设备不合法便可以中断连接。使用X509认证的好处是在传输层就可以验证设备的合法性在发送CONNECT消息之前便可以阻隔非法设备的连接以节省后续不必要的资源浪费。而且MQTT协议运行在使用TLS时除了提供身份认证还可以确保消息的完整性和保密性。
选择用户数据格式
MQTT协议只实现了传送消息的格式并没有限制用户协议需要按照一定的风格因此在MQTT协议之上我们需要定义一套自己的通信协议。比如说发布者向设备发布一条打开消息设备可以回复一个消息并携带返回码这样的消息格式是使用二进制、字符串还是JSON格式呢下面就简单做个选型参考。
十六进制/二进制
MQTT原本就是基于二进制实现的所以用户协议使用二进制实现是一个不错的选择。虽然失去了直观的可读性但可以将流量控制在非常小。其实对于单片机开发者来说十六进制并不陌生因为单片机寄存器都是以位来操作的芯片间通信也会使用十六进制/二进制。而对于没有单片机开发经验的工程师来说十六进制/二进制可能就太原始了。下面我们继续看看还有没有其他方案。
字符串
对单片机开发者来说字符串也是一个选择。比如通过串口传输的AT指令就是基于字符串通信的。使用字符串方便了人阅读但是对高级语言开发者来说字符串依旧不是最佳选择恐怕键值对Key-Value才是最优形式。
JSON
JSON中文全称是JavaScript对象标记语言在这门语言中一切都是对象。因此任何支持的类型都可以通过JSON来表示例如字符串、数字、对象、数组等。其语法规则是
对象表示为键值对数据由逗号分隔花括号保存对象方括号保存数组。
JSON层次结构简洁清晰易于阅读和编写同时也易于机器解析和生成有效提升网络传输效率。
对于单片机开发者主流的微控制器软件开发工具Keil有提供JSON库可以用于STC、STM32等微控制器开发所以在微控制器上解析JSON不需要自己写一个JSON解析器或者移植了。
如果实在懒得使用JSON库生成或解析也可以直接使用C语言中的sprintf生成JSON字符串比如
sprintf(buf, {\String\:\%s\, \Value\:%d}, Hello World!, 12345);这样就可以生成一个{“String”:”Hello World!”, “Value”:12345}JSON字符串了。
XML
MQTT协议只负责通信部分用户协议可以自己选择当然也可以选择复杂又冗长的XML格式。可是既然要选择MQTTXML为什么不考虑换为XMPP呢
小结
综上所述MQTTJSON是目前最优方案。协议简洁清晰、易于阅读、解析和生成等也考虑了服务器端开发者和设备端开发者的开发成本。
有关MQTT的云平台和工具
支持MQTT的云平台
目前百度、阿里、腾讯的云平台都逐渐有了物联网开发套件腾讯QQ物联平台内测中阿里云物联网套件公测中两者都需要进行申请试用而百度云物联网套件已经支持MQTT并且可以免费试用一段时间。除了BAT三大家下面再介绍一些其他支持MQTT的物联网云平台。
OneNET云平台OneNET是由中国移动打造的PaaS物联网开放平台。平台能够帮助开发者轻松实现设备接入与设备连接快速完成产品开发部署为智能硬件、智能家居产品提供完善的物联网解决方案。OneNET云平台已经于2014年10月正式上线。云巴云巴Cloud Bus是一个跨平台的双向实时通信系统为物联网、App和Web提供实时通信服务。云巴基于MQTT支持Socket.IO协议支持RESTful API。
MQTT服务器
如果不想使用云平台只是纯粹地玩一下MQTT或者只想在内网对设备进行监控那么可以自己本地部署一个MQTT服务器。下面介绍几款MQTT服务器
Apache-Apollo一个代理服务器在ActiveMQ基础上发展而来可以支持STOMP、AMQP、MQTT、Openwire、SSL和WebSockets等多种协议并且Apollo提供后台管理页面方便开发者管理和调试。EMQEMQ 2.0号称百万级开源MQTT消息服务器基于Erlang/OTP语言平台开发支持大规模连接和分布式集群发布订阅模式的开源MQTT消息服务器。HiveMQ一个企业级的MQTT代理主要用于企业和新兴的机器到机器M2M通讯和内部传输最大程度的满足可伸缩性、易管理和安全特性提供免费的个人版。HiveMQ提供了开源的插件开发包。Mosquitto一款实现了消息推送协议MQTT v3.1的开源消息代理软件提供轻量级的、支持可发布/可订阅的消息推送模式。
MQTT调试工具
知道了各大平台的MQTT同时自己也可以在内网部署MQTT服务器那接下来没有调试工具怎么行呢难道要用自己喜欢的语言编写一个当然不需要。MQTT调试工具可以考虑使用HiveMQ的MQTT客户端——HiveMQ Websockets Client这是一款基于WebSocket的浏览器MQTT客户端支持主题订阅和发布。
MQTT与其他协议
目前各大平台都开始支持MQTT协议MQTT相比其他协议有什么优势呢物联网设备能不能用其他的协议呢下面是MQTT与其他部分协议的比较给大家作为参考。
MQTT与TCP Socket
虽然MQTT运行于TCP层之上看起来这两者之间根本没有比较性但笔者觉得还是有必要叙述一番因为大多数从事硬件或嵌入式开发的工程师都是直接在TCP层上通信的。从事嵌入式开发工作的人都应该知道LwIPLwIP是一套用于嵌入式系统的开放源代码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除了可以应用于物联网领域在手机消息推送、在线聊天等领域都可以有所作为。
小结
经过以上的比较我们可以得出如下结论MQTT基于异步发布/订阅的实现解耦了消息发布者和订阅者基于二进制的实现节省了存储空间及流量同时MQTT拥有更好的消息处理机制可以替代TCP Socket一部分应用场景。相对于HTTP和XMPPMQTT可以选择用户数据格式解析复杂度低同时MQTT也可用于手机推送等领域。手机作为与人连接的入口正好建立了人与物的连接可谓一箭双雕。当然其他协议也可以作为一个辅助的存在HTTP可以为只需定时上传数据的设备服务CoAP则更适用于非常受限的移动通信网络表3直观地展示了上文提到的几种协议之间的优劣异同。
