物联网四大协议.docx

物联网四大协议物联网协议ProtocolTra nsportXMPPTCPMQTTTCPCoAPUDPRESTful HTTPTCPPublish/Publish/Messagi ngSubscribeRequest/SubscribeRequest/Request/ ResponseRequest/ ResponseResponseResponse2G, 3G, 4GSuitability(1000s nodes)Excelle ntExcelle ntExcelle ntExcelle ntLLN Suitability (1000s nodes)FairFairExcelle ntFairComputeResources10Ks RAM/Flash10Ks RAM/Flash10Ks RAM/Flash10Ks RAM/FlashSuccessStoriedRemote man ageme nt of con sumer white goodsExte nding en terprise messagi ng into IoT applicati onsUtility Field AreaNetworksSmart En ergyProfile 2 (premise en ergy man ageme nt/ home services)协议一：物联网协议XMPPXMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的 发展性。

因此，基于XMPP的应用具有超强的可扩展性经过扩展以后的XMPP可以通 过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地 址的服务等应用程序而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进 行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能基本网络结构XMPP中定义了三个角色，客户端，服务器，网关通信能够在这三者的任意两个之间双 向发生服务器同时承担了客户端信息记录，连接管理和信息的路由功能网关承担着与 异构即时通信系统的互联互通，异构系统可以包括SMS （短信），MSN，ICQ等基本 的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XMLXMPP核心协议通信的基本模式就是先建立一个stream，然后协商一堆安全之类的东 西，中间通信过程就是客户端发送XML Stanza，一个接一个的服务器根据客户端发送 的信息以及程序的逻辑，发送XML Stanza给客户端但是这个过程并不是一问一答 的，任何时候都有可能从一方发信给另外一方通信的最后阶段是关闭流，关闭TCP/IP 连接XMPPBSS 器John.jid 二[rtodfi ] domaiin [:用户舍reitciurca ]威功后e I ifttrfel和歆krrtZ迴行理互容户端2功能传输的是与即时通讯相关的指令。

在以前这些命令要么用2进制的形式发送（比如 ）,要么用纯文本指令加空格加参数加换行符的方式发送（比如MSN）而XMPP传 输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了 XML格式的纯文本优点XMPP协议是自由、开放、公开的，并且易于了解而且在客户端、服务器、组件、源码 库等方面，都已经各自有多种实现缺点网络通信过程中数据冗余率非常高，网络流量中70%都消耗在XMPP协议层了对于 物联网来说，大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备， 省电、省流量是所有底层服务的一个关键技术指标，XMPP协议看起来已经落后了协议二：物联网协议MQTTMQTT （ Message Queuing Telemetry Transport，消息队列遥测传输）是 IBM 开发的一个 即时通讯协议，有可能成为物联网的重要组成部分该协议支持所有平台，几乎可以把所 有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联 网）的通信协议MQTT简介MQTT是基于二进制消息的发布/订阅编程模式的消息协议，最早由IBM提出的，如今已经成为OASIS规范景，比如：由于规范很简单，非常适合需要低功耗和网络带宽有限的IoT场•遥感数据 汽车•智能家居 •智慧城市 ■医疗医护由于物联网的环境是非常特别的，所以MQTT遵循以下设计原则:1■精简，不添加可有可无的功能。

2■发布/订阅（Pub/Sub ）模式，方便消息在传感器之间传递3■允许用户动态创建主题，零运维成本4■把传输量降到最低以提高传输效率5■把低带宽、高延迟、不稳定的网络等因素考虑在内6■支持连续的会话控制7■理解客户端计算能力可能很低8■提供服务质量管理9■假设数据不可知，不强求传输数据的类型与格式，保持灵活性运用 MQTT协议，设备可以很方便地连接到物联网云服务，管理设备并处理数据，最后 应用到各种业务场景，如下图所示：MQTT决立设毎低功輕设番 —IMQTT智険网关］* *低功耗设富 —I发布/订阅模式与请求/回答这种同步模式不同，发布/订阅模式解耦了发布消息的客户（发布者）与订阅 消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联 系打个比方，你打给朋友，一直要等到朋友接了才能够开始交流，是一个典型 的同步请求/回答的场景；而给一个好友邮件列表发电子邮件就不一样，你发好电子邮件 该干嘛干嘛，好友们到有空了去查看邮件就是了，是一个典型的异步发布/订阅的场景 熟悉编程的同学一定非常熟悉这种设计模式了，因为它带来了这些好处：•发布者与订阅者不必了解彼此，只要认识同一个消息代理即可。

•发布者和订阅者不需要交互，发布者无需等待订阅者确认而导致锁定•发布者和订阅者不需要同时，可以自由选择时间来消费消息主题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提供的服务、原生、简单，无需实现和部署服务端缺点：An droid版本限制(必须大于2.2版本)，该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google方案 2、使用 XMPP 协议(Openfire + Spark + Smack)简介：基于XML协议的通讯协议，前身是Jabber，目前已由IETF国际标准化组织完成 了标准化工作优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例an droidp n缺点：协议较复杂、冗余(基于XML )、费流量、费电，部署硬件成本高方案3、使用MQTT协议简介：轻量级的、基于代理的''发布/订阅〃模式的消息传输协议优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域，且已有C++版的服务端组件rsmb缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高 方案4、使用HTTP轮循方式简介：定时向HTTP服务端接口( Web Service API)获取最新消息优点：实现简单、可控性强，部署硬件成本低缺点：实时性差协议三：物联网协议CoAP由于物联网中的很多设备都是资源受限型的，即只有少量的内存空间和有限的计算能力， 所以传统的HTTP协议应用在物联网上就显得过于庞大而不适用。

IETF的CORE工作组 提出了一种基于REST架构的CoAP协议CoAP是受限制的应用协议(Constrained Application Protocol)的代名词由于目前物联网中的很多设备都是资源受限型的，所 以只有少量的内存空间和有限的计算能力，传统的HTTP协议在物联网应用中就会显得 过于庞大而不适用因此，IETF的CoRE工作组提出了一种基于REST架构、传输层为 UDP、网络层为6LowPAN (面向低功耗无线局域网的IPv6 )的CoAP协议CoAP应用CoAP采用与HTTP协议相同的请求响应工作模式CoAP协议共有4中不同的消息类 型CON 需要被确认的请求，如果CON请求被发送，那么对方必须做出响应NON 不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应ACK——应答消息，接受到CON消息的响应RST――复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发 送的内容，那么复位消息将会被发送CoAP消息格式使用简单的二进制格式，最小为4个字节—个消息二固定长度的头部header +可选个数的option +负载payload。