效率对比：OPC-UA、Modbus、MQTT、Sparkplug、HTTP

插图：© IoT For All --> OPC-UA、HTTP、Modbus、MQTT 和 Sparkplug 是工业通信中常见且流行的技术，每种技术都适用于特定的通信层级和目的。OPC-UA 通常用于车间环境中，HTTP 常用于互联网通信，MQTT 适用于本地或云平台通信，而 Modbus 在设备级别的通信中应用广泛。虽然这些技术的设计目的不同，但我们可以从通信效率方面进行比较。在本文中，我们将从影响传输带宽的四个通信标准出发，对这些协议进行效率比较：连接开销、连接持久性、基于变化的数据传输、数据压缩。本文中的图表和发现基于 Jonathan Hottell 在 2019 年进行的实验。**连接开销**当两个设备通过网络进行通信时，它们通常会建立连接以交换数据。这一过程包括多个步骤，从而产生连接开销，主要包括：- **握手过程**：在数据传输开始前，设备需要通过交换一系列信息（称为握手）来建立连接。握手验证设备的身份，协商通信参数，并确保双方准备好发送和接收数据。这种初始的协商和验证过程会消耗时间和网络资源。- **协议开销**：网络协议（如 TCP/IP）引入了额外的开销，以确保可靠有序的数据传输。这些协议添加了控制信息、错误检查机制、排序和确认机制，以确保数据的完整性和送达。尽管这些功能增强了网络通信的可靠性，但也引入了处理和网络资源的开销。**OPC-UA**：OPC-UA 由于其复杂架构和广泛的功能集，会引入额外的开销。建立 OPC-UA 连接涉及多个步骤，包括握手、安全协商和会话建立，这导致较高的连接开销。**Modbus**：Modbus 的连接开销较低，因为该协议不需要复杂的握手或会话管理。Modbus 主要专注于对数据点的直接访问，连接建立的开销通常只限于建立网络连接和定位从设备。**HTTP**：与上述其他协议相比，HTTP 会引入较高的连接开销。每个 HTTP 请求-响应周期通常涉及建立新的连接，这在握手、头部交换和会话管理方面会增加额外的开销。**MQTT**：MQTT 被设计为轻量且高效，因此连接开销较低。它使用简单的二进制协议和最小的头部大小，减少了建立和维护连接所需的数据量。**Sparkplug**：Sparkplug 引入的额外开销相对 MQTT 很小，因为它主要专注于定义负载格式和数据表示，而不是改变连接行为。**EMQ 技术**简而言之，这项效率比较表明，作为更强大且功能丰富的协议，OPC-UA 可能比其他技术具有更高的连接开销。MQTT 作为更简单和轻量的协议，通常连接开销较低。HTTP 和 Modbus 采用请求-响应模型，它们也有相对合理的连接开销。Sparkplug 因为“出生”消息的引入，连接时会稍微多一些数据。图中显示的实验结果与我们已有的知识非常一致。**连接持久性**一旦连接建立，就需要一定的开销来维护连接。这包括定期交换“保活”消息，以确保连接保持活跃，并在连接的两端管理连接状态信息。此外，面向连接的协议在连接中断或丢失时可能需要重新建立连接，从而进一步增加开销。因此，保持连接在多个请求中打开可以减少建立新连接所带来的开销，从而提高效率。让我们看看连接的效率比较：**OPC-UA**：OPC-UA 是客户机-服务器模型。客户机和服务器之间的连接可以是持久的，也可以是非持久的，具体取决于应用程序或协议的需求和特性。但在此情况下，我们假设使用的是持久连接。**Modbus**：Modbus 同样是客户机-服务器模型。Modbus 本身并不强制要求客户机和服务器之间保持持久连接。而是为每个请求建立连接，响应接收后连接就关闭。**HTTP**：HTTP 是一种主要用于网络通信的无状态协议。每个 HTTP 请求-响应周期都是独立的，默认情况下请求之间不会保持连接。**MQTT**：MQTT 采用的是持久连接模型。一旦客户机与 MQTT 代理建立连接，连接会保持打开，直到由客户机或代理明确关闭。它还提供了诸如保活机制和自动重新连接等功能，以确保在网络中断的情况下连接的可靠性。**Sparkplug**：Sparkplug 基于 MQTT，继承了 MQTT 的连接维护特性。它采用持久连接模型，允许客户机和 MQTT 代理之间建立长连接。我们假设 Sparkplug 的结果与 MQTT 类似。**EMQ 技术**OPC-UA 和 MQTT 被设计为支持连接持久性，可以在单个连接上处理多个请求，从而减少连接建立的开销。HTTP 和 Modbus 在标准配置中通常使用短连接，这可能导致每次请求的连接开销更高。**基于变化的数据传输**“基于变化的报告”机制常用于工业自动化和通信协议中，用于仅在监控变量或参数的值发生变化或更新时才传输数据。与定期传输数据相比，该机制通过仅在必要时发送数据更新来优化网络带宽的使用。在需要监控或控制大量数据的系统中，定期传输所有数据可能会导致网络资源的低效使用。“基于变化的报告”机制通过选择性地在监控变量值发生显著变化时发送数据更新，从而减少不必要的网络流量和数据传输开销。效率比较如下：**OPC-UA**：OPC-UA 通过其订阅模型支持“基于变化的报告”机制。OPC-UA 客户端可以订阅服务器中的特定变量或节点。服务器仅在订阅数据发生变化时才向客户端发送更新。**Modbus**：作为一种简单而传统的协议，Modbus 本身不支持“基于变化的报告”机制。它主要关注对数据点的直接访问，而不具备报告变化的内置机制。**HTTP**：HTTP 本身没有“基于变化的报告”功能，但可以在应用层通过长轮询或服务器发送事件（SSE）技术实现。这些技术允许服务器在发生更改时将数据更新推送到客户端。**MQTT**：MQTT 本身的标准规范中并不包含“基于变化的报告”机制。然而，可以通过将 MQTT 与其他协议或应用程序逻辑结合来实现该功能。**Sparkplug**：Sparkplug 为“基于变化的报告”机制提供原生支持。它定义了包含元数据和数据值的标准负载格式。订阅客户端仅在数据值发生变化时才会接收到更新。**EMQ 技术**OPC-UA 的发布/订阅模型和 MQTT 支持基于变化的数据传输机制，即仅在数据发生变化时发送数据，从而减少不必要的网络流量并提高效率。相比之下，OPC 读写模型、HTTP 和 Modbus 通常依赖于周期性或轮询式的获取数据方式，这可能导致较高的网络流量和较低的带宽效率。Johnathan 的实验反映了“基于变化的报告”机制可以显著减少网络流量。**数据压缩**通信中的数据压缩是指通过减少数据的大小，以便在网络或通道上传输更高效的过程。它包括在发送前对数据进行压缩，并在接收端解压缩以恢复原始数据。需要注意的是，通信系统中的发送方和接收方必须支持相同的压缩算法，以确保压缩和解压成功。让我们看看不同协议的数据压缩效率比较：**OPC-UA**：OPC-UA 使用 UA-XML、UA-JSON 或 UA-binary 来传输数据。这些数据格式本身不支持数据压缩。OPC-UA 使用 base64 编码数据，这并不具备压缩能力。除非将数据作为服务进行压缩，否则 OPC-UA 的二进制传输压缩无法提高带宽效率。**Modbus**：Modbus 不支持任何数据压缩。**HTTP**：HTTP 可能支持数据压缩，但不是标准功能，需要在应用层进行额外配置或实现。**MQTT**：MQTT 可能支持数据压缩，但不是标准功能，需要在应用层进行额外配置或实现。**Sparkplug**：Sparkplug 将其负载定义为 Google Protobuf，而 Protobuf 本质上是一种压缩数据格式。因此，Sparkplug 可以被视为具有数据压缩功能的协议。**EMQ 技术**OPC-UA 提供了数据压缩的内置支持，但压缩率不高，对于高效传输压缩数据帮助不大。HTTP 和 MQTT 可能支持数据压缩，但这不是标准功能，需在应用层面进行额外配置或实现。Modbus 不支持任何数据压缩。Sparkplug 定义了其负载为 Google Protobuf，这在传输中某种程度上是压缩的数据。**正面对比图表**| 协议 | 连接开销 | 连接持久性 | 基于变化的数据传输 | 数据压缩 ||------------|----------|--------------|------------------|------------|| OPC-UA | 差 | 差 | 不支持 | 中等 || Modbus | 优秀 | 中等 | 不支持 | 差 || HTTP | 优秀 | 差 | 用户定义 | 用户定义 || MQTT | 优秀 | 良好 | 用户定义 | 用户定义 || Sparkplug | 良好 | 良好 | 支持 | 优秀 |**Sparkplug 是最有效的协议**从上述效率比较可以看出，Sparkplug 协议是工业应用中最有效的协议。它对“基于变化的报告”机制提供了原生支持，使其非常适合数据更新的高效传输。此外，由于其轻量级协议和持久连接模型，它具有较低的连接开销，确保了连续通信和高效的消息传递。TweetShareShareEmail 连接性 数据分析 MQTT 网络与协议