MQTT vs HTTP vs Modbus TCP vs OPC UA: Which Protocol Should an IoT Gateway Use?

Quick Answer

传感器本身并不决定最终云平台或 SCADA 的协议。现场层可以统一使用 RS485 Modbus RTU，而网关负责把这些数据转换或重新封装成应用层需要的协议。真正的选择取决于：谁主动发起通信、数据存在哪里、服务器是否需要下发命令、客户已有的软件系统是什么。

MQTT 通过 Broker 把发送端和接收端解耦。网关把传感器数据发布到 Topic，一个或多个应用订阅该 Topic。远程分布式监测站特别适合这种模式，因为网关不需要知道最终有多少个业务系统消费数据。

同一份传感器数据，可以用完全不同的方式交付

MQTT：更适合云平台的发布/订阅架构

完整 MQTT 配置通常包含 Broker 地址、端口、Client ID、认证信息和 Topic。常见误区是“设备显示 Online 就代表数据已经到了”。实际上 Online 只证明建立了 MQTT 会话，仍可能发布到错误主题、服务器订阅了另一个主题，或者网关根本没有采集到有效传感器数据。

Publish 和 Subscribe 不能弄反

Publish Topic 是设备向外发送遥测数据的位置；Subscribe Topic 通常用于平台向设备发送指令或消息。如果服务器要收到测量数据，就应该订阅网关的 Publish Topic。在一些实现中，把发布和订阅设置成同一个主题可能造成不必要的回环，因此不应作为默认配置。

MQTTS 与 8883 端口

MQTTS 通常指 MQTT over TLS。8883 是常见 TLS 端口，但真正能否连接不仅取决于端口，还取决于 TLS 库、CA 校验方式、服务器证书、是否需要客户端证书以及 MQTT 版本兼容性。实际第三方云平台调试中，确实可能出现同一网关能连一个 TLS Broker、却无法连接另一个 Broker，最终需要固件升级的情况。

批量项目出货前，应使用客户真实 Broker、真实证书模式和最终固件做完整测试。证书应与客户服务器/云平台体系匹配，不是网关厂家可以脱离服务器随意生成的一套通用文件。

HTTP POST：客户已有 Web 接收接口时最直接

如果客户已经有一个能够接收 POST 请求的服务器应用，HTTP 往往是非常直接的方案。网关作为 HTTP Client，按照设定周期把 JSON 发送到指定 URL。这适合客户自建 Web 后台，也适合软件团队不想单独维护 MQTT Broker 的场景。

典型 JSON 可以包含时间戳、站点 ID 和 params 对象，内部放各传感器数值。字段名称本身属于项目约定，真正需要提前确定的是：数据类型、单位、无效/缺失数据如何表示，以及服务器收到后返回什么。

Modbus TCP：PLC/SCADA 主动读取时更合适

Modbus TCP 把熟悉的 Modbus 寄存器模型搬到以太网上，适合 PLC、HMI 或 SCADA 已经作为 Modbus 主站的工业系统。网关可以把 RS485 Modbus RTU 设备桥接到 Ethernet，也可以把自己采集到的数据映射到规定寄存器。

如果客户的表达是：“给我们一个 IP，并告诉我们每个信号存在哪里，我们自己来读”，这种需求通常更接近 Modbus TCP，而不是 MQTT 或 HTTP。

OPC UA：更适合丰富的工业集成

OPC UA 可以把数据组织成有名称的标签/节点，并携带结构和元数据，而不是只有数字寄存器地址。因此它适合 SCADA、工业中间件和 PC 软件，需要标准化发现、读取和订阅的场景。

不同网关对 OPC UA 的角色可能不同，必须确认是 Server、Client 还是两者都支持。在 NiuBoL 项目中，如果 OPC UA 是核心要求，更适合优先选较高能力的边缘网关。

到底该选哪个协议？

不要混淆“现场协议”和“上行协议”

一个系统完全可以在传感器到网关这一段使用 RS485 Modbus RTU，同时在网关到云平台这一段使用 MQTT。也可以先用 ADC 读取 4–20mA，再把换算后的数据通过 Modbus TCP 或 OPC UA 提供给 SCADA。现场接口和应用层协议是两个独立设计层。

故障排查：MQTT 已连接但没有数据

• 先确认网关内部确实已经采集到传感器数据。
• 检查上报周期，并确认网关正在“发布数据”，而不仅仅是“已连接 Broker”。
• 逐字符核对 Publish Topic，包括前导“/”以及平台可能区分的大小写。
• 使用独立 MQTT 客户端订阅同一 Topic，把网关问题和业务平台问题分开。
• 检查用户名/密码、Client ID 冲突，以及是否有另一个客户端占用了相同凭据。
• TLS 场景检查 CA/服务器证书、MQTT 版本和固件 TLS 库兼容性。
• 查看网关日志；必要时抓包，确认报文是否真正离开设备以及服务器如何响应。

故障排查：HTTP 服务器完全收不到数据

第一步先把“采集”和“上传”分开。如果网关日志已经显示下位机无回复，就先修复传感器采集层，不要先去调服务器。确认采集正常后，再检查 URL、端口、DNS/网络可达性、Content-Type、JSON 格式以及 HTTPS 要求。这里的 HTTP 功能是网关主动向服务器 POST 的 Client，不是自动提供给客户浏览的 HTTP Server。

常见问答Q1. IoT 项目中 MQTT 一定比 HTTP 好吗？

A1. 没有绝对优劣。MQTT 适合发布/订阅和大量远程设备；客户已经有 Web 接收接口时，HTTP 往往更直接。

Q2. MQTT 显示 Online 是否代表平台已经收到传感器数据？

A2. 不代表。Online 只说明连接建立，仍要确认传感器采集、发布动作、Topic 和平台订阅。

Q3. MQTT 的 Publish 和 Subscribe Topic 有什么区别？

A3. Publish 用于网关发送遥测数据；Subscribe 用于网关接收服务器发来的消息或指令。

Q4. IoT 网关可以用 HTTP POST 发送 JSON 吗？

A4. 支持 HTTP Client 上传的网关/固件可以。项目要提前约定 JSON 结构和服务器响应。

Q5. MQTTS 是否只要端口填 8883 就行？

A5. 不行。8883 很常见，但固件 TLS、证书方式和目标 Broker 必须兼容。

Q6. 什么时候应该用 Modbus TCP 而不是 MQTT？

A6. 当 PLC/SCADA 等工业主站需要通过以太网主动轮询寄存器时，更适合 Modbus TCP。

Q7. 什么时候 OPC UA 更合适？

A7. 当工业软件需要标准化标签/节点、元数据和更丰富的互操作能力时。

Q8. 一个网关可以同时使用多个上层协议吗？

A8. 很多边缘网关可以，但是否能同时多目的地运行必须以实际固件和项目测试为准。