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