1. 從一次現(xiàn)場調試說起為什么ModbusTCP在ESP32上會“卡死”去年冬天我在一個配電柜改造項目里第一次被ESP32的ModbusTCP搞到懷疑人生。現(xiàn)場是一臺ESP32-S3核心板跑著ModbusTCP從站上位機每200ms輪詢一次寄存器數(shù)量不多也就四十來個。按理說這點數(shù)據(jù)量對ESP32來說連熱身都算不上但實際跑起來每隔十幾分鐘就會丟一幀上位機報超時然后自動重連重連之后又能撐一陣。最開始我以為是WiFi信號問題換了天線、調了信道、把路由器挪到柜子旁邊都沒用。后來抓包才發(fā)現(xiàn)問題出在TCP分片上——上位機一次請求的報文被拆成了兩個TCP段發(fā)過來而我的代碼里默認“一次recv就是一整幀”第二個分片直接被當成新幀的頭部解析整個緩沖區(qū)就亂了。這個坑其實非常典型。ModbusTCP雖然協(xié)議本身簡單但它跑在TCP之上而TCP是字節(jié)流協(xié)議不保證你一次recv就能拿到完整的一幀。ESP32的LwIP協(xié)議棧在WiFi環(huán)境下MSS最大報文段長度通常只有1460字節(jié)一旦ModbusTCP的ADU應用數(shù)據(jù)單元超過這個長度或者網絡抖動導致TCP分段分片就必然發(fā)生。更麻煩的是ModbusTCP的MBAP頭里有一個Length字段它告訴你后面還有多少字節(jié)但如果你不主動做緩存拼接這個字段就形同虛設。所以這篇內容我想聊的不是“怎么跑通ModbusTCP”而是怎么在ESP32上把分片緩存這件事做扎實。適合已經能在ESP32上跑起ModbusTCP、但被偶發(fā)丟幀和粘包問題折磨的開發(fā)者也適合正在做工業(yè)網關、邊緣采集終端的朋友。下面我會從協(xié)議本質、緩沖區(qū)設計、狀態(tài)機實現(xiàn)、實測調優(yōu)幾個角度把這件事拆開講透。2. ModbusTCP分片到底是怎么發(fā)生的協(xié)議層與網絡層的雙重真相2.1 MBAP頭里的Length字段才是拼接的唯一依據(jù)很多人寫ModbusTCP從站的時候習慣性地把recv到的數(shù)據(jù)直接丟給協(xié)議解析函數(shù)解析函數(shù)里假設buffer[0..6]是MBAP頭buffer[7]是功能碼然后按固定長度去讀。這種寫法在PC端以太網環(huán)境下可能跑幾個月都不出問題因為以太網的MTU是1500MSS是1460而大多數(shù)ModbusTCP請求的ADU長度遠小于這個值TCP棧通常會把一整幀放在一個段里發(fā)出去。但ESP32跑的是WiFiWiFi的MTU雖然也是1500但實際空口傳輸中AP和STA之間的協(xié)商、重傳、聚合都會影響TCP分段行為。更關鍵的是當ModbusTCP的ADU超過MSS時TCP層必然分片這是協(xié)議棧的行為你控制不了。MBAP頭的結構是這樣的前2字節(jié)是事務標識符接著2字節(jié)是協(xié)議標識符Modbus固定為0然后2字節(jié)是Length最后1字節(jié)是單元標識符。Length字段的值等于“單元標識符 PDU”的總字節(jié)數(shù)也就是說如果你要讀保持寄存器功能碼0x03起始地址0x0000數(shù)量0x000A那么PDU是5字節(jié)加上單元標識符1字節(jié)Length6。整個ADU長度就是6MBAP頭前6字節(jié) 6 12字節(jié)。這個長度遠小于MSS所以單次請求通常不會分片。但響應就不一樣了——如果你返回10個寄存器的值PDU是2功能碼字節(jié)數(shù) 20數(shù)據(jù) 22字節(jié)加上單元標識符1字節(jié)Length23ADU總長29字節(jié)依然很小。那什么時候會分片當寄存器數(shù)量很大比如一次讀125個寄存器PDU就是2250252字節(jié)Length253ADU總長259字節(jié)還是小于MSS。真正會觸發(fā)分片的是多個請求在TCP流中連續(xù)到達或者網絡層因為擁塞控制把多個小段合并/拆分。但更隱蔽的情況是上位機比如某些SCADA軟件在發(fā)送請求時TCP_NODELAY沒開Nagle算法把多個小請求攢在一起發(fā)到了ESP32這邊一次recv收到多個ADU如果你不按Length字段切分就會把第二個ADU的頭部當成第一個ADU的數(shù)據(jù)。所以分片緩存要解決兩個問題粘包多個ADU粘在一個TCP段里和拆包一個ADU被拆到多個TCP段里。這兩個問題的根源都是“TCP是字節(jié)流沒有消息邊界”而ModbusTCP的消息邊界就藏在MBAP頭的Length字段里。2.2 ESP32的LwIP配置對分片行為的實際影響ESP32默認的LwIP配置里TCP_MSS通常是1460TCP_WND接收窗口是5744左右TCP_SND_BUF也是5744。這些參數(shù)決定了TCP層一次能緩沖多少數(shù)據(jù)。如果你在menuconfig里把TCP_MSS調小比如調到536那么分片會更容易發(fā)生因為每個段能攜帶的數(shù)據(jù)更少。反過來如果你把接收窗口調大比如調到11680那么一次recv可能拿到更多數(shù)據(jù)粘包的概率反而增加。我在實測中發(fā)現(xiàn)ESP32-S3在WiFi環(huán)境下如果AP的DTIM周期設置得比較長比如3那么ESP32在省電模式下會周期性休眠醒來后可能一次性收到多個緩沖的TCP段這時候粘包幾乎必然發(fā)生。還有一個容易被忽略的點ESP32的LwIP默認開啟了LWIP_TCP_SACK_OUT和LWIP_TCP_TIMESTAMPS這些選項會影響TCP段的確認和重傳行為但對分片緩存本身沒有直接影響。真正需要關注的是TCP_QUEUE_OOSEQ它決定了亂序到達的TCP段是否會被緩存。如果這個選項關閉亂序段會被丟棄導致重傳進而加劇分片。所以我的建議是在menuconfig里保持TCP_QUEUE_OOSEQ開啟并且把TCP_WND設置得比最大ADU長度大一些比如8192這樣即使有多個ADU連續(xù)到達也不會因為窗口滿而丟數(shù)據(jù)。2.3 一個真實的抓包案例兩個分片如何打亂整個緩沖區(qū)我拿之前那個配電柜項目舉例。上位機是某國產組態(tài)軟件它發(fā)送的請求是讀40個保持寄存器功能碼0x03起始地址0x0000數(shù)量0x0028。PDU長度是5Length6ADU總長12字節(jié)。這個請求本身很小不會分片。但組態(tài)軟件在初始化時會連續(xù)發(fā)送多個請求比如先讀設備標識再讀寄存器再讀線圈。這些請求之間的間隔可能只有幾毫秒TCP層會把它們合并成一個段發(fā)出去。假設三個請求的ADU分別是12字節(jié)、12字節(jié)、12字節(jié)總共36字節(jié)一個TCP段就發(fā)過來了。我的代碼如果只recv一次然后按第一個ADU的Length6去解析就會把第一個ADU之后的24字節(jié)當成新數(shù)據(jù)但解析函數(shù)可能只處理了前12字節(jié)剩下的24字節(jié)被丟棄或者錯位解析。更糟糕的是如果第二個ADU的Length字段恰好被當成事務標識符整個解析就全亂了。抓包顯示ESP32的recv返回了36字節(jié)但我的緩沖區(qū)只有256字節(jié)一次recv就填滿了前36字節(jié)。如果我不做循環(huán)解析只解析一次那么剩下的24字節(jié)就留在緩沖區(qū)里下一次recv又追加新數(shù)據(jù)緩沖區(qū)里就混著舊數(shù)據(jù)和新數(shù)據(jù)Length字段完全對不上。這就是典型的粘包問題。解決辦法就是每次recv之后循環(huán)檢查緩沖區(qū)里是否至少有一個完整的ADU根據(jù)Length字段判斷如果有就解析并移除直到剩余數(shù)據(jù)不足一個完整ADU為止。3. 環(huán)形緩沖區(qū)還是線性緩沖區(qū)ESP32內存約束下的選型邏輯3.1 線性緩沖區(qū)加memmove的代價與適用場景最直觀的做法是開一個固定大小的數(shù)組比如512字節(jié)每次recv把數(shù)據(jù)追加到數(shù)組末尾然后從頭開始解析。解析完一個ADU后把剩余數(shù)據(jù)用memmove往前挪。這種方案實現(xiàn)簡單代碼量少適合ADU長度不大、并發(fā)連接數(shù)不多的場景。但它的缺點也很明顯memmove在數(shù)據(jù)量大時開銷不可忽略。假設緩沖區(qū)里經常有200字節(jié)的剩余數(shù)據(jù)每次解析一個ADU就要挪200字節(jié)如果每秒處理100個請求那就是每秒20KB的memmove對ESP32的CPU來說雖然不算重但在高并發(fā)下會累積成可觀的負載。更重要的是線性緩沖區(qū)在邊界處理上容易出錯。比如緩沖區(qū)還剩10字節(jié)但下一個ADU需要12字節(jié)這時候recv新數(shù)據(jù)進來如果緩沖區(qū)總大小是512已用10剩余502recv最多能收502字節(jié)。但如果recv返回了502字節(jié)緩沖區(qū)滿了而里面可能包含多個ADU你需要循環(huán)解析直到剩余數(shù)據(jù)不足一個ADU。如果剩余數(shù)據(jù)恰好是某個ADU的前半部分你就必須保留它等下一次recv。這時候如果緩沖區(qū)已經滿了你就沒有空間再recv了只能先解析、挪動、騰出空間。這個邏輯如果寫得不嚴謹很容易出現(xiàn)“緩沖區(qū)滿了但解析不出完整ADU”的死鎖。我早期就是用線性緩沖區(qū)在實驗室跑得好好的一到現(xiàn)場就出問題。后來分析發(fā)現(xiàn)現(xiàn)場的網絡抖動導致recv返回的數(shù)據(jù)量忽大忽小有時候一次recv只有幾個字節(jié)緩沖區(qū)里長期有“半截”ADUmemmove頻繁觸發(fā)CPU占用率從5%飆到30%。雖然30%不算高但對于一個還要跑其他任務的ESP32來說這30%可能就是壓垮駱駝的最后一根稻草。3.2 環(huán)形緩沖區(qū)的讀寫指針設計避免“假滿”與“覆蓋”環(huán)形緩沖區(qū)ring buffer是更優(yōu)雅的方案。它用讀指針和寫指針來管理數(shù)據(jù)寫指針追讀指針讀指針追寫指針不需要memmove。但環(huán)形緩沖區(qū)有一個經典問題如何區(qū)分“空”和“滿”如果讀指針等于寫指針可能是空也可能是滿。常見的做法是留一個字節(jié)不用或者額外維護一個count變量。我傾向于用count變量因為ESP32的內存雖然緊張但多一個int32_t的開銷可以忽略而邏輯清晰度提升很大。環(huán)形緩沖區(qū)的容量選擇也有講究。ModbusTCP的最大ADU長度是260字節(jié)MBAP 7字節(jié) PDU 253字節(jié)但實際項目中很少用到最大長度。如果你只讀保持寄存器最大PDU是252字節(jié)功能碼字節(jié)數(shù)250字節(jié)數(shù)據(jù)加上MBAP頭7字節(jié)ADU最大259字節(jié)。所以緩沖區(qū)至少要能容納一個最大ADU也就是260字節(jié)。但考慮到粘包你可能需要容納多個ADU比如3個那就是780字節(jié)。再加上TCP層可能一次recv返回更多數(shù)據(jù)我建議緩沖區(qū)大小設為1024字節(jié)或2048字節(jié)。ESP32-S3有512KB SRAM開2KB緩沖區(qū)完全沒問題。如果是ESP32-C3SRAM小一些但2KB也不算什么。環(huán)形緩沖區(qū)的寫入邏輯是計算寫指針到緩沖區(qū)末尾的連續(xù)空間如果剩余空間足夠直接memcpy如果不夠分兩段memcpy先寫到末尾再繞回到開頭。讀取邏輯類似但讀取時不需要真的把數(shù)據(jù)移走只需要移動讀指針。解析ADU時先從讀指針位置讀取MBAP頭7字節(jié)但環(huán)形緩沖區(qū)里的數(shù)據(jù)可能跨越末尾所以讀取MBAP頭也需要分兩段。為了簡化我通常先把MBAP頭拷貝到一個臨時數(shù)組里解析出Length然后判斷緩沖區(qū)里是否有足夠的數(shù)據(jù)7 Length - 1因為Length包含單元標識符而MBAP頭已經包含了單元標識符這里要仔細MBAP頭是7字節(jié)其中前6字節(jié)是事務標識符協(xié)議標識符Length第7字節(jié)是單元標識符。Length字段的值是“單元標識符PDU”的長度所以整個ADU長度 6 Length。因此如果緩沖區(qū)里可讀數(shù)據(jù)量 6 Length就說明有一個完整ADU。注意Length字段本身在MBAP頭的第5、6字節(jié)所以讀取Length只需要前6字節(jié)。3.3 雙緩沖區(qū)方案用空間換確定性的極端做法還有一種方案是雙緩沖區(qū)一個用于recv一個用于解析。recv緩沖區(qū)接收TCP數(shù)據(jù)然后整體拷貝到解析緩沖區(qū)解析緩沖區(qū)里做線性解析。這種方案的好處是recv和解析解耦recv可以盡可能快地收數(shù)據(jù)解析可以慢慢處理。但缺點是內存翻倍而且拷貝開銷大。在ESP32上如果recv緩沖區(qū)是2048解析緩沖區(qū)也是2048那就是4KB對于C3來說有點奢侈。而且拷貝本身也是memcpy和memmove的開銷差不多。所以除非你的應用對實時性要求極高否則我不推薦雙緩沖區(qū)。我的選擇是環(huán)形緩沖區(qū) 狀態(tài)機解析。環(huán)形緩沖區(qū)負責高效存取狀態(tài)機負責逐字節(jié)或逐段解析兩者結合既省內存又省CPU。下面我會詳細講狀態(tài)機的設計。4. 狀態(tài)機解析把“等Length”這件事做成可重入的4.1 狀態(tài)劃分IDLE、HEADER、PAYLOAD三態(tài)足夠嗎狀態(tài)機解析的核心思想是不要假設一次recv就能拿到完整ADU而是把解析過程拆成多個狀態(tài)每次有數(shù)據(jù)進來就推進狀態(tài)直到一個ADU解析完成。最簡單的狀態(tài)機是三個狀態(tài)IDLE等待MBAP頭、HEADER正在讀MBAP頭、PAYLOAD正在讀PDU。但實際實現(xiàn)時我發(fā)現(xiàn)三個狀態(tài)不夠因為MBAP頭本身也可能分片。比如你只收到了前3字節(jié)事務標識符和協(xié)議標識符有了但Length還沒收到。這時候你需要一個“部分頭”狀態(tài)。所以更實用的狀態(tài)劃分是STATE_IDLE緩沖區(qū)里沒有正在解析的ADU等待至少6字節(jié)的MBAP頭。STATE_HEADER已經讀取了部分MBAP頭但不足6字節(jié)繼續(xù)等待。STATE_PAYLOADMBAP頭已完整Length已知正在等待剩余PDU數(shù)據(jù)。STATE_COMPLETE一個完整ADU已就緒可以交給業(yè)務處理。但狀態(tài)機不一定非要顯式地用switch-case實現(xiàn)。另一種更輕量的做法是每次recv之后用一個while循環(huán)檢查緩沖區(qū)里可讀數(shù)據(jù)量是否 6如果是讀取Length然后檢查可讀數(shù)據(jù)量是否 6 Length如果是說明一個完整ADU就緒解析并移動讀指針繼續(xù)循環(huán)如果不足跳出循環(huán)等待下一次recv。這種寫法本質上是一個隱式狀態(tài)機代碼更簡潔而且不需要維護狀態(tài)變量。我最終采用的就是這種方案因為它足夠簡單而且不容易出錯。4.2 處理“半截Length”的邊界情況一個字節(jié)都不能錯隱式狀態(tài)機雖然簡潔但有一個邊界情況必須小心當緩沖區(qū)里可讀數(shù)據(jù)量 6但Length字段的值導致6 Length超過緩沖區(qū)容量時怎么辦比如Length2536253259而緩沖區(qū)只有256字節(jié)那這個ADU永遠無法完整放入緩沖區(qū)。這時候你有兩個選擇要么把緩沖區(qū)擴大到至少260字節(jié)要么在檢測到Length過大時主動斷開連接或返回異常。ModbusTCP協(xié)議規(guī)定最大ADU是260字節(jié)所以緩沖區(qū)至少260字節(jié)是硬性要求。我建議直接開到512字節(jié)或1024字節(jié)留足余量。另一個邊界情況是緩沖區(qū)里可讀數(shù)據(jù)量 6但Length字段的值是0或者大于253。Length0意味著沒有PDU這在ModbusTCP里是非法的因為至少要有功能碼。Length253也是非法的因為PDU最大253字節(jié)。遇到這種情況應該丟棄整個緩沖區(qū)或者重置連接因為這說明數(shù)據(jù)流已經錯位了繼續(xù)解析只會越錯越離譜。我在代碼里加了一個校驗如果Length 2 || Length 254直接清空緩沖區(qū)并關閉連接。注意Length1是合法的嗎Length1意味著只有單元標識符沒有PDU這也是非法的因為功能碼至少1字節(jié)。所以Length最小是2單元標識符功能碼。最大是254實際上PDU最大253字節(jié)加上單元標識符1字節(jié)Length最大254。但ModbusTCP規(guī)范里說最大ADU是260字節(jié)MBAP頭7字節(jié)所以PDU最大253字節(jié)Length1253254。所以Length的范圍是2到254。4.3 解析完成后的回調設計如何把ADU交給業(yè)務層當檢測到一個完整ADU后你需要把它從環(huán)形緩沖區(qū)里取出來交給業(yè)務層處理。取出的方式有兩種一種是拷貝到一個臨時數(shù)組然后調用回調函數(shù)另一種是直接傳指針和長度但環(huán)形緩沖區(qū)里的數(shù)據(jù)可能跨越末尾所以指針可能不連續(xù)。為了簡化業(yè)務層我通?？截惖揭粋€256字節(jié)的臨時數(shù)組里然后調用modbus_handle_adu(temp, adu_len)。拷貝的開銷很小因為ADU最大260字節(jié)memcpy一次也就幾百納秒。業(yè)務層處理完后返回響應響應再通過TCP發(fā)回去。注意響應發(fā)送時也要考慮TCP分片但發(fā)送端的分片由LwIP處理你只需要保證一次send發(fā)送完整響應即可。如果響應超過MSSLwIP會自動分片接收端上位機會自己拼接這不屬于我們討論的范圍?；卣{設計還有一個細節(jié)事務標識符。ModbusTCP的事務標識符由客戶端生成服務端必須在響應里原樣返回。所以你在解析ADU時要把前2字節(jié)的事務標識符保存下來響應時填回去。這個字段在MBAP頭里解析時順手就拿到了。5. 實測調優(yōu)從“偶爾丟幀”到“連續(xù)72小時零丟包”5.1 壓力測試環(huán)境的搭建用Python模擬惡劣網絡為了驗證分片緩存的健壯性我搭了一個測試環(huán)境PC上跑Python腳本用socket發(fā)送ModbusTCP請求但故意把請求拆成多個TCP段發(fā)送中間加隨機延遲。比如一個12字節(jié)的請求先發(fā)5字節(jié)sleep 10ms再發(fā)7字節(jié)。這樣ESP32端就會經歷“半截頭”和“半截PDU”的情況。同時我還模擬粘包連續(xù)發(fā)送三個請求中間不加延遲讓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) # 分片發(fā)送每片3字節(jié)延遲5ms send_fragmented(s, req, 3, 0.005) # 再發(fā)一個粘包請求 req2 build_request(2, 1, 0, 10) req3 build_request(3, 1, 0, 10) s.send(req2 req3) # 粘包這個腳本跑起來后ESP32端如果分片緩存沒做好立刻就會出錯。我最初用線性緩沖區(qū)時這個腳本跑不到100個請求就掛了。換成環(huán)形緩沖區(qū)隱式狀態(tài)機后連續(xù)跑了72小時零丟包。5.2 緩沖區(qū)大小的實測數(shù)據(jù)512字節(jié) vs 1024字節(jié) vs 2048字節(jié)我分別在512、1024、2048三種緩沖區(qū)大小下做了測試每種跑24小時統(tǒng)計丟包率和CPU占用率。測試條件是每秒100個請求其中30%是分片請求20%是粘包請求50%是正常請求。結果如下緩沖區(qū)大小丟包率平均CPU占用最大CPU占用內存剩余512字節(jié)0.02%12%28%180KB1024字節(jié)0%11%25%179KB2048字節(jié)0%11%24%178KB512字節(jié)時丟包率0.02%雖然很低但確實有丟包。分析日志發(fā)現(xiàn)當連續(xù)多個大ADU粘包時512字節(jié)緩沖區(qū)偶爾會滿導致recv無法接收新數(shù)據(jù)TCP窗口關閉上位機超時。1024字節(jié)后丟包率降為0。2048字節(jié)和1024字節(jié)差別不大但內存多占1KB。所以我的建議是至少1024字節(jié)推薦2048字節(jié)。對于ESP32-S3這種內存充足的芯片直接上2048對于ESP32-C31024也夠用。5.3 和LwIP參數(shù)的聯(lián)動調優(yōu)TCP_WND與TCP_MSS的取舍緩沖區(qū)大小只是應用層的事LwIP的參數(shù)也會影響分片行為。我試過把TCP_WND從5744調到8192發(fā)現(xiàn)粘包概率略有增加因為接收窗口大了TCP層可以緩沖更多數(shù)據(jù)一次recv返回的數(shù)據(jù)量更大。但這對分片緩存來說不是壞事因為環(huán)形緩沖區(qū)能處理任意大小的數(shù)據(jù)。真正需要注意的是TCP_MSS如果把它調小到536分片會更頻繁但每個分片更小環(huán)形緩沖區(qū)的壓力反而小。不過536會導致TCP效率降低因為每個段攜帶的數(shù)據(jù)少頭部開銷占比大。所以我的建議是保持默認的1460不要動。還有一個參數(shù)是TCP_SND_BUF它影響發(fā)送響應時的緩沖。如果你返回的響應很大比如讀125個寄存器響應259字節(jié)TCP_SND_BUF至少要能容納這個響應。默認5744足夠。但如果你的應用要返回大量數(shù)據(jù)比如一次性返回1000個寄存器這不符合Modbus規(guī)范但有些人會這么干那就需要調大。6. 那些文檔里不會寫的坑事務標識符錯位與單元標識符陷阱6.1 事務標識符不匹配導致的“幽靈響應”事務標識符是ModbusTCP里用來匹配請求和響應的?？蛻舳税l(fā)請求時帶一個TID服務端響應時必須原樣返回。如果你在分片緩存里把TID搞錯了客戶端就會認為響應不屬于自己從而丟棄。更隱蔽的是如果多個請求粘包你解析第一個ADU時用了第二個ADU的TID那么第一個響應就會帶錯誤的TID客戶端匹配不上而第二個響應又帶第一個的TID整個就亂了。我在早期代碼里就犯過這個錯解析ADU時TID是從緩沖區(qū)讀的但讀指針移動后下一個ADU的TID又讀到了結果響應時用的TID是上一個ADU的。后來我改成每解析一個ADU先把TID保存到一個局部變量然后立即構造響應響應里用這個局部變量。這樣就不會錯位。6.2 單元標識符在網關場景下的特殊處理單元標識符Unit ID在直連場景下通常固定為1或0xFF但在網關場景下它用來區(qū)分不同的從站設備。比如一個ModbusTCP轉ModbusRTU的網關TCP端的Unit ID對應RTU端的從站地址。如果你在分片緩存里把Unit ID丟了網關就不知道把請求轉發(fā)給哪個RTU設備。所以解析ADU時Unit ID也要保存。而且響應時Unit ID必須和請求一致。有些網關實現(xiàn)里Unit ID0xFF表示廣播不響應。這些細節(jié)在分片緩存里都要考慮到因為分片可能導致Unit ID被拆到兩個TCP段里如果你不緩存就會讀到錯誤的值。6.3 異常響應Exception Response的長度計算ModbusTCP的異常響應格式是功能碼 | 0x80異常碼。PDU長度是2字節(jié)加上單元標識符1字節(jié)Length3ADU總長9字節(jié)。這個長度很短通常不會分片。但如果你在解析請求時發(fā)現(xiàn)功能碼不支持需要返回異常響應這時候要注意異常響應的Length字段是3而不是請求的Length。我見過有人直接把請求的Length填到異常響應里導致客戶端解析錯誤。所以構造響應時Length要重新計算不能復用請求的。7. 代碼骨架一個可復用的分片緩存實現(xiàn)7.1 環(huán)形緩沖區(qū)的C實現(xiàn)讀寫指針與count下面是我在實際項目中用的環(huán)形緩沖區(qū)實現(xiàn)精簡后大概80行。核心是rb_write和rb_read兩個函數(shù)以及rb_peek用于不移動讀指針地查看數(shù)據(jù)。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里用了循環(huán)逐字節(jié)寫這在數(shù)據(jù)量大時效率不高。實際項目中我會優(yōu)化成兩段memcpy但為了邏輯清晰這里保留逐字節(jié)版本。如果你追求性能可以改成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 解析循環(huán)while Length判斷解析循環(huán)放在recv之后每次recv把數(shù)據(jù)寫入環(huán)形緩沖區(qū)然后調用modbus_parse。modbus_parse里用一個while循環(huán)不斷檢查是否有完整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清空緩沖區(qū) rb_consume(rb, rb-count); break; } uint32_t adu_len 6 length; if (rb-count adu_len) break; // 數(shù)據(jù)不夠等下一次recv uint8_t adu[260]; rb_peek(rb, adu, adu_len); rb_consume(rb, adu_len); modbus_handle_adu(adu, adu_len); } }這個循環(huán)的關鍵是每次只peek不consume直到確認有完整ADU才consume。這樣即使數(shù)據(jù)分片也不會丟失。7.3 與FreeRTOS任務的結合優(yōu)先級與棧大小在ESP32上ModbusTCP通常跑在一個獨立的FreeRTOS任務里。這個任務的優(yōu)先級建議設為5比WiFi任務低比空閑任務高棧大小建議4096字節(jié)。因為解析ADU時會在棧上開260字節(jié)的臨時數(shù)組加上函數(shù)調用開銷4096足夠。如果你在解析里還要做復雜業(yè)務比如讀寫Flash棧要再大一些。任務里用recv阻塞接收超時設為100ms這樣即使沒有數(shù)據(jù)任務也能周期性醒來檢查其他事件。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的超時參數(shù)在LwIP里是毫秒但實際精度可能受FreeRTOS tick影響。如果tick是10ms超時100ms就是10個tick。這個精度對ModbusTCP來說足夠了。8. 從單連接到多連接分片緩存的擴展思路8.1 每個連接獨立緩沖區(qū)還是共享緩沖區(qū)ModbusTCP服務端通常支持多個客戶端連接。每個連接都有自己的TCP流所以分片緩存必須是每連接獨立的。如果你用一個全局緩沖區(qū)多個連接的數(shù)據(jù)會混在一起Length字段完全對不上。所以每個連接需要獨立的ringbuf_t和解析狀態(tài)。在ESP32上如果同時有5個連接每個連接2KB緩沖區(qū)那就是10KB對于S3來說沒問題對于C3來說有點緊張。這時候可以減小緩沖區(qū)到512字節(jié)但前面實測512字節(jié)有0.02%丟包率所以需要權衡。我的建議是如果連接數(shù)不超過3個每個連接1KB如果連接數(shù)更多考慮用512字節(jié)但要把LwIP的TCP_WND調小減少粘包概率。8.2 連接斷開時的緩沖區(qū)清理與內存泄漏防范連接斷開時必須釋放該連接的緩沖區(qū)。如果你用malloc動態(tài)分配記得free。如果用的是靜態(tài)數(shù)組記得重置read/write/count。我見過有人在連接斷開后沒有重置count導致下一次連接進來時緩沖區(qū)里還有舊數(shù)據(jù)解析直接錯位。所以每次accept新連接時都要調用rb_init重新初始化。另外如果連接異常斷開比如RSTrecv會返回-1這時候也要清理。8.3 和ModbusRTU轉TCP網關的差異Unit ID路由表如果你做的是ModbusRTU轉TCP網關分片緩存之后還要根據(jù)Unit ID查路由表把PDU轉發(fā)到對應的RTU串口。這時候Unit ID的解析必須準確而且路由表要支持動態(tài)添加。我通常用一個簡單的數(shù)組每個元素是{unit_id, uart_port}查找時線性遍歷。如果Unit ID很多可以用哈希表但在ESP32上線性遍歷幾十個元素的開銷可以忽略。9. 我踩過的三個坑和對應的修復方案9.1 坑一recv返回0被當成正常數(shù)據(jù)TCP的recv返回0表示對端關閉了連接。我早期代碼里沒有判斷l(xiāng)en0直接把0字節(jié)寫入環(huán)形緩沖區(qū)然后繼續(xù)解析。結果緩沖區(qū)里一直是舊數(shù)據(jù)解析循環(huán)無限循環(huán)因為count沒變但while條件一直滿足。后來加了判斷如果len0關閉連接清理緩沖區(qū)。如果len0根據(jù)errno判斷是超時還是錯誤超時就繼續(xù)錯誤就關閉。9.2 坑二Length字段字節(jié)序搞反ModbusTCP的Length字段是網絡字節(jié)序大端。我一開始用length header[4] | (header[5] 8)結果Length值完全錯誤導致解析出的ADU長度不對。后來改成length (header[4] 8) | header[5]問題解決。這個坑很低級但在調試時很容易忽略因為抓包看到的Length是正常的但代碼里讀出來是反的。9.3 坑三環(huán)形緩沖區(qū)滿時recv阻塞導致看門狗復位當環(huán)形緩沖區(qū)滿時如果你還繼續(xù)recv數(shù)據(jù)會丟失。但如果你不recvTCP窗口會關閉對端發(fā)不過來。我早期代碼里在緩沖區(qū)滿時直接return不recv結果任務一直不阻塞CPU占用100%看門狗復位。后來改成如果緩沖區(qū)剩余空間小于某個閾值比如256字節(jié)就主動consume一些已解析的數(shù)據(jù)但已解析的數(shù)據(jù)已經consume了或者臨時擴大緩沖區(qū)。實際上只要解析循環(huán)及時consume緩沖區(qū)很少會滿。如果真的滿了說明解析速度跟不上接收速度這時候應該降低recv的頻率或者增加任務優(yōu)先級。10. 寫在最后一些個人經驗分片緩存這件事說到底是“不要相信一次recv就能拿到完整消息”。這個原則不僅適用于ModbusTCP也適用于任何基于TCP的自定義協(xié)議。我在ESP32上做過的項目中凡是涉及TCP的我都會加一層分片緩存哪怕協(xié)議本身很簡單。因為WiFi環(huán)境的不確定性遠高于有線以太網你永遠不知道下一個recv會返回多少字節(jié)。另外調試分片問題時抓包工具是必不可少的。我通常用Wireshark抓PC端的包同時用ESP32的日志打印每次recv的字節(jié)數(shù)和緩沖區(qū)狀態(tài)。兩邊對照很快就能定位是分片還是粘包。如果你沒有抓包條件也可以在代碼里加一個簡單的統(tǒng)計記錄每次recv的字節(jié)數(shù)分布如果發(fā)現(xiàn)經常出現(xiàn)小于10字節(jié)的recv那說明分片很嚴重需要檢查LwIP參數(shù)或WiFi信號。最后關于緩沖區(qū)大小我的經驗是寧大勿小。ESP32-S3有512KB SRAM開2KB緩沖區(qū)連零頭都不到。與其為了省1KB內存而冒丟包的風險不如直接開大一點。畢竟在現(xiàn)場調試時丟一個包可能就要折騰半天而內存省下來也沒別的用途。