IOT_MQTT_CoAP_XMPP

转自

http://info.3g.qq.com/g/s?aid=tech_ss&id=tech_20150828236800&g_ut=3

http://blog.csdn.net/u013327478/article/details/41841827

http://www.21ic.com/atmel/blog/IoT/2014-11-28/608539.html

实时通信技术作为一项根本性前提，在物联网应用程序的开发工作中扮演着核心角色。想象一下，如果我们能够利用手机与家居环境内的各种小装置进行通信，那么科幻电影中的种种场景将很快变成现实。但如果整个通信过程需要数秒才能完成，那么使用体验无疑会大打折扣。


要说起实时通信技术的发展演变，我们就不能不提即时通讯方案的出现。从历史角度讲，即时通讯产品可以算是最早出现的客户友好型联网实时通信客户端。AOL IM、ICQ以及Jabber正是各类支持实时通信的即时通讯方案中的典型代表。而这一切早在上世纪九十年代就已然出现了。


时至今日，我们开始将着眼点放在开发作用于不同物联网设备之间的通信协议——不过当初构建即时通讯解决方案时积累到的经验仍然适用。目前物联网设备所广泛使用的三大实时协议包括：XMPP、CoAP以及MQTT。有趣的是，其中的XMPP早在Jabber时代就已经作为一套开放即时通讯协议存在了。


XMPP


XMPP的全称为可扩展通讯与表示协议。这项立足于XML的TCP通信协议能够以近实时方式在两个甚至更多联网功能实体之间进行结构化数据交换。XMPP当中的现成功能包括表示信息以及联系人名单维护。尽管这两项功能最初都是针对即时通讯需求设计而成，但它们在物联网应用程序当中仍然能够起到不错的效果。鉴于其出色的开放特性并以XML为基础，XMPP已经被扩展至各类公共订阅系统当中——而这也恰好适合物联网应用的实际需求。


利用XMPP作为物联网通信协议，我们能够享受到几大突出优势。首先就是XMPP的分散特性。XMPP的运作方式与电子邮件比较相似，游走于由传输代理构建而成的分布式网络当中，而非高度依赖于单一中央服务器或者代理节点(CoAP与MQTT皆属于这种情况)。与电子邮件一样，每个人都能够轻松运行属于自己的XMPP服务器，这就使得设备制造商以及API供应方能够创建并管理自己的设备网络体系。而由于大家都有能力运行自己的服务器，所以出于安全考虑，我们可以在必要时利用内置TLS加密机制将该服务器隔离在企业内网的安全验证协议之下。


遗憾的是，XMPP也存在着一些弊端。其最大的问题之一就是缺少端到端加密机制。尽管在不少场景之下，这类加密机制基本算是可有可无，但归根结底大多数物联网设备仍然需要利用加密来保障安全。端到端加密机制的缺失无疑会令物联网设备制造商陷入被动当中。


XMPP的另一个问题在于不具备服务质量(简称QoS)控制。在物联网领域，确保消息交付的重要性甚至比即时通讯领域还要高。如果大家的警报系统没能切实收到相关信息并正确触发，那么接下来的后续影响可能会非常可怕。


CoAP


CoAP的全称为受限应用协议，其开发目的在于允许资源相对有限的设备利用UDP而非TCP通过互联网实现通信。开发人员可以同任意支持CoAP的设备进行交互，具体方式与采用传统REST API的设备完全一致。CoAP的主要适用场景包括低功耗传感器以及需要通过互联网加以控制的设备。


CoAP是一种简单的请求/响应协议(与REST非常相似)，且遵循传统的客户端/服务器模式。客户端可以面向资源发出GET、PUT、POST以及DELETE等请求。CoAP数据包采用位字段以最大限度提升内存利用效率，且经常将字符串映射至整数以降低数据包在设备内部以及网络中传输时所占用的带宽。除了数据包体积极度小巧之外，CoAP的另一大优势在于其采用UDP;数据报文使得CoAP能够在各类基于数据包的技术之上起效——例如短信。


所有CoAP消息皆可被标记为“确认”或者“未确认”，并作为应用层级的QoS机制。尽管SSL/TLS加密无法在UDP之上实现，但CoAP使用数据传输层安全(简称DTLS)作为替代——其可以算是TLS的TCP版本。默认加密级别相当于一条3072位的RSA密钥。尽管包含这些强大的安全保障能力，CoAP仍然能够运行在内存仅为10 KB的微控制器当中。


CoAP的弊端之一在于，它属于一对一协议。尽管我们可以通过扩展方式实现组广播，但这种广播能力并非原生存在。除此之外，CoAP的另一大缺陷在于不提供公共订阅消息队列。


MQTT


MQTT的全称为消息队列遥测传输，这是一种公共订阅消息收发协议。与CoAP类似，它在设计当中同样考虑到运行设备资源有限的状况。MQTT采用轻量级数据包结构设计，旨在最大程度节约内存使用量及运行功耗。联网设备以订阅方式监听托管在MQTT代理端的话题。每一次在其它设备或者服务向该话题发送数据，所有参与订阅的设备都将自动获取到这一更新信息。


MQTT的最大优势在于其公共订阅消息队列机制以及多对多广播能力。有了指向MQTT代理端的长效TCP连接的支持，以有限带宽进行消息收发变得简单而轻松。


MQTT的短板在于，其始终存在的连接限制了设备进入休眠状态的整体时长。如果相关设备在运行中多数处于休眠状态，我们不妨优先选择另一种MQTT协议——MQTT-S，其利用UDP取代原始协议中的TCP。


MQTT的另一大弊端是缺少基础协议层面的加密机制。MQTT被设计为一种轻量化协议，而内置加密的方式会给传输连接增加很大负担。虽然我们也能够在应用程序层级添加定制化安全机制，但这可能需要进行大量的调整工作。


实时协议是物联网的基础


对于每一位有意发挥物联网技术全部固有优势的开发人员来说，了解底层协议都是必不可少的一环。随着这一领域的不断升温，我们在不同设备之间建立高效通信连接时将面临更多技术难题。更重要的是，要想创建出不仅可以与设备交互、更能对其加以控制的API，实时通信的作用可谓不言而喻。当初以帮助人们实现远程通信为目标而诞生的互联网，如今开始衍生出更多更加灵活的使用方式。


作为开发人员，有责任探索所有值得发掘的使用方式。了解各类协议及其优缺点将帮助我们构建起出色的解决方案。不过值得强调的是，将实时通信机制添加到技术堆栈当中也将加快我们的开发流程。目前已经有多种后端即服务平台提供现成的实时通信机制。在大多数情况下，我们都能够利用　　Firebase、Socket.io或者Built.io构建起自己的物联网平台，而且这种方式也能为大家节省下大量开发时间。不过为了尽可能多地收集相关选项并找到最适合当下需求的技术堆栈，我们也有理由对各类现有方案进行深入了解。

MQTT和CoAP都是非常有用的物联网协议，但两者有根本区别，两个协议各有特点，选择哪个才是正确的取决于你的应用程序。

1、MQTT是多个客户端通过一个中央代理传递消息的多对多协议。它通过让客户端发布消息、代理决定消息路由和复制来解耦生产者和消费者。虽然MQTT持久性有一些支持，但它是最好的实时通讯总线。

2、CoAP基本上是一个在Client和Server之间传递状态信息的单对单协议。虽然它支持观察资源，但是CoAP最适合状态转移模型，而不是单纯的基于事件。

3、MQTT Clients与Broker之间保持TCP长连接，这个在NAT环境中也不会有问题。

     CoAP Clients与Server都要接收和发送UDP包。在NAT环境下使用CoAP，需要使用“隧道掘进”或者端口转发(内网穿透)，否则像LWM2M（轻量级M2M）一样，首先初始化设备       到‘头端’( head-end )的连接.

4、MQTT不支持带有类型或者其它帮助Clients理解的标签消息。MQTT消息可用于任意目的，但前提是所有的Clients必须知道消息格式。而CoAP则相反，它内置内容协商和发现         支持，这样允许设备彼此窥测以找到交换数据的方式。

 有一种协议及其相关内容将万维网推向了成功，这就是 IP，或者叫做互联网协议。这个协议是每种浏览器与互联网连接的基础，也构成了 IT 数据中心的主干。有人认为物联网也会走同样的发展道路，他们相信拥有一个 IP 地址就足以让物联网连接在一起了。

但是物联网的问题不在 IP 上，而是叠加在 IP 之上的所有其他内容。运行诸如 HTTP、SSL 和 XML 这样的协议需要具备强大的计算能力和存储空间，目前一般的 PC、智能手机或者平板电脑等设备都已经完全胜任这一任务了，但是对于运行在一个很小的微控制器上的普通传感器来说这就有点勉为其难了(尽管 ARM Cortex-M7 的功能也很强大)。

为了解决这一难题，相关各方已经推出了大批的替代方案，大部分都是不具备互操作性的物联网协议，例如：6LoWPAN、AllJoyn、AMQP、ANT+、Bluetooth、CoAP、DASH7、DDS、INSTEON、KNX、MQTT、NFC、RFID、STOMP、Thread、Weightless、XMPP、ZigBee、以及 Z-Wave 等。这还只是其中的一部分，而且每周都会有具有更多思路的协议推出。

试图找到一种物联网的“圣典协议”，找到一种一统天下的端到端协议以便能够服务所有物品的想法是愚蠢的。一方面，传感器在范围、射频频谱、安全水平、拓扑结构、功率消耗等方面的要求是各不相同的，另外一方面，任何一个成功的物联网策略最终都需要与一个基于 IP 的云通过某种形式整合在一起。除此之外几乎很难找到其他类型的解决方案。因此物联网应用必须能够相互连接和交换数据。

解决方法是在传感器和致动器、移动设备、以及云之间搭建一个多重协议的桥梁，最好是开放式源代码，具有可扩展性，能够将大范围内的海量设备都包括进来。此外，传输应该是可靠的，能够经受住无线连接短暂的间断。

越来越多的机构正在将 MQTT 视为这一桥梁的一个组成部分。MQTT 既有完全高级版可以在 TCP/IP 上运行，也有简化版 MQTT-SN 用于非 IP 设备。其发布/订阅模式能够在让拓扑结构进行扩展的同时保留实时的特性以及服务质量的可配置性。

IBM 公司最初开发 MQTT 的目的是将其作为主机和服务器的消息传输代理，可整合入 WebSphere 为网络提供服务。随后公司在提供给 OASIS 以及 Eclipse 基金会时将其开放用于嵌入式用途。

IBM Bluemix 的一个重要部分是其 IoT Foundation 服务，这是一项基于云的 MQTT 实例，带有预定义的主题结构和消息格式。移动应用程序也早就开始使用 MQTT 了，如 Facebook Messenger 和 Salesforce.com 等。IBM 公司还有一个在 MQTT 基础上的 e-book 移动应用。

需要考虑的其他一些新进展包括：

· ARM 的 mbed device server 正在寻求用专门针对物联网的服务器来替代通用型网络服务器。借助于收购 Sensinode 公司而获得的技术，ARM 已经将HTTP、CoAP、以及 MQTT 整合在了一个平台上。

· 2lemetry 在此基础上通过 ThingFabric 的推出又向前迈了一步，将一些主要协议如 MQTT、CoAP、和 STOMP 连同可扩展性整合在了一起。

· PubNub 将一种 websocket 连接方式运行在 MQTT 上，重点实现云实施的低延迟和交付的可靠性。在 Atmel 公司的 Bits & Pieces 博客上有一篇访客写的很好的文章就是介绍 PubNub 的这一方法的。

· 说到 Atmel 和 Arduino，IBM 公司针对如何通过 IoT Foundation 充分发挥 Arduino 的作用提供了几种方法，例如一个 Arduino Uno 连接实例，以及一个如何实施云就绪温度传感器的系列说明。

· 开放源代码使许多人都深受鼓舞，不断出现各种独特的研究项目，其中一个比较令人感兴趣的项目是 AllJoyn 与 MQTT 之间的桥接。如果这个项目能够成功的话，其意义将是非常重要的，例如可以借助这种方式从一个移动设备上的 Facebook 直接控制家中的娱乐设施。

还是那句话，我不相信有一个“圣典协议”能够一劳永逸地在整个物联网上普遍采用，而且能够满足每一种具体应用的实际需求。最后脱颖而出的解决方案一定是将多个协议整合在一起用来为尽可能广泛的应用提供服务。MQTT 以实时方式将传感器和移动设备连接到大数据系统的能力正在吸引越来越多的人参与进来