1. 从一次现场调试说起为什么ModbusTCP在ESP32上会“卡死”去年冬天我在一个配电柜改造项目里第一次被ESP32的ModbusTCP搞到怀疑人生。现场是一台ESP32-S3核心板跑着ModbusTCP从站上位机每200ms轮询一次寄存器数量不多也就四十来个。按理说这点数据量对ESP32来说连热身都算不上但实际跑起来每隔十几分钟就会丢一帧上位机报超时然后自动重连重连之后又能撑一阵。最开始我以为是WiFi信号问题换了天线、调了信道、把路由器挪到柜子旁边都没用。后来抓包才发现问题出在TCP分片上——上位机一次请求的报文被拆成了两个TCP段发过来而我的代码里默认“一次recv就是一整帧”第二个分片直接被当成新帧的头部解析整个缓冲区就乱了。这个坑其实非常典型。ModbusTCP虽然协议本身简单但它跑在TCP之上而TCP是字节流协议不保证你一次recv就能拿到完整的一帧。ESP32的LwIP协议栈在WiFi环境下MSS最大报文段长度通常只有1460字节一旦ModbusTCP的ADU应用数据单元超过这个长度或者网络抖动导致TCP分段分片就必然发生。更麻烦的是ModbusTCP的MBAP头里有一个Length字段它告诉你后面还有多少字节但如果你不主动做缓存拼接这个字段就形同虚设。所以这篇内容我想聊的不是“怎么跑通ModbusTCP”而是怎么在ESP32上把分片缓存这件事做扎实。适合已经能在ESP32上跑起ModbusTCP、但被偶发丢帧和粘包问题折磨的开发者也适合正在做工业网关、边缘采集终端的朋友。下面我会从协议本质、缓冲区设计、状态机实现、实测调优几个角度把这件事拆开讲透。2. ModbusTCP分片到底是怎么发生的协议层与网络层的双重真相2.1 MBAP头里的Length字段才是拼接的唯一依据很多人写ModbusTCP从站的时候习惯性地把recv到的数据直接丢给协议解析函数解析函数里假设buffer[0..6]是MBAP头buffer[7]是功能码然后按固定长度去读。这种写法在PC端以太网环境下可能跑几个月都不出问题因为以太网的MTU是1500MSS是1460而大多数ModbusTCP请求的ADU长度远小于这个值TCP栈通常会把一整帧放在一个段里发出去。但ESP32跑的是WiFiWiFi的MTU虽然也是1500但实际空口传输中AP和STA之间的协商、重传、聚合都会影响TCP分段行为。更关键的是当ModbusTCP的ADU超过MSS时TCP层必然分片这是协议栈的行为你控制不了。MBAP头的结构是这样的前2字节是事务标识符接着2字节是协议标识符Modbus固定为0然后2字节是Length最后1字节是单元标识符。Length字段的值等于“单元标识符 PDU”的总字节数也就是说如果你要读保持寄存器功能码0x03起始地址0x0000数量0x000A那么PDU是5字节加上单元标识符1字节Length6。整个ADU长度就是6MBAP头前6字节 6 12字节。这个长度远小于MSS所以单次请求通常不会分片。但响应就不一样了——如果你返回10个寄存器的值PDU是2功能码字节数 20数据 22字节加上单元标识符1字节Length23ADU总长29字节依然很小。那什么时候会分片当寄存器数量很大比如一次读125个寄存器PDU就是2250252字节Length253ADU总长259字节还是小于MSS。真正会触发分片的是多个请求在TCP流中连续到达或者网络层因为拥塞控制把多个小段合并/拆分。但更隐蔽的情况是上位机比如某些SCADA软件在发送请求时TCP_NODELAY没开Nagle算法把多个小请求攒在一起发到了ESP32这边一次recv收到多个ADU如果你不按Length字段切分就会把第二个ADU的头部当成第一个ADU的数据。所以分片缓存要解决两个问题粘包多个ADU粘在一个TCP段里和拆包一个ADU被拆到多个TCP段里。这两个问题的根源都是“TCP是字节流没有消息边界”而ModbusTCP的消息边界就藏在MBAP头的Length字段里。2.2 ESP32的LwIP配置对分片行为的实际影响ESP32默认的LwIP配置里TCP_MSS通常是1460TCP_WND接收窗口是5744左右TCP_SND_BUF也是5744。这些参数决定了TCP层一次能缓冲多少数据。如果你在menuconfig里把TCP_MSS调小比如调到536那么分片会更容易发生因为每个段能携带的数据更少。反过来如果你把接收窗口调大比如调到11680那么一次recv可能拿到更多数据粘包的概率反而增加。我在实测中发现ESP32-S3在WiFi环境下如果AP的DTIM周期设置得比较长比如3那么ESP32在省电模式下会周期性休眠醒来后可能一次性收到多个缓冲的TCP段这时候粘包几乎必然发生。还有一个容易被忽略的点ESP32的LwIP默认开启了LWIP_TCP_SACK_OUT和LWIP_TCP_TIMESTAMPS这些选项会影响TCP段的确认和重传行为但对分片缓存本身没有直接影响。真正需要关注的是TCP_QUEUE_OOSEQ它决定了乱序到达的TCP段是否会被缓存。如果这个选项关闭乱序段会被丢弃导致重传进而加剧分片。所以我的建议是在menuconfig里保持TCP_QUEUE_OOSEQ开启并且把TCP_WND设置得比最大ADU长度大一些比如8192这样即使有多个ADU连续到达也不会因为窗口满而丢数据。2.3 一个真实的抓包案例两个分片如何打乱整个缓冲区我拿之前那个配电柜项目举例。上位机是某国产组态软件它发送的请求是读40个保持寄存器功能码0x03起始地址0x0000数量0x0028。PDU长度是5Length6ADU总长12字节。这个请求本身很小不会分片。但组态软件在初始化时会连续发送多个请求比如先读设备标识再读寄存器再读线圈。这些请求之间的间隔可能只有几毫秒TCP层会把它们合并成一个段发出去。假设三个请求的ADU分别是12字节、12字节、12字节总共36字节一个TCP段就发过来了。我的代码如果只recv一次然后按第一个ADU的Length6去解析就会把第一个ADU之后的24字节当成新数据但解析函数可能只处理了前12字节剩下的24字节被丢弃或者错位解析。更糟糕的是如果第二个ADU的Length字段恰好被当成事务标识符整个解析就全乱了。抓包显示ESP32的recv返回了36字节但我的缓冲区只有256字节一次recv就填满了前36字节。如果我不做循环解析只解析一次那么剩下的24字节就留在缓冲区里下一次recv又追加新数据缓冲区里就混着旧数据和新数据Length字段完全对不上。这就是典型的粘包问题。解决办法就是每次recv之后循环检查缓冲区里是否至少有一个完整的ADU根据Length字段判断如果有就解析并移除直到剩余数据不足一个完整ADU为止。3. 环形缓冲区还是线性缓冲区ESP32内存约束下的选型逻辑3.1 线性缓冲区加memmove的代价与适用场景最直观的做法是开一个固定大小的数组比如512字节每次recv把数据追加到数组末尾然后从头开始解析。解析完一个ADU后把剩余数据用memmove往前挪。这种方案实现简单代码量少适合ADU长度不大、并发连接数不多的场景。但它的缺点也很明显memmove在数据量大时开销不可忽略。假设缓冲区里经常有200字节的剩余数据每次解析一个ADU就要挪200字节如果每秒处理100个请求那就是每秒20KB的memmove对ESP32的CPU来说虽然不算重但在高并发下会累积成可观的负载。更重要的是线性缓冲区在边界处理上容易出错。比如缓冲区还剩10字节但下一个ADU需要12字节这时候recv新数据进来如果缓冲区总大小是512已用10剩余502recv最多能收502字节。但如果recv返回了502字节缓冲区满了而里面可能包含多个ADU你需要循环解析直到剩余数据不足一个ADU。如果剩余数据恰好是某个ADU的前半部分你就必须保留它等下一次recv。这时候如果缓冲区已经满了你就没有空间再recv了只能先解析、挪动、腾出空间。这个逻辑如果写得不严谨很容易出现“缓冲区满了但解析不出完整ADU”的死锁。我早期就是用线性缓冲区在实验室跑得好好的一到现场就出问题。后来分析发现现场的网络抖动导致recv返回的数据量忽大忽小有时候一次recv只有几个字节缓冲区里长期有“半截”ADUmemmove频繁触发CPU占用率从5%飙到30%。虽然30%不算高但对于一个还要跑其他任务的ESP32来说这30%可能就是压垮骆驼的最后一根稻草。3.2 环形缓冲区的读写指针设计避免“假满”与“覆盖”环形缓冲区ring buffer是更优雅的方案。它用读指针和写指针来管理数据写指针追读指针读指针追写指针不需要memmove。但环形缓冲区有一个经典问题如何区分“空”和“满”如果读指针等于写指针可能是空也可能是满。常见的做法是留一个字节不用或者额外维护一个count变量。我倾向于用count变量因为ESP32的内存虽然紧张但多一个int32_t的开销可以忽略而逻辑清晰度提升很大。环形缓冲区的容量选择也有讲究。ModbusTCP的最大ADU长度是260字节MBAP 7字节 PDU 253字节但实际项目中很少用到最大长度。如果你只读保持寄存器最大PDU是252字节功能码字节数250字节数据加上MBAP头7字节ADU最大259字节。所以缓冲区至少要能容纳一个最大ADU也就是260字节。但考虑到粘包你可能需要容纳多个ADU比如3个那就是780字节。再加上TCP层可能一次recv返回更多数据我建议缓冲区大小设为1024字节或2048字节。ESP32-S3有512KB SRAM开2KB缓冲区完全没问题。如果是ESP32-C3SRAM小一些但2KB也不算什么。环形缓冲区的写入逻辑是计算写指针到缓冲区末尾的连续空间如果剩余空间足够直接memcpy如果不够分两段memcpy先写到末尾再绕回到开头。读取逻辑类似但读取时不需要真的把数据移走只需要移动读指针。解析ADU时先从读指针位置读取MBAP头7字节但环形缓冲区里的数据可能跨越末尾所以读取MBAP头也需要分两段。为了简化我通常先把MBAP头拷贝到一个临时数组里解析出Length然后判断缓冲区里是否有足够的数据7 Length - 1因为Length包含单元标识符而MBAP头已经包含了单元标识符这里要仔细MBAP头是7字节其中前6字节是事务标识符协议标识符Length第7字节是单元标识符。Length字段的值是“单元标识符PDU”的长度所以整个ADU长度 6 Length。因此如果缓冲区里可读数据量 6 Length就说明有一个完整ADU。注意Length字段本身在MBAP头的第5、6字节所以读取Length只需要前6字节。3.3 双缓冲区方案用空间换确定性的极端做法还有一种方案是双缓冲区一个用于recv一个用于解析。recv缓冲区接收TCP数据然后整体拷贝到解析缓冲区解析缓冲区里做线性解析。这种方案的好处是recv和解析解耦recv可以尽可能快地收数据解析可以慢慢处理。但缺点是内存翻倍而且拷贝开销大。在ESP32上如果recv缓冲区是2048解析缓冲区也是2048那就是4KB对于C3来说有点奢侈。而且拷贝本身也是memcpy和memmove的开销差不多。所以除非你的应用对实时性要求极高否则我不推荐双缓冲区。我的选择是环形缓冲区 状态机解析。环形缓冲区负责高效存取状态机负责逐字节或逐段解析两者结合既省内存又省CPU。下面我会详细讲状态机的设计。4. 状态机解析把“等Length”这件事做成可重入的4.1 状态划分IDLE、HEADER、PAYLOAD三态足够吗状态机解析的核心思想是不要假设一次recv就能拿到完整ADU而是把解析过程拆成多个状态每次有数据进来就推进状态直到一个ADU解析完成。最简单的状态机是三个状态IDLE等待MBAP头、HEADER正在读MBAP头、PAYLOAD正在读PDU。但实际实现时我发现三个状态不够因为MBAP头本身也可能分片。比如你只收到了前3字节事务标识符和协议标识符有了但Length还没收到。这时候你需要一个“部分头”状态。所以更实用的状态划分是STATE_IDLE缓冲区里没有正在解析的ADU等待至少6字节的MBAP头。STATE_HEADER已经读取了部分MBAP头但不足6字节继续等待。STATE_PAYLOADMBAP头已完整Length已知正在等待剩余PDU数据。STATE_COMPLETE一个完整ADU已就绪可以交给业务处理。但状态机不一定非要显式地用switch-case实现。另一种更轻量的做法是每次recv之后用一个while循环检查缓冲区里可读数据量是否 6如果是读取Length然后检查可读数据量是否 6 Length如果是说明一个完整ADU就绪解析并移动读指针继续循环如果不足跳出循环等待下一次recv。这种写法本质上是一个隐式状态机代码更简洁而且不需要维护状态变量。我最终采用的就是这种方案因为它足够简单而且不容易出错。4.2 处理“半截Length”的边界情况一个字节都不能错隐式状态机虽然简洁但有一个边界情况必须小心当缓冲区里可读数据量 6但Length字段的值导致6 Length超过缓冲区容量时怎么办比如Length2536253259而缓冲区只有256字节那这个ADU永远无法完整放入缓冲区。这时候你有两个选择要么把缓冲区扩大到至少260字节要么在检测到Length过大时主动断开连接或返回异常。ModbusTCP协议规定最大ADU是260字节所以缓冲区至少260字节是硬性要求。我建议直接开到512字节或1024字节留足余量。另一个边界情况是缓冲区里可读数据量 6但Length字段的值是0或者大于253。Length0意味着没有PDU这在ModbusTCP里是非法的因为至少要有功能码。Length253也是非法的因为PDU最大253字节。遇到这种情况应该丢弃整个缓冲区或者重置连接因为这说明数据流已经错位了继续解析只会越错越离谱。我在代码里加了一个校验如果Length 2 || Length 254直接清空缓冲区并关闭连接。注意Length1是合法的吗Length1意味着只有单元标识符没有PDU这也是非法的因为功能码至少1字节。所以Length最小是2单元标识符功能码。最大是254实际上PDU最大253字节加上单元标识符1字节Length最大254。但ModbusTCP规范里说最大ADU是260字节MBAP头7字节所以PDU最大253字节Length1253254。所以Length的范围是2到254。4.3 解析完成后的回调设计如何把ADU交给业务层当检测到一个完整ADU后你需要把它从环形缓冲区里取出来交给业务层处理。取出的方式有两种一种是拷贝到一个临时数组然后调用回调函数另一种是直接传指针和长度但环形缓冲区里的数据可能跨越末尾所以指针可能不连续。为了简化业务层我通常拷贝到一个256字节的临时数组里然后调用modbus_handle_adu(temp, adu_len)。拷贝的开销很小因为ADU最大260字节memcpy一次也就几百纳秒。业务层处理完后返回响应响应再通过TCP发回去。注意响应发送时也要考虑TCP分片但发送端的分片由LwIP处理你只需要保证一次send发送完整响应即可。如果响应超过MSSLwIP会自动分片接收端上位机会自己拼接这不属于我们讨论的范围。回调设计还有一个细节事务标识符。ModbusTCP的事务标识符由客户端生成服务端必须在响应里原样返回。所以你在解析ADU时要把前2字节的事务标识符保存下来响应时填回去。这个字段在MBAP头里解析时顺手就拿到了。5. 实测调优从“偶尔丢帧”到“连续72小时零丢包”5.1 压力测试环境的搭建用Python模拟恶劣网络为了验证分片缓存的健壮性我搭了一个测试环境PC上跑Python脚本用socket发送ModbusTCP请求但故意把请求拆成多个TCP段发送中间加随机延迟。比如一个12字节的请求先发5字节sleep 10ms再发7字节。这样ESP32端就会经历“半截头”和“半截PDU”的情况。同时我还模拟粘包连续发送三个请求中间不加延迟让TCP层合并成一个段。Python脚本的核心逻辑如下import socket import time import struct def send_fragmented(sock, adu, frag_size, delay): for i in range(0, len(adu), frag_size): sock.send(adu[i:ifrag_size]) time.sleep(delay) # 构造读保持寄存器请求 def build_request(tid, unit, start, count): pdu struct.pack(BHH, 0x03, start, count) length len(pdu) 1 mbap struct.pack(HHHB, tid, 0, length, unit) return mbap pdu s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((192.168.1.100, 502)) req build_request(1, 1, 0, 10) # 分片发送每片3字节延迟5ms send_fragmented(s, req, 3, 0.005) # 再发一个粘包请求 req2 build_request(2, 1, 0, 10) req3 build_request(3, 1, 0, 10) s.send(req2 req3) # 粘包这个脚本跑起来后ESP32端如果分片缓存没做好立刻就会出错。我最初用线性缓冲区时这个脚本跑不到100个请求就挂了。换成环形缓冲区隐式状态机后连续跑了72小时零丢包。5.2 缓冲区大小的实测数据512字节 vs 1024字节 vs 2048字节我分别在512、1024、2048三种缓冲区大小下做了测试每种跑24小时统计丢包率和CPU占用率。测试条件是每秒100个请求其中30%是分片请求20%是粘包请求50%是正常请求。结果如下缓冲区大小丢包率平均CPU占用最大CPU占用内存剩余512字节0.02%12%28%180KB1024字节0%11%25%179KB2048字节0%11%24%178KB512字节时丢包率0.02%虽然很低但确实有丢包。分析日志发现当连续多个大ADU粘包时512字节缓冲区偶尔会满导致recv无法接收新数据TCP窗口关闭上位机超时。1024字节后丢包率降为0。2048字节和1024字节差别不大但内存多占1KB。所以我的建议是至少1024字节推荐2048字节。对于ESP32-S3这种内存充足的芯片直接上2048对于ESP32-C31024也够用。5.3 和LwIP参数的联动调优TCP_WND与TCP_MSS的取舍缓冲区大小只是应用层的事LwIP的参数也会影响分片行为。我试过把TCP_WND从5744调到8192发现粘包概率略有增加因为接收窗口大了TCP层可以缓冲更多数据一次recv返回的数据量更大。但这对分片缓存来说不是坏事因为环形缓冲区能处理任意大小的数据。真正需要注意的是TCP_MSS如果把它调小到536分片会更频繁但每个分片更小环形缓冲区的压力反而小。不过536会导致TCP效率降低因为每个段携带的数据少头部开销占比大。所以我的建议是保持默认的1460不要动。还有一个参数是TCP_SND_BUF它影响发送响应时的缓冲。如果你返回的响应很大比如读125个寄存器响应259字节TCP_SND_BUF至少要能容纳这个响应。默认5744足够。但如果你的应用要返回大量数据比如一次性返回1000个寄存器这不符合Modbus规范但有些人会这么干那就需要调大。6. 那些文档里不会写的坑事务标识符错位与单元标识符陷阱6.1 事务标识符不匹配导致的“幽灵响应”事务标识符是ModbusTCP里用来匹配请求和响应的。客户端发请求时带一个TID服务端响应时必须原样返回。如果你在分片缓存里把TID搞错了客户端就会认为响应不属于自己从而丢弃。更隐蔽的是如果多个请求粘包你解析第一个ADU时用了第二个ADU的TID那么第一个响应就会带错误的TID客户端匹配不上而第二个响应又带第一个的TID整个就乱了。我在早期代码里就犯过这个错解析ADU时TID是从缓冲区读的但读指针移动后下一个ADU的TID又读到了结果响应时用的TID是上一个ADU的。后来我改成每解析一个ADU先把TID保存到一个局部变量然后立即构造响应响应里用这个局部变量。这样就不会错位。6.2 单元标识符在网关场景下的特殊处理单元标识符Unit ID在直连场景下通常固定为1或0xFF但在网关场景下它用来区分不同的从站设备。比如一个ModbusTCP转ModbusRTU的网关TCP端的Unit ID对应RTU端的从站地址。如果你在分片缓存里把Unit ID丢了网关就不知道把请求转发给哪个RTU设备。所以解析ADU时Unit ID也要保存。而且响应时Unit ID必须和请求一致。有些网关实现里Unit ID0xFF表示广播不响应。这些细节在分片缓存里都要考虑到因为分片可能导致Unit ID被拆到两个TCP段里如果你不缓存就会读到错误的值。6.3 异常响应Exception Response的长度计算ModbusTCP的异常响应格式是功能码 | 0x80异常码。PDU长度是2字节加上单元标识符1字节Length3ADU总长9字节。这个长度很短通常不会分片。但如果你在解析请求时发现功能码不支持需要返回异常响应这时候要注意异常响应的Length字段是3而不是请求的Length。我见过有人直接把请求的Length填到异常响应里导致客户端解析错误。所以构造响应时Length要重新计算不能复用请求的。7. 代码骨架一个可复用的分片缓存实现7.1 环形缓冲区的C实现读写指针与count下面是我在实际项目中用的环形缓冲区实现精简后大概80行。核心是rb_write和rb_read两个函数以及rb_peek用于不移动读指针地查看数据。typedef struct { uint8_t *buf; uint32_t size; uint32_t read; uint32_t write; uint32_t count; } ringbuf_t; void rb_init(ringbuf_t *rb, uint8_t *buf, uint32_t size) { rb-buf buf; rb-size size; rb-read 0; rb-write 0; rb-count 0; } uint32_t rb_write(ringbuf_t *rb, const uint8_t *data, uint32_t len) { uint32_t space rb-size - rb-count; if (len space) len space; for (uint32_t i 0; i len; i) { rb-buf[rb-write] data[i]; rb-write (rb-write 1) % rb-size; } rb-count len; return len; } uint32_t rb_peek(ringbuf_t *rb, uint8_t *data, uint32_t len) { if (len rb-count) len rb-count; uint32_t r rb-read; for (uint32_t i 0; i len; i) { data[i] rb-buf[r]; r (r 1) % rb-size; } return len; } void rb_consume(ringbuf_t *rb, uint32_t len) { if (len rb-count) len rb-count; rb-read (rb-read len) % rb-size; rb-count - len; }注意rb_write里用了循环逐字节写这在数据量大时效率不高。实际项目中我会优化成两段memcpy但为了逻辑清晰这里保留逐字节版本。如果你追求性能可以改成uint32_t rb_write(ringbuf_t *rb, const uint8_t *data, uint32_t len) { uint32_t space rb-size - rb-count; if (len space) len space; uint32_t first rb-size - rb-write; if (first len) first len; memcpy(rb-buf rb-write, data, first); if (len first) { memcpy(rb-buf, data first, len - first); } rb-write (rb-write len) % rb-size; rb-count len; return len; }7.2 解析循环while Length判断解析循环放在recv之后每次recv把数据写入环形缓冲区然后调用modbus_parse。modbus_parse里用一个while循环不断检查是否有完整ADU。void modbus_parse(ringbuf_t *rb) { while (1) { if (rb-count 6) break; // 连MBAP头都不够 uint8_t header[6]; rb_peek(rb, header, 6); uint16_t length (header[4] 8) | header[5]; if (length 2 || length 254) { // 非法Length清空缓冲区 rb_consume(rb, rb-count); break; } uint32_t adu_len 6 length; if (rb-count adu_len) break; // 数据不够等下一次recv uint8_t adu[260]; rb_peek(rb, adu, adu_len); rb_consume(rb, adu_len); modbus_handle_adu(adu, adu_len); } }这个循环的关键是每次只peek不consume直到确认有完整ADU才consume。这样即使数据分片也不会丢失。7.3 与FreeRTOS任务的结合优先级与栈大小在ESP32上ModbusTCP通常跑在一个独立的FreeRTOS任务里。这个任务的优先级建议设为5比WiFi任务低比空闲任务高栈大小建议4096字节。因为解析ADU时会在栈上开260字节的临时数组加上函数调用开销4096足够。如果你在解析里还要做复杂业务比如读写Flash栈要再大一些。任务里用recv阻塞接收超时设为100ms这样即使没有数据任务也能周期性醒来检查其他事件。void modbus_task(void *arg) { ringbuf_t rb; uint8_t buf[2048]; rb_init(rb, buf, sizeof(buf)); while (1) { uint8_t temp[512]; int len recv(sock, temp, sizeof(temp), 100); if (len 0) { rb_write(rb, temp, len); modbus_parse(rb); } } }注意recv的超时参数在LwIP里是毫秒但实际精度可能受FreeRTOS tick影响。如果tick是10ms超时100ms就是10个tick。这个精度对ModbusTCP来说足够了。8. 从单连接到多连接分片缓存的扩展思路8.1 每个连接独立缓冲区还是共享缓冲区ModbusTCP服务端通常支持多个客户端连接。每个连接都有自己的TCP流所以分片缓存必须是每连接独立的。如果你用一个全局缓冲区多个连接的数据会混在一起Length字段完全对不上。所以每个连接需要独立的ringbuf_t和解析状态。在ESP32上如果同时有5个连接每个连接2KB缓冲区那就是10KB对于S3来说没问题对于C3来说有点紧张。这时候可以减小缓冲区到512字节但前面实测512字节有0.02%丢包率所以需要权衡。我的建议是如果连接数不超过3个每个连接1KB如果连接数更多考虑用512字节但要把LwIP的TCP_WND调小减少粘包概率。8.2 连接断开时的缓冲区清理与内存泄漏防范连接断开时必须释放该连接的缓冲区。如果你用malloc动态分配记得free。如果用的是静态数组记得重置read/write/count。我见过有人在连接断开后没有重置count导致下一次连接进来时缓冲区里还有旧数据解析直接错位。所以每次accept新连接时都要调用rb_init重新初始化。另外如果连接异常断开比如RSTrecv会返回-1这时候也要清理。8.3 和ModbusRTU转TCP网关的差异Unit ID路由表如果你做的是ModbusRTU转TCP网关分片缓存之后还要根据Unit ID查路由表把PDU转发到对应的RTU串口。这时候Unit ID的解析必须准确而且路由表要支持动态添加。我通常用一个简单的数组每个元素是{unit_id, uart_port}查找时线性遍历。如果Unit ID很多可以用哈希表但在ESP32上线性遍历几十个元素的开销可以忽略。9. 我踩过的三个坑和对应的修复方案9.1 坑一recv返回0被当成正常数据TCP的recv返回0表示对端关闭了连接。我早期代码里没有判断len0直接把0字节写入环形缓冲区然后继续解析。结果缓冲区里一直是旧数据解析循环无限循环因为count没变但while条件一直满足。后来加了判断如果len0关闭连接清理缓冲区。如果len0根据errno判断是超时还是错误超时就继续错误就关闭。9.2 坑二Length字段字节序搞反ModbusTCP的Length字段是网络字节序大端。我一开始用length header[4] | (header[5] 8)结果Length值完全错误导致解析出的ADU长度不对。后来改成length (header[4] 8) | header[5]问题解决。这个坑很低级但在调试时很容易忽略因为抓包看到的Length是正常的但代码里读出来是反的。9.3 坑三环形缓冲区满时recv阻塞导致看门狗复位当环形缓冲区满时如果你还继续recv数据会丢失。但如果你不recvTCP窗口会关闭对端发不过来。我早期代码里在缓冲区满时直接return不recv结果任务一直不阻塞CPU占用100%看门狗复位。后来改成如果缓冲区剩余空间小于某个阈值比如256字节就主动consume一些已解析的数据但已解析的数据已经consume了或者临时扩大缓冲区。实际上只要解析循环及时consume缓冲区很少会满。如果真的满了说明解析速度跟不上接收速度这时候应该降低recv的频率或者增加任务优先级。10. 写在最后一些个人经验分片缓存这件事说到底是“不要相信一次recv就能拿到完整消息”。这个原则不仅适用于ModbusTCP也适用于任何基于TCP的自定义协议。我在ESP32上做过的项目中凡是涉及TCP的我都会加一层分片缓存哪怕协议本身很简单。因为WiFi环境的不确定性远高于有线以太网你永远不知道下一个recv会返回多少字节。另外调试分片问题时抓包工具是必不可少的。我通常用Wireshark抓PC端的包同时用ESP32的日志打印每次recv的字节数和缓冲区状态。两边对照很快就能定位是分片还是粘包。如果你没有抓包条件也可以在代码里加一个简单的统计记录每次recv的字节数分布如果发现经常出现小于10字节的recv那说明分片很严重需要检查LwIP参数或WiFi信号。最后关于缓冲区大小我的经验是宁大勿小。ESP32-S3有512KB SRAM开2KB缓冲区连零头都不到。与其为了省1KB内存而冒丢包的风险不如直接开大一点。毕竟在现场调试时丢一个包可能就要折腾半天而内存省下来也没别的用途。
