物联网四大协议

物联网四大合同物联网合同ProtocolXMPPMQTTCoAPRESTfulHTTPTransportTCPTCPUDPTCPMessagingPublish/SubscribeRequest/ResponsePublish/SubscribeRequest/ResponseRequest/ResponseRequest/Response2G,3G,4GSuitability(1000snodes)ExcellentExcellentExcellentExcellentLLNSuitability(1000snodes)FairFairExcellentFairComputeResources10KsRAM/Flash10KsRAM/Flash10KsRAM/Flash10KsRAM/FlashSuccessStoriedRemotemanagementofconsumerwhitegoodsExtendingenterprisemessagingintoIoTapplicationsUtilityFieldAreaNetworksSmartEnergyProfile2(premiseenergymanagement/homeservices)

合同一：物联网合同XMPP

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

基本网络构造

XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承当了客户端信息统计，连接管理和信息的路由功效。网关承当着与异构即时通信系统的互联互通，异构系统能够涉及SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。工作原理XMPP核心合同通信的基本模式就是先建立一种stream，然后协商一堆安全之类的东西，中间通信过程就是客户端发送XMLStanza，一种接一种的。服务器根据客户端发送的信息以及程序的逻辑，发送XMLStanza给客户端。但是这个过程并不是一问一答的，任何时候都有可能从一方发信给另外一方。通信的最后阶段是关闭流，关闭TCP/IP连接。

功效

传输的是与即时通讯有关的指令。在以前这些命令要么用2进制的形式发送（例如QQ），要么用纯文本指令加空格加参数加换行符的方式发送（例如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是合同的形式变成了XML格式的纯文本。

优点

XMPP合同是自由、开放、公开的，并且易于理解。并且在客户端、服务器、组件、源码库等方面，都已经各自有多个实现。

缺点

网络通信过程中数据冗余率非常高，网络流量中70%都消耗在XMPP合同层了。对于物联网来说，大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备，省电、省流量是全部底层服务的一种核心技术指标，XMPP合同看起来已经落后了。

合同二：物联网合同MQTT

MQTT（MessageQueuingTelemetryTransport，消息队列遥测传输）是IBM开发的一种即时通讯合同，有可能成为物联网的重要构成部分。该合同支持全部平台，几乎能够把全部联网物品和外部连接起来，被用来当做传感器和致动器（例如通过Twitter让房屋联网）的通信合同。

MQTT介绍

MQTT是基于二进制消息的公布/订阅编程模式的消息合同，最早由IBM提出的，如今已经成为OASIS规范。由于规范很简朴，非常适合需要低功耗和网络带宽有限的IoT场景，例如：

·遥感数据

·汽车

·智能家居

·智慧都市

·医疗医护

由于物联网的环境是非常特别的，因此MQTT遵照下列设计原则：

1.精简，不添加可有可无的功效。

2.公布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。

3.允许顾客动态创立主题，零运维成本。

4.把传输量降到最低以提高传输效率。

5.把低带宽、高延迟、不稳定的网络等因素考虑在内。

6.支持持续的会话控制。

7.理解客户端计算能力可能很低。

8.提供服务质量管理。

9.假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

运用MQTT合同，设备能够很方便地连接到物联网云服务，管理设备并解决数据，最后应用到多个业务场景，以下图所示：

公布/订阅模式

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

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

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

·公布者和订阅者不需要交互，公布者无需等待订阅者确认而造成锁定。

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

主题

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

主题还能够通过通配符进行过滤。其中，+能够过滤一种层级，而#只能出现在主题最后表达过滤任意级别的层级。

举个例子：

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

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

·building-b/#：代表B楼全部的设备。

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

服务质量

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

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

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

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

服务质量是个老话题了。级别2所提供的不重不丢诸多状况下是最抱负的，但是来回多次确实认一定对并发和延迟带来影响。级别1提供的最少一次语义在日志解决这种场景下是完全OK的，因此像Kafka这类的系统运用这一特点减少确认从而大大提高了并发。级别0适合鸡肋数据场景，食之无味弃之可惜，就这样着吧。

消息类型

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

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

2.CONNACK：连接确认

3.PUBLISH：新公布消息

4.PUBACK：新公布消息确认，是QoS1给PUBLISH消息的回复

5.PUBREC：QoS2消息流的第一部分，表达消息公布已统计

6.PUBREL：QoS2消息流的第二部分，表达消息公布已释放

7.PUBCOMP：QoS2消息流的第三部分，表达消息公布完毕

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

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

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

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

12.PINGREQ：心跳

13.PINGRESP：确认心跳

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

从现有的移动端（Android）消息推送方案中，也能够看出MQTT合同和XMPP合同的优缺点

方案1、使用GCM服务（谷歌CloudMessaging）

介绍：谷歌推出的云消息服务，即第二代的G2DM。

优点：谷歌提供的服务、原生、简朴，无需实现和布署服务端。

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

方案2、使用XMPP合同（Openfire+Spark+Smack）

介绍：基于XML合同的通讯合同，前身是Jabber，现在已由IETF国际原则化组织完毕了原则化工作。

优点：合同成熟、强大、可扩展性强、现在重要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。

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

方案3、使用MQTT合同

介绍：轻量级的、基于代理的“公布/订阅”模式的消息传输合同。

优点：合同简洁、小巧、可扩展性强、省流量、省电，现在已经应用到公司领域，且已有C++版的服务端组件rsmb。

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

方案4、使用HTTP轮循方式

介绍：定时向HTTP服务端接口（WebServiceAPI）获取最新消息。

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

缺点：实时性差。

合同三：物联网合同CoAP

由于物联网中的诸多设备都是资源受限型的，即只有少量的内存空间和有限的计算能力，因此传统的HTTP合同应用在物联网上就显得过于庞大而不合用。IETF的CoRE工作组提出了一种基于REST架构的CoAP合同。CoAP是受限制的应用合同(ConstrainedApplicationProtocol)的代名词。由于现在物联网中的诸多设备都是资源受限型的，因此只有少量的内存空间和有限的计算能力，传统的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。Payload的长度根据数据报长度来计算。重要是一对一的合同举个例子：

例如某个设备需要从服务器端查询现在温度信息。请求消息（CON）：GET/temperature,请求内容会被包在CON消息里面响应消息(ACK)：2.05Content“22.5C”，响应内容会被放在ACK消息里面CoAP与MQTT的区别MQTT和CoAP都是行之有效的物联网合同，但两者还是有很大区别的，例如MQTT合同是基于TCP，而CoAP合同是基于UDP。从应用方向来分析，重要区别有下列几点：1、MQTT合同不支持带有类型或者其它协助Clients理解的标签信息，也就是说全部MQTTClients必须要懂得消息格式。而CoAP合同则相反，由于CoAP内置发现支持和内容协商，这样便能允许设备互相窥测以找到数据交换的方式。2、MQTT是长连接而CoAP是无连接。MQTTClients与Broker之间保持TCP长连接，这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话，那就需要采用某些NAT穿透性手段。3、MQTT是多个客户端通过中央代理进行消息传递的多对多合同。它重要通过让客户端公布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相称于消息传递的实时通讯总线。CoAP基本上就是一种在Server和Client之间传递状态信息的单对单合同。

合同四：物联网合同RESTfulHTTP

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

Web应用程序最重要的REST原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到告知。另外，无状态请求能够由任何可用服务器回答，这十分适合云计算之类的环境。客户端能够缓存数据以改善性能。RESTful的核心是定义可表达流程元素/资源的对象。在REST中，每一种对象都是通过URL来表达的，对象顾客负责将状态信息打包进每一条消息内，方便对象的解决总是无状态的。RESTful的第二大问题是组合管理及流程绑定。公司对正规的（基于SOAP）SOA最大的反对声之一便是，这种等级的发现和绑定灵活性局限性以适应复杂性。SoAP合同：SoAP(简朴对象访问合同)是交换数据的一种合同规范，是一种轻量的、简朴的、基