物联网四大协议物联网协议协议一:物联网协议XMPPXMPP是一种基于标准通用标记语言的子集XML的协议,它继承了在XML环境中灵活的发展性。
因此,基于XMPP的应用具有超强的可扩展性。
经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求,以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。
而且,XMPP包含了针对服务器端的软件协议,使之能与另一个进行通话,这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。
基本网络结构XMPP中定义了三个角色,客户端,服务器,网关。
通信能够在这三者的任意两个之间双向发生。
服务器同时承担了客户端信息记录,连接管理和信息的路由功能。
网关承担着与异构即时通信系统的互联互通,异构系统可以包括SMS(短信),MSN,ICQ等。
基本的网络形式是单客户端通过TCP/IP连接到单服务器,然后在之上传输XML。
工作原理XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西,中间通信过程就是客户端发送XML Stanza,一个接一个的。
服务器根据客户端发送的信息以及程序的逻辑,发送XML Stanza给客户端。
但是这个过程并不是一问一答的,任何时候都有可能从一方发信给另外一方。
通信的最后阶段是关闭流,关闭TCP/IP 连接。
功能传输的是与即时通讯相关的指令。
在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行符的方式发送(比如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是通过主题对消息进行分类的,本质上就是一个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由于物联网中的很多设备都是资源受限型的,即只有少量的内存空间和有限的计算能力,所以传统的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。
Payload的长度根据数据报长度来计算。
主要是一对一的协议举个例子:比如某个设备需要从服务器端查询当前温度信息。
请求消息(CON): GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK): 2.05 Content “22.5 C”,响应内容会被放在ACK消息里面CoAP与MQTT的区别MQTT和CoAP都是行之有效的物联网协议,但两者还是有很大区别的,比如MQTT协议是基于TCP,而CoAP协议是基于UDP。
从应用方向来分析,主要区别有以下几点:1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息,也就是说所有MQTT Clients必须要知道消息格式。
而CoAP协议则相反,因为CoAP内置发现支持和内容协商,这样便能允许设备相互窥测以找到数据交换的方式。
2、MQTT是长连接而CoAP是无连接。
MQTT Clients与Broker之间保持TCP长连接,这种情形在NAT环境中也不会产生问题。
如果在NAT环境下使用CoAP的话,那就需要采取一些NAT穿透性手段。