首页 > IoT > MQTT 不是物联网的“圣典协议”,但是也差不多了
MQTT 不是物联网的“圣典协议”,但是也差不多了
来源:Atmel  时间:2015-01-05

有一种协议及其相关内容将万维网推向了成功,这就是 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 视为这一桥梁的一个组成部分。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 以实时方式将传感器和移动设备连接到大数据系统的能力正在吸引越来越多的人参与进来。

点击阅读英文原文