四个重要的IOT物联网协议介绍

物联网 (IoT) 有多种应用程序级协议可供使用，使应用程序开发和维护变得更加容易。然而，考虑到某些应用程序协议的范围、可用性、成熟度和细分市场适用性，某些应用程序协议比其他协议更合适。

本文重点介绍最适合互联网数据消息传递的应用协议，因此不会讨论 Zigbee、蓝牙和 Matter 等局域网机器对机器协议。

虽然超文本传输协议 (HTTP) 在某些用例（例如设备日志和视频等大文件传输）中找到了立足点，但它并不被视为轻量级应用程序协议。此外，当今大多数物联网工作负载都集中在通过远程信息处理进行数据采集以进行分析以及相对琐碎的命令和控制用例。然而，随着对物联网的理解不断扩展和成熟，我们正在寻求更加自主的协议。本文仅重点讨论每个协议的关键相关点。为了更深入地了解每个协议，提供了参考链接。在这种情况下，全文提供了深入研究协议的链接。

物联网应用协议为开发人员提供了物联网消息传递抽象，用于在设备和集中式服务之间进行通信。 IoT 消息传递提供了与各种网络介质以及低级寻址和路由协议交互的编程应用程序接口 (API)。最普遍的物联网应用协议可以灵活地在各种网络介质上运行，保持活跃的服务器和客户端选项，并从设备和云的角度得到供应商支持。

应用协议#1：消息队列遥测传输 (MQTT)

毫无疑问，消息队列遥测传输 (MQTT)是当今最普遍的物联网应用协议。 MQTT 于 1999 年推出，并于 2013 年实现标准化。结构化信息标准促进组织 (OASIS)是 MQTT 规范的托管机构。

自该标准获得批准以来，MQTT 得到了解决方案提供商、Amazon Web Services (AWS) 等超大规模云以及用于嵌入式 C 语言的 AWS IoT 设备 SDK等物联网编程框架和库的广泛支持。其简单的发布-订阅模型与基于主题的命名空间的自然使用相结合，为解决方案设计人员提供了最大的灵活性和便利性。不乏示例、教程和软件开发工具包，可以为大多数物联网产品构建情况提供清晰、简洁的指导。

广泛的支持帮助 MQTT 推动其规范的不断改进。目前大多数实现都基于MQTT 3.x 规范。最近推出的MQTT 5 规范扩展了功能并克服了许多 3.x 限制。然而，超大规模云以及客户端工具链对 MQTT 5 的广泛支持还需要时间。

对于物联网产品制造商来说，最好的方法是依靠最可行且广泛采用的工具链，以确保更轻松的迁移。除非物联网产品的目标是使用特定的 MQTT 5 功能，否则专注于 MQTT 3.x 可能会面临较少的挑战。另一方面，AWS IoT Greengrass 中对 MQTT5 支持的推出反映了明确的需求信号。

当今所有超大规模云都支持 MQTT，但不同程度地完全符合协议规范。超大规模云的一个显着挑战是克服服务质量 (QoS)。 QoS 有效地规定了消息传递保证，这从客户端和代理之间的协议开始，该协议随后规定了它们如何协同工作以确保 QoS。

在QoS 0时，从客户端发送的消息最多会被接收一次。在QoS 1下，消息将至少传送一次。在QoS 2下，代理只接收一次消息。虽然大多数超大规模云提供 QoS 0 和 1，但 QoS 2 可能极其困难，因为代理必须考虑收到的所有消息，以确保消息在其生命周期内仅在某个主题上可用一次。由于数据量可能非常惊人，因此扩展此类服务可能变得不切实际。在这种情况下，许多云提供了重复数据删除模式，将消息移动到主题订阅者使用的主题。

应用协议#2：高级消息队列协议（AMQP）

尽管高级消息队列协议 (AMQP)最初是作为业务消息传递的基础而形成的，但它已在物联网应用协议领域获得了关注。 AMQP 于 2003 年推出，并于 2014 年标准化，由OASIS标准组管理。 IoT 中最典型的模式是发布-订阅。由于底层架构是基于队列而不是基于主题，因此 AMQP 经常出现在需要高度强化和弹性的工业物联网和能源物联网环境中。

直到最近，AMQP 作为物联网应用协议的采用加速还无法与 MQTT 相媲美。 AMQP 面临的一个挑战是安全支持。它作为企业消息传递协议的历史意味着它主要在封闭网络中运行，并有物联网所需的大规模安全配置的轶事证据。 2021 年 3 月 17 日，AMQP 推出了名为AMQP Claims-based security version 1.0 的新规范，这可能会有所帮助。新的交互模型利用OAuth 2.0和JSON Web 令牌 (JWT)在 AMQP 连接上下文中确保安全。新的发展可能有助于与 MQTT 竞争。

超大规模云提供一定程度的 AMQP 支持。 AMQP 供应商包括HiveMQ和RabbitMQ，它们通常用作超大规模托管服务的底层技术。 Amazon MQ 是 RabbitMQ 开源项目的托管服务，提供 AMQP 支持，但鼓励客户不要公开端点，但可以通过 AWS direct connect 等私有网络进行互操作。 HiveMQ 和 RabbitMQ 在 AWS 市场上都有产品。其他超大规模云提供不同程度的支持。

应用协议#3：实时系统（DDS）的数据分发服务

实时系统数据分发服务 (DDS)协议被构建为一种高速、低延迟的中间件协议。 DDS 于 2001 年推出，于 2003 年标准化，由对象管理组 (OMG)管理，  但受DDS 基金会管辖。 DDS 在其标准批准后不久就很受欢迎，但在整个 2010 年代一直萎靡不振。然而，最近它被证明是机器人和控制系统中工业物联网应用协议的有力竞争者。 DDS 被选为机器人操作系统 2 (ROS2)的消息传递协议。 Real-Time Innovations (RTI)、eProsima 和 ADLink 等 DDS 供应商分别投入巨资持续开发 Connext Professional、Fast DDS 和 Vortex DDS。

与 MQTT 一样，DDS 是基于主题的，采用发布-订阅模式，但相似之处仅此而已。消息有效负载可以被认为是二进制格式，这会使消息构造更加复杂。最后，众所周知，DDS 在其同类产品中更为重量级，其标头大小相对较大，为 16 字节。这可能看起来不多，但随着时间的推移，繁忙的消息流字节数会增加，这就是为什么 DDS 对于小型电池供电的 IoT 设备来说被认为是不切实际的。

因此，当今的超大规模云都没有原生 DDS 支持，这意味着没有简单的选项可以将原生 DDS 数据引入云中进行分析。然而，这并不意味着客户没有选择。 RTI 和 eProsima 都有 DDS 路由器产品，可将本地生成的 DDS 数据桥接到另一个广域网实体（可以是云）。另一个选择是 eProsima 的 DDS 路由器，它也可以在相同的环境中运行。让 DDS 数据参与物联网，为超大规模云中的本地 DDS 数据分析提供了可能性，以进行分析、模拟和机器学习，而无需任何协议到协议的转换以及相关的序列化-反序列化开销。

应用协议#4：受限应用协议（CoAP）

与 DDS 一样，受限应用协议 (CoAP)是为局域网构建的，但主要区别在于它与参与互联应用程序的设备更相关。 CoAP 协议于 2013 年推出，自 2014 年以来一直处于不断发展的状态。CoAP 得到互联网工程任务组 (IETF)通过RFC 7252的支持。

也许 CoAP 无法与 MQTT 竞争的唯一原因是它严格依赖用户数据报协议 (UDP)，这使得它很容易在有损网络中丢失数据。随着互联网络变得更具弹性，CoAP 可能成为 MQTT 的坚定竞争对手，尤其是对于不需要高服务质量的物联网系统。超大规模云尚未采用 CoAP，但这种情况可能正在改变。如果物联网产品制造商开始更频繁地要求 CoAP 作为 MQTT 的广泛可行替代方案，我们自然会看到对构建 CoAP 通信的更广泛支持。

降低风险：明智地选择您的方案

从设备硬件和软件到超大规模云开发再到设备调试和配置等多个角度来看，物联网仍然很复杂。一般来说，为物联网产品选择 MQTT 是自然的选择。但是，如果物联网产品在医疗、工业、机器人等专业领域运行，请检查 AMQP、CoAP 和 DDS 等应用协议的使用情况，以获得更好的物联网系统集成结果。