16、物联网传输与消息协议深度解析

物联网传输与消息协议深度解析

1. 协议基础与资源约束

在信息传输中，RESTful 配置有其特定要求，比如要先测试风扇是否意外关闭，信息传输有明确概念。以改变恒温器的参考温度为例，说“降低 2 度”在不可靠的安装中不能确保命令执行，而说“将参考温度设置为 36 度”，设备能检查自身当前设置并调整参考值。

某些协议是为资源匮乏（如内存空间小）的设备专门设计的，有些则不是，还有些可帮助实现应对这些约束。“约束”的构成因众多参数而异，有人认为几千字节的代码就算有约束。据 RTI 称，DDS 的有限版本接近 500K 字节。

2. 市场上的物联网消息协议

市场上的“物联网消息”协议有不同的发布者和规范，如下表所示：
| 发布者 | 规范/标准 | 定义 |
| — | — | — |
| ITU | ITU - T Y.2060 | 物联网概念 |
| ITU | ITU - T Y.2060 | 机器 - 应用接口 |
| IEEE | IEEE 802.15.4 | 数据链路层 |
| IEEE | 6LoWPAN | IPv6 低功耗无线个人区域网络 |
| IEEE | CoAP | 受限应用协议 |
| IETF | RPL | 低功耗有损网络的 IPv6 路由协议 |
| GS1 | ONS | 对象命名服务 |
| GS1 | EPC | 电子产品代码 |
| OASIS | MQTT | 消息队列遥测传输 |
| OASIS | AMQP | 高级消息队列协议 |
| OASIS | DDS | 数据扩散服务 |

3. 常见协议介绍

3.1 HTTP 协议

HTTP（超文本传输协议）是用于万维网的通信协议，基于 TCP 传输层，默认情况下，HTTP 服务器使用端口 80（HTTPS 使用 443）。知名的 HTTP 客户端是 Web 浏览器，可让用户访问包含数据的服务器，这些客户端连接到如 Apache HTTP Server 或 Internet Information Services 等 HTTP 服务器。HTTPS 是 HTTP 的安全变体，用于安全浏览，使用 SSL 或 TLS 安全交易协议，常用于安全支付。

3.2 HTTP/2 协议

HTTP/2 是 HTTP 的修订版本，虽本身不是消息协议，但规范中表明它可部分解决过去性能上的限制，适合物联网和与云的通信。它能处理流和“推送”服务器，在开放连接内可发起数据流。对于资源有限的小设备，使用哈夫曼编码压缩头部，HPACK 就是实现此功能的例子。

3.3 MQTT 协议

MQTT（消息队列遥测传输）由 IBM 参与开发，运行在 TCP/IP 协议的 TCP 层之上，1999 年以“发布/订阅”模式创建并开源。MQTT v3.1.1 已成为 OASIS 标准。其最初用于遥测或远程监控应用，旨在从众多设备收集数据并传输到 IT 基础设施，所有元素连接到服务器/数据集中器。

MQTT 是简单轻量级的消息协议，适用于需最小化带宽资源需求、有显著延迟的系统和网络，同时要保证可靠性、一定的交付保证和质量，以及管理远程元素的电池性能。它需要双向、有序、无损的连接，提供三种服务质量（QoS）方面：
- 消息最多发送一次（可能永远不到达）；
- 消息至少交付一次（可能有重复）；
- 消息恰好交付一次。

通常 MQTT 客户端初始化连接，服务器作为代理。该协议不支持发现过程，直接寻址设备较困难，因此有了 SMQ 协议。MQTT 适用于小型设备的广泛网络和需要从众多来源收集数据的系统，许多云软件平台支持它，如 IBM 的 Bluemix、亚马逊的 AWS IoT、微软的 Azure IoT 等。在软件方面，通信通过五种类型的数据包进行：连接、发布、订阅、取消订阅和心跳；在硬件方面，Arduino 卡支持 MQTT 与云通信。

3.4 MQTT 的安全性

MQTT V3.1 版本可通过数据包传输用户名和密码，网络加密可使用 SSL，但 SSL 不是最轻量级的安全协议，会增加网络负载。应用程序可添加进一步的安全措施加密传输和接收的数据，但要保持协议简单轻量级，集成这些措施并不容易。

3.5 CoAP 协议

CoAP（受限应用协议）是 SOAP 的后继者，属于 TCP/IP 模型的“应用”层协议。它主要源自 HTTP，有来自 REST 模型的一些修改，与 HTTP 有些相似但数据包更小，在一定程度上与 MQTT 竞争。

CoAP 是用于促进简单小设备在互联网上交互通信的传输/Web 消息协议，适用于资源受限的节点，如小传感器、开关、阀门等需通过标准互联网网络进行控制或远程监控且要求高效的组件。它提供客户端/服务器模型和设备间的问答交互，支持服务和资源的集成发现系统，集成了 Web 的关键概念，如媒体类型管理、URI 结构和互联网数据。它设计为便于与 HTTP 接口集成到 Web 上，同时支持组播 IP、低负载和简单性以适应受限环境，这些在物联网和机器对机器（M2M）设备中非常重要。

CoAP 工作在 UDP 之上，使用四种 REST 命令，含义与 HTTP 略有不同。若需要确认接收（有超时和指数重发模型），消息可标记为“可确认”，消息可以是单播或组播，能在大多数处理 UDP 或类似 UDP 解决方案的元素上运行。它在 M2M 网络、智慧城市应用、建筑自动化和物联网平台的能源管理领域取得了成功。

下面是 CoAP 协议的工作流程 mermaid 流程图：

graph LR
    A[客户端] -->|请求| B(CoAP 服务器)
    B -->|响应| A
    A -->|发现服务/资源请求| C(服务/资源发现系统)
    C -->|服务/资源信息| A

3.6 XMPP 协议

XMPP（可扩展消息和存在协议）主要用于通过服务器进行即时的人与人或点对点的文本消息传递，有实现“发布/订阅”模型的扩展。它基于 XML，默认格式为文本，便于人与人之间的通信，工作在 TCP 层。

在物联网中，其主要优势是地址模式为 name@domain.com，便于寻址设备，适合远距离设备间的数据交换，还可确认特定设备的存在或可用性，此时设备需管理发现模式。BOSH 协议可将推送消息拆分成多个部分。XMPP 不是为高速通信设计的，“实时”方面通常以秒为单位衡量，例如可用于将房屋的恒温器连接到 Web 服务器，以便通过手机访问信息，其在寻址、安全和可扩展性方面的优势使其适用于主流物联网应用。

4. 其他协议介绍

4.1 DDS 协议

DDS（数据分发服务）处于 OSI 模型的应用层，是源自国防领域的中间件协议。它围绕标准数据，侧重于工业和嵌入式应用之间的交互，采用高效的“实时”系统。

与“以消息为中心”的消息服务不同，DDS 是“以数据为中心”的消息服务，基于“发布 - 订阅”机制。应用程序可以通过发布修改共享数据并通知其他应用程序，也可以订阅某些共享数据以接收远程应用程序所做的相关修改。

DDS 具有以下特点：
- 可轻松大规模部署；
- 独立于语言和操作系统；
- 数据用合适的语言描述，如基于 CORBA 标准的接口定义语言（IDL），通过分析可提供合适的访问器和修改器；
- 应用程序有应用编程 API，可使用众多服务；
- 能每秒向众多接收者有效同时交付数百万条消息；
- 引入了域的概念，涵盖网络中分布的一组机器并共享公共数据；
- 主要针对直接使用设备数据的设备，用于连接设备并向其他设备分发数据；
- 本身没有代理，可通过互连“总线”工作，可实现有或没有代理的模式。

由于其性能优势，DDS 主要应用于高性能物联网系统，适用于对可靠性和性能有严格要求的行业，如航空航天、国防、军事系统、电信、风电场、医院集成、医学成像、资产管理系统、汽车测试和安全测试等。

以下是 DDS 协议的工作原理列表说明：
1. 应用程序发布数据修改，通知其他订阅者。
2. 订阅者订阅感兴趣的数据，接收相关修改。
3. 通过域来管理和共享数据。

4.2 AMQP 协议

AMQP（高级消息队列协议）是 OASIS 家族的中间件协议，基于“以消息为中心”的模型，由银行业和金融领域开发，能够快速可靠地处理数千个排队的交换和交易。

该协议主要关注消息路由质量，确保消息在传输过程中不丢失，注重服务质量（QoS），仔细监控消息并保证每个消息到达预期接收者，无论网络出现何种故障或重启。通信在 TCP 层之上进行，发送服务器之间的交易消息，相关设备必须确认收到每条消息。标准还规定了可选的事务模式，有正式的多阶段验证序列。

AMQP 主要用于服务器到服务器的业务消息传递，网络中的“元素”通常是移动/便携式手持设备，用于与后台数据中心通信。在物联网中，该协议需要包含认证和加密单元（SASL/TLS）以及代理，更适用于基于服务器的控制计划或分析功能。

4.3 SMQ 协议

SMQ 是“Real Time Logic”公司的专有协议，针对 MQTT 和 CoAP 在小型设备应用中的一些不足而设计。其主要特点是使用代理在消息中分配和广播的“临时”ID，以便响应可以直接发送到特定设备，这样更容易控制或与特定节点进行通信。

通常，通信通过使用 WebSocket 连接的“增强”HTTP 开始（本质上是 TCP，具有更高级别的数据包概念），软件实现使用脚本语言 Lua。

4.4 JMS 协议

JMS（Java 消息服务）是 Sun 开发的 API，用于在应用程序或 Java 组件之间快速、可靠且异步地发送和接收消息。因此，它仅适用于能够运行 Java 的设备，使它们能够在 Java 应用中使用消息服务，就像 JDBC API 用于数据库一样。

JMS 是“以消息为中心”的，与之前的协议类似，基于分布式软件架构，采用与 HTTP 相同的原则、设计规则和属性。它也运行在 TCP/IP 传输层之上，使用一组受限的动词用于所有用例，即 REST（表述性状态转移）模式下的 CRUD：创建（CREATE）、读取（READ）、更新（UPDATE）和删除（DELETE）。

JMS 可以在“发布/订阅”和“点对点”模式下运行，在消息供应方面具有良好的服务质量。

以下是各协议特点对比表格：
| 协议名称 | 适用场景 | 服务质量 | 连接类型 | 主要优势 |
| — | — | — | — | — |
| HTTP | 万维网通信 | 无特定 QoS | TCP | 广泛应用，易于集成到 Web |
| HTTP/2 | 物联网与云通信 | 无特定 QoS | TCP | 解决性能限制，支持流和推送 |
| MQTT | 小型设备网络，数据收集 | 三种 QoS 级别 | TCP | 简单轻量级，云平台支持多 |
| CoAP | 资源受限设备 | 可配置确认 | UDP | 适合受限环境，支持组播 |
| XMPP | 主流物联网应用 | 无特定 QoS | TCP | 寻址方便，可确认设备存在 |
| DDS | 高性能物联网系统 | 高效实时 | 自定义 | 大规模部署，实时性强 |
| AMQP | 服务器到服务器业务 | 高 QoS 保障 | TCP | 消息路由可靠，支持事务 |
| SMQ | 小型设备应用 | 未提及 | TCP | 便于特定设备寻址 |
| JMS | Java 应用消息传递 | 良好 QoS | TCP | 适用于 Java 环境，支持多种模式 |

5. 总结

不同的物联网传输与消息协议各有特点和适用场景。在选择协议时，需要考虑设备资源、通信需求、服务质量要求、安全性等多方面因素。例如，对于资源匮乏的小型传感器，CoAP 可能是更好的选择；而对于需要大规模数据分发和实时交互的工业应用，DDS 则更具优势。通过了解这些协议的特性，可以更好地构建高效、可靠的物联网系统。

希望本文能帮助你对物联网传输与消息协议有更深入的理解，在实际应用中做出更合适的选择。