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