Modbus RTU 和 TCP 到底差在哪？这次终于讲明白了
假设甲方甩来一句话：”我们要采集 200 台设备的数据，你看着用 RTU 还是 TCP。”
心里咯噔一下——这俩我都知道，但真要二选一并说出个所以然，还得回去翻资料。折腾了两天，把两者的差异从物理层到协议层捋了一遍，终于敢拍板了。
这篇就把这次搞明白的东西写下来。下次再有人问你 RTU 和 TCP 怎么选，直接甩这篇过去。
一、一张表先看全貌
| 对比维度 | Modbus RTU | Modbus TCP |
|---|---|---|
| 物理介质 | 串口线（RS-485 / RS-232） | 以太网线（双绞线、光纤） |
| 通信速度 | 较慢（通常最高 115.2 kbps） | 极快（100M / 1000M 起步） |
| 数据打包 | 紧凑二进制帧，带 CRC 校验 | RTU 基础上加 MBAP 头，去掉 CRC |
| 网络架构 | 严格主从模式（单主多从） | 客户端-服务器模式（支持多客户端并发） |
| 设备数量 | 受限（一条总线 32~247 个） | 理论无上限（取决于 IP 网络规模） |
| 典型场景 | 电表、水表、传感器、变频器等底层仪表 | PLC 之间、SCADA 上位机、远程监控、大数据采集 |
表是死的，故事是活的。下面拆着说。
二、本质：RTU 是”单车道”，TCP 是”高速公路网”
Modbus RTU：一条线上排着队说话
RTU 跑在串口上，物理层是 RS-485（少数 RS-232）。它的工作方式像一条单车道公路：
- 总线上只能有一个主设备，剩下全是从设备（地址 1~247，地址 0 是广播地址——发给 0 的指令所有从站都执行，但都不应答）。
- 主设备发指令，从设备应答，轮询方式进行。
- 同一时刻只有一个设备在说话，其他都闭嘴等着。
这种方式的好处是简单、可靠、抗干扰强。坏处也明显——慢。115.2 kbps 已经是串口的天花板了，200 台设备轮一遍，光等待时间就够喝杯咖啡。
而且 485 总线标准上最多挂 32 个节点（带中继器能扩到 247），设备一多就得分段组网，折腾。
🔧 一个很关键但很少被提起的细节：Modbus RTU 用静默时间来做帧同步——帧与帧之间必须保持至少 3.5 个字符时间的静默（在 9600 bps 下大约 3.65ms），帧内部相邻字节之间不能超过 1.5 个字符时间。超过 1.5 个字符间隔，从站就认为这帧结束了，后半截会被当新帧处理。这就是为什么串口调试时偶尔收到”不完整的回应”——不是丢数据，是帧被提前切断了。
Modbus TCP：跑在以太网上的多车道
TCP 把 Modbus 搬到了以太网上，工作模式从”主从”变成了”客户端-服务器”：
- 设备是服务器，监听 502 端口。
- 任何客户端都可以并发发起请求。
- 多个控制中心能同时访问同一台设备。
这就像高速公路网——不光速度快（千兆起步），而且路口随便上下，谁要去访问哪台设备都行，不用排队。
设备数量理论上没上限，受限于 IP 网络规模。你想接 1000 台？没问题，组个局域网就行。
三、协议层：MBAP 头和消失的 CRC
这是技术上最有意思的地方。RTU 和 TCP 在协议帧上长这样（画个示意）：
RTU 帧：
[从站地址] [功能码] [数据] [CRC校验]
TCP 帧：
[MBAP头(7字节)] [功能码] [数据]
两个变化：
1. TCP 多了个 MBAP 头
MBAP 全称 Modbus Application Protocol header，7 个字节，拆出来长这样：
| 字段 | 字节数 | 说明 |
|---|---|---|
| 事务标识符 | 2 | 请求/响应对应的编号，客户端自增，用于匹配”这个响应对应哪个请求” |
| 协议标识符 | 2 | 固定 00 00，表示 Modbus 协议 |
| 长度 | 2 | 后面所有字节数（从单元标识符到数据结束） |
| 单元标识符 | 1 | 相当于 RTU 的从站地址，在串口转 TCP 网关场景下用来指定目标从站 |
理解这个最好的方式是想一下”Modbus TCP 网关”的场景。网关一头接 485 总线，上面挂了 10 个从站（地址 1~10），另一头接以太网。上位机通过 TCP 连到网关，怎么告诉网关”我要读地址 3 那个从站”？答案就是单元标识符填 3。网关把 MBAP 头剥掉，把剩余内容当 RTU 帧从地址 3 发出去。
RTU 不需要 MBAP，因为串口总线一次只有一个主站在说话，不会串。
2. TCP 把 CRC-16 去掉了
RTU 帧末尾带 2 字节 CRC-16（不是 CRC-32，那个更大更慢），用来验证数据完整。算法是 CRC-16-IBM（多项式 0x8005），对从站地址到数据末的所有字节计算。
TCP 为什么不要了？因为跑在以太网上，底下有 TCP/IP 协议栈层层把关——链路层有 FCS 校验，TCP 层有校验和。数据坏了，TCP 层自己重传，到不了应用层。
CRC 在 TCP 里是冗余的，去掉它反让帧更紧凑。这就是工程上的”别做底下已经做过的事”。
四、Modicon 是谁？插一段历史
聊 Modbus 绕不开 Modicon 这个名字。
Modicon（莫迪康）是个工业自动化品牌，和 Modbus 是父子关系——”Modbus” 这个词就是 Modicon + Bus（总线）拼出来的，字面意思是”莫迪康公司发明的总线协议”。
时间线是这样的：
- 1968 年，Modicon 公司造出世界上第一台 PLC。
- 1979 年，为了让自家 PLC 之间能通信，推出了 Modbus 协议。
- 后来 Modicon 被施耐德电气收购，现在 Modicon 还是施耐德旗下的 PLC 系列名（M580、M340 那些）。
有意思的是，Modbus 协议本身是开放、免费的，谁都能用。这反而是它后来能成为工业通信”普通话”的关键——要是施耐德捂着收授权费，早被踢出局了。
所以一句话：Modicon 是”爸爸”（品牌），Modbus 是它生的”孩子”（协议），RTU 和 TCP 是这孩子长大后穿的两套”衣服”——串口时代的旧衣服，和以太网时代的新衣服。
五、怎么选？三个判断标准
回到开头那个问题——200 台设备该用 RTU 还是 TCP？我的判断逻辑是这三条：
1. 设备本身支持什么？
这是硬约束。底层仪表（电表、水表、传感器）绝大多数只支持 RTU，因为它们成本低、没网口。高端 PLC、网关、SCADA 系统基本都支持 TCP。
200 台底层设备，如果都是 RS-485 接口，那只能用 RTU——除非你在中间加协议转换网关。
2. 速度要求高不高？
RTU 的 115.2 kbps 在轮询场景下确实吃力。如果你要毫秒级采集，或者数据量大，TCP 是唯一选择。
3. 是不是多点访问？
RTU 是单主模式，同一时刻只能一个主站问。如果两个 SCADA 系统都要读同一批设备，RTU 就抓瞎了，TCP 的多客户端并发正好解决这个。
开头那个假设的案例最后的方案是：底层设备用 RTU 串成几条 485 总线，每条总线接一个网关转 Modbus TCP，再统一接到上位的 SCADA。这样既保留了 485 的布线优势，又享受了 TCP 的并发和速度。这是工业现场最常见的”混合打法”。
🔧 调试小贴士：
- RTU 抓包：用逻辑分析仪或带抓包功能的 USB 转 485 模块（有些 FT232 方案的软件支持）。实时看总线上的原始十六进制帧，地址、功能码、CRC 一目了然。
- TCP 抓包：直接用 Wireshark，显示过滤器填
tcp.port == 502，就能看到所有 Modbus TCP 请求和响应。Wireshark 内置了解析器，会自动把 MBAP 头、功能码、数据段拆好，比自己手动看省事多了。
六、收个尾
RTU 和 TCP 不是替代关系，是互补关系。
RTU 守着底层——便宜、抗造、布线省，传感器和仪表的天下。TCP 占着上层——快、能并发、能远传，PLC 和 SCADA 的主场。中间用网关把两边连起来，这就是现代工业网络的典型架构。
下次再有人问你”用 RTU 还是 TCP”，别急着二选一，先问一句——你这设备在网络的哪一层？
这是 Modbus 系列的最后一篇。整个系列从地址、功能码、串口到 RTU/TCP，把 Modbus 调试里最常踩的坑都过了一遍。希望对你有帮助——哪怕只是让你少走两天弯路，我写这些也就值了。
系列文章： 1. Modbus地址的那个”5位数密码” 2. 8个功能码，干完90%的Modbus活儿 3. RS485凭什么在工厂里横着走 4. Modbus RTU 和 TCP 到底差在哪（本文）
