★ FEATURED ARTICLE 1. 先搞清楚ModbusTCP为什么会出现分片做嵌入式的人大概都遇到过这种场景设备在现场跑得好好的突然某一次上位机下发读写指令控制器这边却怎么都响应不了或者返回的报文错位、校验失败查来查去最后发现是TCP数据被拆开送了。我早期做ESP32网关项目时也在这个问题上栽过跟头。当时以为是网线干扰、对端设备故障折腾了大半天最后用Wireshark抓包一看一条完整的ModbusTCP请求被拆成了3个TCP段第一个段只有MBAP头部的7个字节第二个段带着半个PDU第三个段才把尾部补齐。ESP32端如果按“来一次中断读一次读完就解析”的思路处理必然出事。为什么会出现这种分片这里得先明确一个概念ModbusTCP的报文边界是由设备应用层定义的而TCP本身是字节流协议。ModbusTCP在TCP协议栈看来就是一堆连续字节没有任何“这条消息在这里结束、下条消息从哪里开始”的标记。发送方操作系统的TCP/IP协议栈会根据MSS最大分段大小、窗口变化、Nagle算法等因素决定每个TCP报文段实际承载多少字节。ModbusTCP请求大一些比如写多个寄存器、读大文件区或者网络路径MTU有限制时一个完整的请求被拆成多个TCP包是常态。同时还有另一种反方向的情况粘包。上位机连续下发多条指令TCP协议栈可能把两三个请求合并进同一个报文段里ESP32端读完一次缓冲区里躺着好几条完整的ModbusTCP帧。所以在这个领域业界一直推荐一个处理原则收到TCP数据先进缓存不急着解析等缓存里的字节足够组成完整帧再取出来用。// ModbusTCP请求帧最小长度MBAP功能码至少1字节数据 #define MBAP_HEADER_LEN 7 #define MODBUS_MIN_REQ_LEN (MBAP_HEADER_LEN 1)在编写ESP32的ModbusTCP网关、数据采集器或者从站控制器时TCP客户端/服务器每次接收到的数据长度是动态的。如果直接拿本次接收的数据去解析一旦遇到分片就漏掉部分字段数据错位、长度校验失败都是很常见的事。所以分片缓存并不是什么高端技巧而是一个必须有的基础模块。这里要顺带说一个容易混淆的地方ModbusTCP和ModbusRTU在分包逻辑上有些相似RTU靠3.5个字符时间的静默来切分帧ModbusTCP则完全依赖MBAP头里的“长度”字段。以下是我拆解ModbusTCP报文时习惯用的结构字段长度字节说明事务处理标识符2请求/响应对应标识大端序协议标识符2ModbusTCP固定为0x0000长度字段2后面所有字节的总长度单元IDPDU单元ID1从站地址功能码1读线圈、写寄存器等操作码数据体NPDU数据部分重点就是那个“长度字段”它是判断缓存是否攒够一条完整帧的唯一可靠依据。你要根据这个字段当前的数值再减去已收到字节数算出还有多少字节没到而不是傻等或者乱拼。2. 分片缓存的关键设计环形缓冲区与状态机明白了原理实际动手写缓存模块时还有个设计问题需要先想清楚用什么数据结构来暂存TCP接收到的数据。ESP32内存不像PC那么宽裕虽然不同型号SRAM大小有差异但嵌入式设备上做通信缓存还是要省着用。我个人不推荐用边长动态数组频繁做append操作不仅耗时时间长了还会产生内存碎片。更稳妥的做法是实现一个环形缓冲区Ring Buffer或者叫循环队列。在ESP32上我还推荐用FreeRTOS的消息队列配合信号量但缓存放数据、应用取数据这种场景环形缓冲区表现更好因为它是“留一块连续内存读写指针循环移动”不需要反复分配释放内存。2.1 环形缓冲区的实现要点环形缓冲区本身不复杂核心元素就三个存放数据的数组、写索引写入位置、读索引读取位置。实现时注意两个容易出错的地方第一缓冲区空和满的状态要能区分。如果只用读索引和写索引相等来表示“空”那“满”时也有可能出现读写索引相等这就混淆了。通常的做法是让缓冲区最多存size - 1个字节用“写索引1等于读索引”表示已满或者额外维护一个计数变量记录当前已用字节数。计数的方式直观些省得每次判断边界都做取余运算。第二专门为缓存模块提供两个基础接口写入接口从TCP接收通道拿到数据放进环形缓冲区和弹出接口从缓冲区取出一段连续的完整帧。弹出一段帧后要考虑跨回绕的情况——缓冲区末尾放不下完整帧时需要分两段读取或者先拷贝到临时数组。我实际项目里用的是定长数组缓冲区大小设为MODBUS_TCP_RX_BUFFER_SIZE。官方对ModbusTCP PDU没有设定特别夸张的上限但应对批量读写寄存器比如一次写120个寄存器数据体就有240字节加上MBAP头整帧也就250字节上下。为了留足余量我可以把缓冲区开成1024字节再配合一个“待处理帧”的结构体做解析。// 一个极简实现思路 #define RING_BUFFER_SIZE 2048 typedef struct { uint8_t buffer[RING_BUFFER_SIZE]; volatile uint16_t head; // 写位置 volatile uint16_t tail; // 读位置 volatile uint16_t count; // 当前缓存的字节数 } ring_buffer_t; int rb_write(ring_buffer_t *rb, const uint8_t *data, uint16_t len); int rb_read(ring_buffer_t *rb, uint8_t *data, uint16_t len);2.2 解析状态机从“盲读”变成“等完整帧”环形缓冲区解决了“数据放哪”的问题接下来核心问题是“缓存里的数据什么时候算一条完整帧”我的做法是引入一个简易状态机把接收解析流程分成四个步骤状态一等待MBAP头。检查缓冲区可读字节数是否≥7不够就继续等不触发解析动作。状态二读取MBAP头中的长度字段。注意大端序取出两个字节后按16位组合得到后续字节数。状态三等待PDU完成。已收到的长度total_need 7 pdu_len如果缓冲区可读字节数还没达到这个值继续攒。状态四完整帧已就绪。从缓冲区连续取出total_need字节交给ModbusTCP业务处理函数。状态机的关键点在于每个状态都只做“判断等待”两件事绝不因为本次没读到完整数据就丢弃已有的缓存数据。// 伪代码描述状态机 typedef enum { RX_STATE_WAIT_HEADER, RX_STATE_WAIT_BODY, RX_STATE_FRAME_READY } modbus_rx_state_t;说起来简单但很多人第一次实现时容易犯的错是取长度字段时只看了第一个字节或者没考虑到长度字段本身也可能被分片比如MPAB头的后两个字节跑到了下一个TCP段里。这些情况在弱网环境、网关转发链路上很常见所以状态机能用上就给用上不要怕多几行代码。3. 在ESP32上实现缓存模块的核心代码这部分直接贴我用过的模块。虽然我用的开发框架是ESP-IDF但思路移植到Arduino框架也完全可行Arduino的WiFiClient接收数据同样是“来多少读多少”所以把下面这段代码的接收入口换成client.read()即可。3.1 接收入口把TCP数据灌入缓冲区我用的是事件驱动任务处理的模型。ESP32上建议开一个独立任务专门处理ModbusTCP通信modbus_tcp_taskWiFi/TCP栈收到数据后通过xQueueSendFromISR投递一个事件任务里再调用rb_write把收到的TCP数据写入环形缓冲区。// WiFi/以太网事件回调中把接收到的数据写入环形缓冲区 static void on_tcp_data(void *arg, esp_event_base_t base, int32_t event_id, void *event_data) { // event_data里是收到的tcp payload长度和指针 modbus_tcp_netif_data_t *net (modbus_tcp_netif_data_t *)arg; // 写入环形缓冲区 rb_write(net-rx_rb, (uint8_t *)event_data, payload_len); // 通知解析任务“有数据可处理” xSemaphoreGive(net-rx_sem); }注意事件回调里尽量不要做耗时处理。绝对不要在回调里直接调memcpy大块数据的同时还去解析——应该只把它当成“搬砖进仓库”的角色解析的事情交给后面的任务。3.2 解析任务状态机的完整实现下面是典型的状态机代码。我写的版本更偏工程化把等待头部、等待数据块、帧就绪都揉进了一个while循环里。// 状态机核心函数不断从环形缓冲区取字节判断 modbus_err_t modbus_rx_process(modbus_conn_t *conn) { ring_buffer_t *rb conn-rx_rb; uint8_t tmp[8]; while (1) { switch (conn-rx_state) { case RX_STATE_WAIT_HEADER: // 至少要MBAP头7字节 if (rb_get_used(rb) MBAP_HEADER_LEN) { return MODBUS_ERR_WAITING; } // 一次性读出7字节然后留在解析缓冲中 rb_read(rb, tmp, MBAP_HEADER_LEN); conn-rx_transaction_id (tmp[0] 8) | tmp[1]; conn-rx_protocol_id (tmp[2] 8) | tmp[3]; conn-rx_length_field (tmp[4] 8) | tmp[5]; conn-rx_unit_id tmp[6]; if (conn-rx_protocol_id ! 0x0000) { // 非ModbusTCP协议标识复位 conn-rx_state RX_STATE_WAIT_HEADER; return MODBUS_ERR_PROTOCOL; } conn-rx_pdu_len conn-rx_length_field - 1; // 扣除单元ID conn-rx_need_len MBAP_HEADER_LEN conn-rx_length_field; conn-rx_state RX_STATE_WAIT_BODY; break; case RX_STATE_WAIT_BODY: if (rb_get_used(rb) conn-rx_need_len) { // 攒的不够先返回等待更多数据 return MODBUS_ERR_WAITING; } // 帧已完整取出整个帧交给上层解析 uint16_t frame_len conn-rx_need_len; if (frame_len conn-rx_frame_buf_size) { conn-rx_state RX_STATE_WAIT_HEADER; return MODBUS_ERR_TOO_LARGE; } conn-rx_state RX_STATE_WAIT_HEADER; // 把完整帧数据取出内部会处理环形区回绕 rb_read(rb, conn-rx_frame_buf, frame_len); conn-rx_frame_len frame_len; // 这里交给ModbusTCP业务逻辑处理 modbus_handle_frame(conn); break; default: conn-rx_state RX_STATE_WAIT_HEADER; return MODBUS_ERR_STATE; } } }上面这段代码里有几个细节值得强调rx_length_field - 1长度字段包含单元IDPDU。我要的是PDU长度所以减掉单元ID的1个字节。等计算PDU剩余等待字节时依据是rx_length_field - 1。rb_read返回后状态直接切回WAIT_HEADER。这是为下一条指令做好准备也天然支持了处理粘包——如果缓冲区里还有剩余数据下次循环会立即进入新的帧解析。校验协议标识符为0x0000这是ModbusTCP规范强制要求的。很多设备不检查这一项遇到非标准包时表现奇怪加了这一道关卡之后至少能快速丢弃错误帧。3.3 超时保护防止缓存拖死系统分片缓存最容易被人忽略的就是超时。设想一下对端设备发了一个分片第一段到了后面几个TCP段因为网络问题一直没到ESP32端如果一直等这个连接上后续其他请求都会被堵住。我在实际项目里给状态机加了一个超时计数器。当状态停留在RX_STATE_WAIT_BODY的时间超过100ms就自动清空缓冲区、把连接状态恢复到WAIT_HEADER同时上报一次超时统计。一般用esp_timer_get_time()微秒级时间戳来获取当前时间在进入WAIT_BODY时记录rx_begin_time每次循环比对当前时间与开始时间差值超过MODBUS_RX_TIMEOUT_MS就直接清场。#define MODBUS_RX_TIMEOUT_MS 100 int64_t now esp_timer_get_time() / 1000; if (now - conn-rx_begin_time MODBUS_RX_TIMEOUT_MS) { // 清空本次缓存 rb_reset(conn-rx_rb); conn-rx_state RX_STATE_WAIT_HEADER; // 统计超时次数 conn-timeout_cnt; }超时值选多少合适不能太短因为ModbusTCP允许多个请求连续发起数据包在公网传输也可能有几十毫秒延迟又不能太长不然异常情况下恢复太慢。100ms是我在多个项目里验证过的折中值——局域网模式下一帧完整数据的到达时间通常不超过20ms公网模式下只要不是特别烂的链路100ms也足够等待最后一个分片了。4. 分片缓存的调试方法与实测验证代码写完不能只在脑子里过一遍流程就上线。TCP分片是需要实测验证的而且验证手段不少。这里分享我常用的三个方法从简到难排个序。4.1 用Python脚本模拟分片攻击本地起一个小工具把ModbusTCP请求拆成多段每隔几毫秒发送一段验证ESP32端是否能完整拼出帧并响应。import socket import time # 构造一个功能码为0x10(写多个寄存器)的请求 # 假设事务ID0x0001单元ID0x01起始地址0x0000寄存器数量2(4字节) frame bytes.fromhex(0001 0000 0000 0006 01 10 0000 0002 04 0001 0002) s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((192.168.1.100, 502)) # 人工分片把15字节的frame拆成3段 s.send(frame[:3]) time.sleep(0.01) s.send(frame[3:9]) time.sleep(0.01) s.send(frame[9:])这里用sleep模拟分包发送是为了测试接收逻辑对“拆分”的容错性。如果你的ESP32端没有实现分片缓存直接解析就会丢数据实现了缓存这段逻辑会正常返回响应。实际验证时还可以把中间某个片段故意拖到100ms以上验证超时清理是否生效。4.2 Wireshark抓包确认网络层面分片真正的TCP分片不一定由应用层软件主动控制更多是协议栈在后台做的。想确认某个特定报文是否发生了TCP分段抓包是王道。在电脑上开Wireshark抓包找到向ESP32发起的ModbusTCP请求。过滤条件可以用tcp.port 502也可以结合IP地址过滤。展开一个请求后看TCP分段的序列号和Len字段如果发现一条逻辑请求被拆成了多个[TCP segment of a reassembled PDU]那就是网络层面的分片行为。这种时候应用层代码无法直接感知网络分片唯一能做的就是依赖缓存和状态机。Wireshark主要用来辅助确认“我设计的缓存是不是覆盖了真实场景”而不是去阻止协议栈分片——那是做不到的也没必要做。4.3 多Client并发压力测试实际项目里经常出现一个ESP32网关带多个ModbusTCP从站或者同时被多个上位机访问的场景。每条TCP连接都对应独立的缓存和解析状态机不能共用一把锁、一份缓冲区。所以我在模块设计时给每个连接分配独立的modbus_conn_t结构体里面自带环形缓冲区rx_rb和状态变量。并发测试我做的方法很简单电脑上开三个线程每个线程模拟一个ModbusTCP Client持续循环下发不同长度的读写请求读单个线圈、写多个寄存器、读保持寄存器运行一晚上看异常响应率。调测前我特意跑了一个bug复现版本——共用一个全局缓存三个客户端同时请求时响应错乱率肉眼可见改成每连接独立缓存后跑了两天一夜零错误。这个测试也给我一个启发缓存的隔离性和缓存本身一样重要。5. 工程现场踩过的分片坑以及给后来者的建议最后把我这几年碰到过的、容易让工程师在这块栽跟头的坑挑几个有代表性的整理成清单。坑一直接把接收到的数据当完整帧解析不做长度判断。这个是最常见的错法。TCP每次回调收多少字节完全不可控可能收5字节也可能收100字节。不判断长度就解析一旦分片就错位。坑二解析完下一条帧时忘了处理粘包。很多人的实现是“收到数据解析一条剩余字节丢掉”。如果对端一次发送多条指令丢掉的字节里可能包含另一条完整的请求导致后续响应错乱。正确处理方式是解析完一条帧后继续检查缓冲区里还有没有可解析的完整帧——这正好是状态机天然支持的。坑三MBAP头里读长度字段时没有考虑“长度字段本身被分片”。比如MBAP头7字节中前5字节在一个TCP段后2字节在下一个TCP段。状态机的WAIT_HEADER状态其实已经处理了这种情况——先等满7字节再取长度字段。但如果你的实现是“读够5字节就取长度”就会在这个边缘场景踩雷。坑四重启连接时忘了清空缓冲区。ESP32做TCP Server时如果某个Client异常断开、重连老连接缓存里的残留数据如果不清理新连接会解析出脏帧。每建立一个连接都要对这个连接的缓存和状态机做一次初始化。坑五在中断或事件回调Thread里做阻塞式解析。ESP32虽然支持多任务但TCP事件回调里不应该做耗时处理。我当时遇到过一个问题事件回调里直接调用解析一旦遇到粘包分片叠加解析耗时可能飙到几百微秒甚至毫秒级影响其他网络事件处理。后来改成投递信号量让独立任务去跑解析CPU占用反而更平滑了。给刚入门ESP32ModbusTCP的同行一些建议先从“单Client、单连接”的场景入手把缓存和状态机跑通不要一上来就整多连接并发。验证完分片缓存再引入粘包测试、超时测试最后再做多Client并发。每一步都有明确的可观测指标响应正确率、超时次数、内存占用这样排查问题时能快速定位是协议栈问题、缓存问题还是业务逻辑问题。如果你用的是Arduino框架代码结构有一些变化但思路一致。接收回调里做client.read把数据搬进缓存主循环里持续调用状态机处理函数即可。我见过有人直接用WiFiClient.available() read()判断长度也不失为一个轻量级方案但在强干扰、大并发的工业现场独立任务环形缓冲区状态机的方案会更可靠扩展能力也强。这是我自己在ESP32 ModbusTCP网关项目里踩过、修过、验证过的整套思路。网络通信永远没有玄学分片也好、粘包也罢只要数据先进完整缓存、按长度字段判断帧边界ModbusTCP通信就是稳的。
阅读完成 · 觉得有帮助？
