Modbus RTU over TCP与Modbus TCP：接入前识别帧格式

TCP连接成功，不代表两端采用同一种Modbus帧格式。一端可能等待MBAP头，另一端却发送包含CRC的完整RTU报文。两个产品都写着“以太网Modbus”，仍然可能互相无法解析。调整波特率、寄存器偏移或重试次数之前，应先确认线上应用数据单元究竟长什么样。

本文依据应用协议V1.1b3、TCP实现指南V1.0b及串行规范V1.02。这里的“RTU over TCP”指厂商文档明确规定的RTU字节隧道；这个名称本身并不足以构成完整、可互操作的传输规范。

先要报文字节，不只要协议名称

收集客户端配置、网关工作模式、固件版本及一组有文档依据的请求与响应。明确询问TCP负载是否从MBAP开始、是否包含串口从站地址、是否带CRC，以及是否还有私有前缀。两个方向都要检查，网关可能同时转换请求和响应。

端口号可以帮助确认配置，但不能单独证明负载格式。五百零二端口与Modbus TCP有关，产品也可能提供可配置服务。抓包软件选中的解码器同样只是解释方式，不是设备配置正确的独立证据。保存解码结果时，应保留原始十六进制字节。

Modbus PDU由功能码和功能数据组成。RTU ADU在前面添加从站地址，在后面添加两字节CRC；Modbus TCP ADU则在前面添加七字节MBAP头，不再附加RTU CRC。边界可查应用协议第4.1节及TCP实现指南第3.1节。

接口命名要准确。如果把整个RTU帧都叫作PDU，转换程序就可能错误保留地址和CRC，而本应只保留功能码与数据。标准PDU最大为二百五十三字节，RTU ADU最大二百五十六字节，TCP ADU最大二百六十字节。厂商隧道另加的头部必须单独描述，不能混进这些上限。

假设从单元一读取线地址零处的一个保持寄存器，PDU为03 00 00 00 01。若TCP事务ID为0x002A，完整请求为00 2A 00 00 00 06 01 03 00 00 00 01。长度字段是六，因为它计算单元标识加五字节PDU，而不是整个十二字节ADU。

相应RTU请求为01 03 00 00 00 01 84 0A。CRC在线上低字节先发，依据串行规范第2.5.1节及附录B。末尾两个校验字节属于RTU封装，不应追加到前述TCP请求；TCP事务ID也不能被当作串口站号。

优先使用模拟器，或已确认允许读取目标寄存器的隔离设备。有些厂商对象读取后会清除状态，因此“使用读功能码”仍不能代替查阅寄存器语义。抓取之前先记录单元、线偏移、数量和预期响应类型，避免看到报文后再倒推测试意图。

分别保存两个方向的TCP应用字节流；若现场有获准使用的分析设备，再独立抓取网关串口输出。对于协议转换网关，两侧完整字节序列本来就应不同。比较重点是共同PDU和地址映射，而不是要求整帧逐字节相等。配置文件要与抓包放在一起，后续才能重现结论。

一次应用消息可能分成多次读取交付，多个消息也可能合并到一次读取。Modbus TCP通过MBAP长度辅助确定应用边界。对于原始RTU字节隧道，接入契约必须说明接收方如何确认消息结束、如何保留不完整数据，不能把以太网包边界当作RTU分隔符。

透明字节流也不等于保留串口原始字符间隔。主机两次读取之间的停顿可能来自缓冲，而不是串口线上的静默。本文方法用于识别字节封装，不用于证明RTU时序合规；如果产品要求保留时序，应另行在串口边界定义并验证。

等待MBAP的一端可能把RTU字节解释成非法协议标识或异常长度；原始隧道另一端也可能把MBAP头直接转发到串口，结果没有从站返回有效响应。必须用实际字节验证这些假设，不能把所有超时都归因于格式错误。

建议显式选择协议模式。收到一个畸形消息就自动尝试另一种格式，对写操作尤其危险，因为另一种解释可能变成不同的有效命令。识别探测应无副作用，缓冲长度应受限，向真实设备转发新解释的格式之前，应通过受控配置变更确认。

验收结论应是“这些字节符合这项配置”，而不是仅仅“端口能连接”。一个有效例子只能确认当前交换，不能证明支持所有功能，也不能证明厂商寄存器语义，更不能让私有RTU隧道自动等同于标准Modbus TCP。