2.2 传输层变种详解

2.2 传输层变种详解

本节摘要：Modbus 有 RTU、ASCII、TCP 三个传输变种，事务模型完全相同，帧封装与载体完全不同。本节给出三者的帧结构对照、选型判断，以及最容易踩坑的 MBAP 报文头逐字段解析。

先给结论

三个变种的分工一句话就能说清：**RTU 跑串行链路，效率优先；ASCII 跑串行链路，可读性优先，如今只活在老系统里；TCP 跑以太网，把串行帧拆掉头尾、套上 MBAP 头重新封装。**选型几乎不需要犹豫——新设计的串行链路一律 RTU，以太网链路一律 TCP，ASCII 只在维护遗留系统时才会遇到。但维护遗留系统恰恰是很多工程师的日常，而且 TCP 那个看似简单的 MBAP 头藏着端口、事务标识、单元标识符几个高频误解点，值得逐字段过一遍。

学习目标

阅读完本节，你应当能够：

1. 画出 RTU、ASCII、TCP 三种帧的结构并指出差异所在；
2. 逐字段解释 MBAP 报文头，说清事务标识与单元标识符各自的用途；
3. 根据链路条件（带宽、距离、已有设备）选择合适的变种与参数；
4. 解释网关场景下"单元标识符承载从站地址"的透传惯例。

一、RTU 与 ASCII：同一条线上的两种性格

RTU 与 ASCII 共享同一套功能码与数据模型，差异全部在帧封装上。RTU 把数据按原始字节传输，帧尾用两字节 CRC 兜底；ASCII 把每个字节拆成两个 ASCII 字符传输，帧以冒号开头、回车换行结尾，校验用简单的 LRC 纵向冗余校验。同样读两个寄存器，RTU 帧八个字节就完事，ASCII 帧要膨胀到二十多个字符，效率差了三倍不止。

那 ASCII 图什么？图一个"看得见"。早期调试没有像样的串口分析工具，工程师用终端软件直接看链路上的字符，ASCII 模式下报文就是一行可读文本，哪个环节断了肉眼可见。RTU 的原始字节在终端里则是一串乱码。这个历史优势在今天已经没有意义——抓包工具随手可得，RTU 的字节照样能逐个解出来——但 ASCII 的帧格式作为知识还值得留着，因为你迟早会接手一台只说 ASCII 的老仪表。

RTU 的帧定界方式特别值得琢磨：它不用任何起止字符，靠的是静默——总线上静默超过三点五个字符时间，就认为上一帧结束、下一帧尚未开始。这意味着 RTU 对时序的依赖极重，两个字节之间若因干扰卡顿超过了静默窗口，接收方会把一帧拆成两半理解，CRC 自然报错。现场所谓"RS-485 抗干扰其实挺脆弱"，多数时候是时序被破坏，不是电平被拉偏。这一特性也决定了 RTU 设备的固件在中断处理上必须干脆利落，慢半拍的接收中断就会制造帧错位。

二、TCP 封装与 MBAP 头

以太网没有"静默定界"的土壤，TCP 是字节流协议，本来就不存在报文边界，所以 Modbus TCP 给每帧加了一个七字节的头，称为 MBAP（Modbus Application Protocol）头，用其中的长度字段显式划界。结构如下：

MBAP 头七字节 + PDU，一次完整读取的拆解

a5 31 | 00 00 | 00 06 | 01
  │       │       │      └── 单元标识符：网关背后是几号从站
  │       │       └───────── 长度字段：其后还有六个字节
  │       └───────────────── 协议标识符：恒为 0（Modbus 协议）
  └───────────────────────── 事务标识符：主站随机赋值 用于匹配应答

00 03 | 00 64 | 00 02
  │      │      └── 寄存器数量 2
  │      └───────── 起始地址 0x0064 即 100
  └──────────────── 功能码 03 读保持寄存器
​

三个字段各有一个高频误解。事务标识符：并发多个请求时，应答可能乱序返回，客户端靠它把应答与请求配对；许多简易主站永远填 0，单请求轮询场景没问题，一旦上并发就会张冠李戴。协议标识符：恒为 0，非 0 值属于其他派生协议，见到非 0 要警惕对端说的不是标准 Modbus。单元标识符：这是误解重灾区——纯以太网设备直连时它通常填 255 或 0，但在"TCP 网关转 RTU 总线"的透传架构里，它承载的正是背后串行总线的从站地址。网关收到请求后剥掉 MBAP 头，把单元标识符填进 RTU 帧的地址字节发上总线。排错时若发现网关后所有从站都无响应，先检查客户端是不是把单元标识符写死了 255。

三、变种演化与选型边界

三个变种的出现顺序对应着链路技术的演化：串行时代先有 ASCII（照顾人眼）后有 RTU（照顾效率），以太网普及后 TCP 吸收了主力角色。演化方向始终是"更高效、更少依赖人工目视"，理解这条线，你就理解了为什么新规范不再扩展 ASCII。

图6 三个传输变种的演化时间线与适用地带

选型边界的最后一块拼图是链路距离与速率的权衡。RS-485 在 9600 波特率下跑上千米没有问题，提到 115200 则要把距离压到几百米以内；以太网百米为限，超了要加交换机。改造老厂时常遇到"想上 TCP 但拉不了网线"的区段，串行 RTU 加无线串口服务器的组合是常见的折中——注意无线链路会放大 2.1 节讲过的时序问题，静默间隔可能被无线抖动破坏，这类链路上的超时参数要放得更宽。

💡 关键直觉：三个变种共用同一个"事务大脑"（2.1 的事务模型），差异只在"嘴和耳朵"。排错时先把链路层问题（变种相关）与应用层问题（功能码与地址相关）分开，就不会拿着 Wireshark 去查波特率配置错误这类乌龙。

四、变种混用的边界：网关两侧各自的规矩

现实项目里三个变种常常共存于一台网关的两侧，边界纪律值得单独交代。串行侧只允许一种变种——RTU 与 ASCII 设备物理上可以共线吗？规范上帧封装不同不能混传，但有些网关支持按从站地址区分两种封装分别转发，这类"混线"设计能跑却把排错难度翻倍：抓包窗口里两种帧交错，CRC 与 LRC 两套校验混杂。除非预算真的不支持新增一条总线，不要为省一根线缆引入混线架构。

TCP 侧的边界纪律是端口与单元标识符的语义要成文：多台网关并联时，每台的单元标识符规划（哪些从站号映射到哪台网关）必须有台账，否则两台网关背后都有 3 号从站时，客户端一次寻址命中哪台全凭网线插法。这类问题在 4.1 的容量规划里会再遇到一次——边界纪律的本质，是把"约定"从工程师脑子里搬到文档里。

本节要点回顾

• 三变种一句话：RTU 效率优先跑串行，ASCII 可读性优先已成遗留，TCP 跑以太网靠 MBAP 定界；
• MBAP 三字段：事务标识管并发配对、协议标识恒 0、单元标识符在网关场景承载从站地址；
• RTU 靠静默定界：字节间卡顿超过三点五字符时间就帧错位，"抗干扰差"多数是时序被破坏；
• 链路权衡：RS-485 距离与速率成反比，无线串口链路要放宽超时并警惕时序抖动。

帧与链路都清楚了，下一节解决另一个基本功：点表上的地址到底怎么对应报文里的字节。