Modbus TCP报文解析：从抓包第一帧开始，真正看懂工业以太网的“心跳”
你有没有过这样的经历？
HMI界面上温度值突然变成0或65535，PLC日志里却只写着“通信正常”；Wireshark里明明看到一串发出去的0x03请求，但响应迟迟不来，重试三次后连接直接断开；更头疼的是——换一台同型号仪表，同样的配置就能通，换另一台就死活没反应……
这些不是玄学，是Modbus TCP报文在说话，而你还没学会听。
它不像HTTP有浏览器开发者工具帮你展开 headers，也不像MQTT有现成的客户端库自动处理重连和QoS。Modbus TCP 极简、裸露、一字一节地躺在TCP流里，既给了你最大控制权，也把所有责任都交到了你手上：地址错一位、字节序颠倒一次、Length字段少算一个字节，整帧就废。
这篇文章不讲概念堆砌，不列标准文档原文，不假设你懂OSI七层模型——我们直接打开Wireshark，从你今天下午刚抓到的第一帧开始，一行一行解剖，手把手带你把Modbus TCP从“能连上”变成“看得透”。
你真正需要理解的五个字节：不是协议，是设备间的呼吸节奏
Modbus TCP报文总共7字节固定头 + 可变PDU，但真正决定通信成败的，其实是前6个字节里的四个关键字段。它们不是冷冰冰的定义，而是设备之间建立信任、确认身份、约定节奏的“握手暗号”。
| 字段名 | 长度 | 典型值 | 它到底在干什么？ |
|---|---|---|---|
| Transaction ID | 2字节 | 0x1a2b | “我是第几次找你？”——客户端发请求时打上的唯一编号，服务器原样还回来。不是计数器，不是时间戳，就是个“请对号入座”的标签。 |
| Protocol ID | 2字节 | 0x0000 | “我说的是人话，不是乱码。”——强制校验位。不是0x0000？服务器直接丢包，连错误响应都不发。这是Modbus TCP的“身份证验证”。 |
| Length | 2字节 | 0x0006 | “后面还有6个字节，别多读，也别少等。”——TCP是流水账，没有消息边界。这个字段就是你的尺子，量出Unit ID和PDU一共多长。少读1字节，PDU就残了；多读1字节，下一帧就错位。 |
| Unit ID | 1字节 | 0x01或0xff | “我找的是你，不是隔壁老王。”——在纯TCP网络中，它常常被当成摆设。但一旦中间插了个Modbus网关（比如把TCP转成RS485），它就成了后端多个RTU设备的“门牌号”。 |
