mqtt物联网协议哪一个好（想入行物联网XMPPMQTTCoAP等物联网协议不可不知）

mqtt物联网协议哪一个好（想入行物联网XMPPMQTTCoAP等物联网协议不可不知）·发布者与订阅者不必了解彼此，只要认识同一个消息代理即可。熟悉编程的同学一定非常熟悉这种设计模式了，因为它带来了这些好处：XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。发布/订阅模式与请求/回答这种同步模式不同，发布/订阅模式解耦了发布消息的客户（发布者）与订阅消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联系。打个比方，你打电话给朋友，一直要等到朋友接电话了才能够开始交流，是一个典型的同步请求/回答的场景；而给一个好友邮件列表发电子邮件就不一样，你发好电子邮件该干嘛干嘛，好友们到有空了去查看邮件就

有关物联网协议，现在主要有XMPP、MQTT、CoAP、RESTful HTTP这四种，想了解物联网、进入这行业的必须了解一下，全解且看下文吧。

国外有关四大协议比较

协议一：物联网协议XMPP

XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过 扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程 序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。

基本网络结构

XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。

发布/订阅模式

与请求/回答这种同步模式不同，发布/订阅模式解耦了发布消息的客户（发布者）与订阅消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联系。打个比方，你打电话给朋友，一直要等到朋友接电话了才能够开始交流，是一个典型的同步请求/回答的场景；而给一个好友邮件列表发电子邮件就不一样，你发好电子邮件该干嘛干嘛，好友们到有空了去查看邮件就是了，是一个典型的异步发布/订阅的场景。

熟悉编程的同学一定非常熟悉这种设计模式了，因为它带来了这些好处：

·发布者与订阅者不必了解彼此，只要认识同一个消息代理即可。

·发布者和订阅者不需要交互，发布者无需等待订阅者确认而导致锁定。

·发布者和订阅者不需要同时在线，可以自由选择时间来消费消息。

主题

MQTT是通过主题对消息进行分类的，本质上就是一个UTF-8的字符串，不过可以通过反斜杠表示多个层级关系。主题并不需要创建，直接使用就是了。

主题还可以通过通配符进行过滤。其中， 可以过滤一个层级，而#只能出现在主题最后表示过滤任意级别的层级。

举个例子：

·building-b/floor-5：代表B楼5层的设备。

· /floor-5：代表任何一个楼的5层的设备。

·building-b/#：代表B楼所有的设备。

注意，MQTT允许使用通配符订阅主题，但是并不允许使用通配符广播。

服务质量

为了满足不同的场景，MQTT支持三种不同级别的服务质量（Quality of Service，QoS）为不同场景提供消息可靠性：

·级别0：尽力而为。消息发送者会想尽办法发送消息，但是遇到意外并不会重试。

·级别1：至少一次。消息接收者如果没有知会或者知会本身丢失，消息发送者会再次发送以保证消息接收者至少会收到一次，当然可能造成重复消息。

·级别2：恰好一次。保证这种语义肯定会减少并发或者增加延时，不过丢失或者重复消息是不可接受的时候，级别2是最合适的。

服务质量是个老话题了。级别2所提供的不重不丢很多情况下是最理想的，不过往返多次的确认一定对并发和延迟带来影响。级别1提供的至少一次语义在日志处理这种场景下是完全OK的，所以像Kafka这类的系统利用这一特点减少确认从而大大提高了并发。级别0适合鸡肋数据场景，食之无味弃之可惜，就这么着吧。

消息类型

MQTT拥有14种不同的消息类型：

1.CONNECT：客户端连接到MQTT代理

2.CONNACK：连接确认

3.PUBLISH：新发布消息

4.PUBACK：新发布消息确认，是QoS 1给PUBLISH消息的回复

5.PUBREC：QoS 2消息流的第一部分，表示消息发布已记录

6.PUBREL：QoS 2消息流的第二部分，表示消息发布已释放

7.PUBCOMP：QoS 2消息流的第三部分，表示消息发布完成

8.SUBSCRIBE：客户端订阅某个主题

9.SUBACK：对于SUBSCRIBE消息的确认

10. UNSUBSCRIBE：客户端终止订阅的消息

11. UNSUBACK：对于UNSUBSCRIBE消息的确认

12. PINGREQ：心跳

13. PINGRESP：确认心跳

14. DISCONNECT：客户端终止连接前优雅地通知MQTT代理

从现有的移动端（Android）消息推送方案中，也可以看出MQTT协议和XMPP协议的优缺点

方案1、 使用GCM服务（Google Cloud Messaging）

简介：Google推出的云消息服务，即第二代的G2DM。

优点：Google提供的服务、原生、简单，无需实现和部署服务端。

缺点：Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。

方案2、 使用XMPP协议（Openfire Spark Smack）

简介：基于XML协议的通讯协议，前身是Jabber，目前已由IETF国际标准化组织完成了标准化工作。

优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。

缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。

方案3、 使用MQTT协议

简介：轻量级的、基于代理的“发布/订阅”模式的消息传输协议。

优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域，且已有C 版的服务端组件rsmb。

缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。

方案4、 使用HTTP轮循方式

简介：定时向HTTP服务端接口（Web Service API）获取最新消息。

优点：实现简单、可控性强，部署硬件成本低。

缺点：实时性差。

协议三：物联网协议CoAP

CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。在最近几年的时间中，专家们预测会有更多的设备相互连接，而这些设备的数量将远超人类的数量。在这种大背景下，物联网和 M2M技术应运而生。虽然对人而言，连接入互联网显得方便容易，但是对于那些微型设备而言接入互联网非常困难。在当前由PC机组成的世界，信息交换是通过 TCP和应用层协议HTTP实现的。但是对于小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网，CoAP协议被 设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常的小巧，最小的数据包仅为4字节。

由于物联网中的很多设备都是资源受限型的，即只有少量的内存空间和有限的计算能力，所以传统的HTTP协议应用在物联网上就显得过于庞大而不适用。 IETF的CoRE工作组提出了一种基于REST架构的CoAP协议。CoAP是6LowPAN协议栈中的应用层协议。该文在详细介绍了CoAP协议的内容、特点和交互模型后，在uIPv6 START KIT无线网络开发套件上，使用Contiki嵌入式操作系统，不仅在浏览器端实现了CoAP协议而且用自己编写的客户端程序实现了CoAP协议，增加了和数据库之间的交互功能，从而实现了在Web界面上不仅可以查看实时数据，还可以查看历史数据的功能。

CoAP应用

由于无线物联网中的设备很多都是资源受限型的，这些设备只有少量的内存空间和有限的计算能力。为此，IETF（Intemet Engineering Task Force）的CoRE（Constrained RESTful Environment）工作组为受限节点制定相关的REST（Representational State Transfer）形式的应用层协议。这就是CoRE工作组正在制订的CoAP（Constrained Application Protocol）协议。

协议四：物联网协议RESTful HTTP

REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点 重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。

RESTful的关键是定义可表示流程元素/资源的对象。在REST中，每一个对象都是通过URL来表示的，对象用户负责将状态信息打包进每一条消息内，以便对象的处理总是无状态的。

RESTful的第二大问题是组合管理及流程绑定。企业对正规的（基于SOAP）SOA最大的反对声之一便是，这种等级的发现和绑定灵活性不足以适应复杂性。

协议：其他

MQTT协议是IBM公司主推的协议，现有的情况下，MQTT比起XMPP和RESTful比较有优势。如果我们对上面的结果进行一次PK，我想最 后的结果就是MQTT vs CoAP。HTTP对于嵌入式设备来说太重了，也不灵活，XMPP就更不用说了，与MQTT还有一比的便是CoAP——一个还在草稿阶段的协议。