一个项目里既有 RS485 温湿度传感器，也有带以太网口的 PLC。前者的手册写着 Modbus RTU，后者支持 Modbus TCP。它们都能读取保持寄存器，也都使用 03 功能码，但接线、报文和调试方法完全不同。
这正是 Modbus 选型中最容易混淆的地方：Modbus RTU 和 Modbus TCP 不是两套毫无关系的协议，它们共享 Modbus 的数据模型和大部分功能码，主要区别在于一条 Modbus 请求如何被封装、寻址并送到目标设备。
先记住一句话：RTU 把 Modbus 放在串行链路上，TCP 把 Modbus 放在 TCP/IP 网络上。 项目选型不能只看谁“更快”，还要看现场设备接口、已有网络、节点分布、轮询规模和维护方式。
推荐阅读：边读文章，边对照官方文档
- 先看协议原理：Modbus RTU 基础知识、Modbus TCP 基础知识。
- 边读边做 RTU 接入：RS485 / Modbus 设备通过 DTU 透传接入 ThingsCloud。
- 边读边做 TCP 接入：西门子 PLC S7-200 SMART Modbus TCP 接入 ThingsCloud。
两者相同的部分：Modbus 应用层
Modbus 定义了客户端如何请求、服务器如何响应，以及请求中功能码、寄存器地址和数据的含义。传统资料也常使用“主站 / 从站”，本文沿用当前规范中的“客户端 / 服务器”，两组术语表达的是相近的请求与响应角色。
无论使用 RTU 还是 TCP，常见的数据对象都包括：
- 线圈：单比特，可读写。
- 离散输入：单比特，只读。
- 保持寄存器：
16位，可读写。 - 输入寄存器：
16位，只读。
常用功能码也基本一致，例如 01 读取线圈、03 读取保持寄存器、04 读取输入寄存器、05 写单个线圈和 06 写单个寄存器。
假设要从地址 100 开始读取 3 个保持寄存器，核心 PDU 可以写成：
03 00 64 00 03
其中 03 是功能码，00 64 是从 0 开始计算的协议地址，00 03 是读取数量。RTU 和 TCP 都可以携带这段 PDU，差别出现在它的外层。
核心区别：RTU 用串行帧，TCP 使用 MBAP 报文头
Modbus RTU 报文
Modbus RTU 的应用数据单元由从站地址、PDU 和 CRC 校验组成：
[从站地址 1 字节] [功能码 + 数据] [CRC 2 字节]
放入前面的读取请求后，可以理解为：
01 03 00 64 00 03 CRC-Lo CRC-Hi
这里的 01 是从站地址。CRC 用来检查串行传输中的错误，完整 RTU 报文最大为 256 字节。RTU 还依赖帧间静默时间识别报文边界：规范要求报文之间至少间隔 3.5 个字符时间。
这些规则意味着 RTU 调试不仅要看功能码和寄存器，还要同时检查波特率、数据位、停止位、奇偶校验、从站地址和总线时序。任何一项不一致，都可能表现为超时或 CRC 错误。
Modbus TCP 报文
Modbus TCP 不使用 RTU 的从站地址开头和 CRC 结尾，而是在 PDU 前增加 7 字节的 MBAP 报文头：
[事务标识 2 字节] [协议标识 2 字节] [长度 2 字节] [单元标识 1 字节] [功能码 + 数据]
同一个读取请求可以写成：
00 01 00 00 00 06 01 03 00 64 00 03
00 01：事务标识，用于匹配请求和响应。00 00：协议标识，Modbus 固定为0。00 06：后续字段的字节长度。01：单元标识，经过 TCP / RTU 网关访问串口从站时可用于路由。03 00 64 00 03：与 RTU 示例相同的 PDU。
MBAP 头中的长度字段可以帮助接收端从 TCP 字节流中识别完整报文。开发自定义 Modbus TCP 客户端时，不应假定一次 recv 就一定得到一条完整报文，也不应假定一次只会收到一条报文；应按照 MBAP 长度持续组帧。
Modbus TCP 的完整应用数据单元最大为 260 字节，通常使用 TCP 端口 502。它不再追加 RTU 的 CRC 字段，而是依赖 TCP/IP 和底层网络的数据完整性机制。
Modbus RTU 与 Modbus TCP 对比表
| 对比维度 | Modbus RTU | Modbus TCP |
|---|---|---|
| 常见物理接口 | RS485、RS232 | 以太网，也可经过光纤、WiFi 或蜂窝网络承载 IP |
| 报文外层 | 从站地址 + PDU + CRC | MBAP 头 + PDU |
| 目标寻址 | 串行总线上的从站地址，常用范围为 1–247 | IP 地址 + TCP 端口；单元标识常用于网关后的设备路由 |
| 报文边界 | 依靠 RTU 时序和静默间隔 | 依靠 MBAP 长度字段在 TCP 字节流中组帧 |
| 错误检测 | RTU 帧自带 CRC-16 | 不追加 RTU CRC，依赖 TCP/IP 和链路层机制 |
| 通信组织 | 一条串行总线通常由一个客户端顺序轮询 | 可建立多个 TCP 连接，实际并发能力取决于服务器实现 |
| 现场扩展 | 增加节点要处理地址、总线负载、布线和轮询周期 | 增加节点要处理 IP、交换机容量、连接数和网络规划 |
| 常用调试工具 | 串口工具、示波器、逻辑分析仪、RS485 测试仪 | ping、端口测试、Wireshark、Modbus TCP 客户端 |
| 典型故障 | A/B 线、串口参数、地址冲突、终端与偏置、CRC 错误 | IP 或端口错误、连接超时、网段或路由、防火墙、连接数不足 |
这张表还说明了一个重要边界：RS485 不等于 Modbus RTU，以太网也不等于 Modbus TCP。 RS485 只是常见的电气接口，设备完全可能在 RS485 上运行厂商私有协议；带网口的设备也可能只支持厂商协议、MQTT、OPC UA 或其他协议。选型前必须核对设备手册中的应用层协议。
哪些场景更适合 Modbus RTU
1. 仪表和传感器集中在同一现场
温湿度、压力、流量、电能等仪表常见 RS485 接口，数据变化相对缓慢，采用总线方式连接多台设备比较经济。客户端按计划轮询，就能满足监测和报表需求。
典型场景包括：
- 控制柜内的多台电表和保护器
- 大棚、冷库或机房中的环境传感器
- 泵房中的流量计、压力变送器和变频器
- 老旧设备加装 RS485 通信模块后的联网改造
2. 现场已有成熟的串行总线
如果现有设备、线缆和维护工具已经围绕 RS485 部署，继续使用 Modbus RTU 往往比更换全部设备更稳妥。可以在总线出口增加 DTU 或边缘网关，把现场报文送到 ThingsCloud。
3. 数据量不大，成本与兼容性优先
RTU 并不适合用来传输图片或高频波形，但对于定时读取少量寄存器、远程修改阈值和控制继电器，它通常已经足够。真正需要计算的不是“理论最高速率”，而是一轮查询包含多少设备和报文、最慢从站需要多久响应，以及业务能接受多长的数据刷新周期。
哪些场景更适合 Modbus TCP
1. PLC、HMI 和上位系统已经接入工业以太网
现代 PLC 和控制器通常带有以太网接口。生产线已经部署交换机和结构化网络时，使用 Modbus TCP 可以复用现有网络，并通过 IP 地址管理不同设备。
典型场景包括：
- PLC 与 SCADA 或 HMI 之间的数据交换
- 多个控制柜或多条生产线的集中采集
- 楼宇自控、能源管理和分布式 I/O
- 需要与 MES、边缘服务器或工业网关交换寄存器数据的系统
2. 节点分散，后期扩展和维护更重要
TCP/IP 网络可以借助交换机、路由和光纤连接不同区域。新增设备时通常不必改动一整条串行总线，但要做好 IP 地址、VLAN、端口访问和连接容量规划。
3. 需要更高的轮询吞吐量
以太网带宽通常高于串口，一台客户端也可以连接多台服务器。不过，Modbus 仍然是请求 / 响应协议，设备的 CPU、最大连接数、并发事务数和寄存器处理速度都会限制实际吞吐量。不能只根据网口标称速率设计轮询周期。
很多项目的答案不是二选一，而是混合架构
复杂现场常见这样的分层方式：
RS485 仪表 / 传感器
↓ Modbus RTU
DTU、PLC 或边缘网关
↓ 以太网 / 4G / WiFi
ThingsCloud、SCADA 或业务系统
现场层继续使用成本低、设备选择多的 Modbus RTU，上层网络则使用 Modbus TCP、MQTT 或平台接入协议。网关负责链路转换、报文透传或边缘轮询。这样既保护已有设备，也能把不同区域的数据接入统一平台。
需要注意的是，“Modbus RTU 转 Modbus TCP”不一定等于“设备已经安全上云”。网关完成的是协议与网络转换，公网访问、设备身份、访问控制和加密仍需单独设计。不要直接把 PLC 或网关的 502 端口暴露到公网；跨区域访问应结合网络隔离、防火墙、VPN 或其他受控链路。
用 6 个问题完成项目选型
在设备采购和方案设计阶段，可以按以下顺序判断：
- 设备已经提供什么接口？ 只有 RS485 / RS232 时优先评估 RTU，原生提供以太网和 Modbus TCP Server 时再评估 TCP。
- 节点如何分布？ 同一控制柜或连续总线上的仪表适合 RTU，跨控制柜、楼层或生产线时 TCP/IP 网络更易扩展。
- 一轮轮询要读多少数据？ 根据设备数、寄存器组、响应时间和超时策略估算完整轮询周期，不要只比较标称带宽。
- 现场已有哪套基础设施？ 已有稳定 RS485 总线就不必为追求“新协议”全部更换；已有工业以太网则应评估复用交换机和网络管理能力。
- 谁负责长期维护？ RTU 更依赖接线和串口排查经验，TCP 更依赖 IP 网络、连接和安全策略维护。
- 是否需要混合接入？ 现场设备类型较多时，优先设计网关边界，明确哪一侧使用 RTU、哪一侧使用 TCP/IP 或平台协议。
可以把结论简化为：
- 设备集中、接口以 RS485 为主、数据量较小、成本敏感：优先考虑 Modbus RTU。
- 设备分散、已有工业以太网、需要扩展和集中维护：优先考虑 Modbus TCP。
- 老旧仪表与新 PLC 并存、需要接入云平台：优先考虑 RTU + 网关 + IP 网络的混合架构。
落地时最容易忽略的 5 个问题
1. 寄存器编号和报文地址差 1
部分设备手册把第一个保持寄存器写作 40001，但 Modbus PDU 中的实际起始地址可能是 0。配置时要区分手册中的逻辑编号和报文中的协议地址，并以厂商给出的报文示例验证。
2. 多寄存器数据的字节序不一致
Modbus 规定单个 16 位寄存器以高字节在前的方式传输，但 32 位整数或浮点数如何跨两个寄存器排列，设备厂商的实现可能不同。出现数值异常时，要同时检查数据类型、字节序、字序、倍率和单位。
3. RTU 只看软件配置，不看物理层
从站地址和寄存器填写正确，不代表 RS485 总线一定稳定。A/B 极性、手拉手拓扑、支线、终端电阻、偏置、屏蔽、接地和干扰都会影响通信。建议先用本地主站工具验证串口链路，再接入 DTU 和云平台。
4. TCP 只看网络连通，不看设备容量
ping 通、502 端口能连接，只能说明基础网络可达。还要验证服务器允许的连接数、并发事务数、请求超时和重连策略。高频轮询前应先做持续压力与断线恢复测试。
5. 把 Modbus 当成自带安全能力的协议
传统 Modbus RTU 和 Modbus TCP 都没有为设备身份认证、权限控制和业务数据加密提供完整机制。RTU 的封闭布线减少了远程暴露面，但不等于具备认证；TCP 便于组网，也同时扩大了网络攻击面。安全边界应由项目网络和接入架构补齐。
在 ThingsCloud 中继续完成实操
理解区别之后，最有效的下一步是分别完成一次 RTU 和 TCP 接入。ThingsCloud 官方文档已经提供了两条可直接操作的教程路径：
- RS485 / Modbus 设备通过 DTU 透传接入 ThingsCloud：从设备接线、DTU 上线、属性定义和寄存器配置开始，完成温湿度采集、继电器控制、查询任务和调试日志验证。
- 西门子 PLC S7-200 SMART Modbus TCP 接入 ThingsCloud：学习 PLC 运行 Modbus TCP Server、以太网 DTU 透传、保持寄存器与线圈读写，以及生成用户 App 界面。
如果需要先补充协议细节，也可以阅读：
总结
Modbus RTU 和 Modbus TCP 的核心数据模型相同，主要区别在传输与封装：RTU 面向串行链路，使用从站地址、CRC 和帧间时序；TCP 面向 TCP/IP 网络，使用 MBAP 头、IP 地址、端口和事务标识。
RTU 适合现场仪表、传感器和既有 RS485 设备，TCP 更适合带网口的 PLC、工业以太网和分布式系统。两者不是简单的升级替代关系。实际项目中，现场 RTU、边缘网关和上层 IP 网络组合起来，往往比强行统一成单一协议更容易实施和维护。
参考资料
关于 ThingsCloud
ThingsCloud 是新一代物联网设备统一接入平台，帮助企业在极短的时间内搭建个性化的物联网平台和应用，并适应不断变化的发展需求。目前广泛应用于制造、电力、能源、环境、农业、楼宇、家居、教育、交通、物流、自动化等领域。
ThingsCloud 可接入各类网关，传感器、执行器、控制器、通信模组、智能硬件等，实现数据采集、远程控制，数据分析、告警通知、智能联动。还可以零代码生成项目应用 SaaS 和用户应用 App，并开放 API 和实时消息，便于业务系统集成和扩展开发。
通过使用 ThingsCloud，企业可以大大缩短搭建物联网系统的时间，节省软件开发费用，降低定制开发的风险，快速落地数字化和智能化项目。我们的客户遍布各行业，包括中国石化、中国铁塔、中国燃气、吉林大学、北控水务、ACE、中国民航大学、西安交通大学、精量电子、大秦铁路、宁波水利局等。
