議棧實(shí)戰(zhàn))
1. 為什么嵌入式工程師需要真正理解TCP/IP模型先從一個(gè)真實(shí)場(chǎng)景說(shuō)起。我調(diào)試過(guò)一塊基于Cortex-M4的板子跑的是輕量級(jí)協(xié)議棧設(shè)備需要定時(shí)向服務(wù)器上報(bào)溫濕度數(shù)據(jù)。功能代碼很快就寫(xiě)完了但聯(lián)調(diào)時(shí)發(fā)現(xiàn)一個(gè)詭異的現(xiàn)象設(shè)備運(yùn)行幾個(gè)小時(shí)之后服務(wù)器端就收不到數(shù)據(jù)了ping設(shè)備卻一直通。折騰了大半天最后定位到問(wèn)題出在TCP連接沒(méi)有做異常斷線檢測(cè)服務(wù)器早就把連接斷開(kāi)了設(shè)備端卻還傻傻地以為連接是好的一直往一個(gè)失效的連接上寫(xiě)數(shù)據(jù)。這個(gè)問(wèn)題的根子其實(shí)就在對(duì)TCP/IP模型的理解不夠透徹。當(dāng)時(shí)我只知道“要建立一個(gè)TCP連接”但不清楚這個(gè)連接在協(xié)議棧內(nèi)部到底是怎么維護(hù)的、服務(wù)器斷開(kāi)時(shí)設(shè)備端為什么感知不到、數(shù)據(jù)從應(yīng)用層到網(wǎng)口之間到底經(jīng)過(guò)了哪些處理。對(duì)于搞嵌入式網(wǎng)絡(luò)開(kāi)發(fā)的人來(lái)說(shuō)TCP/IP模型不是一門(mén)需要死記硬背的理論課而是排查問(wèn)題的底層工具。你不需要像計(jì)算機(jī)網(wǎng)絡(luò)專(zhuān)業(yè)的學(xué)生那樣把每個(gè)RFC都翻一遍但你必須要搞清楚數(shù)據(jù)從你的send()函數(shù)出發(fā)到變成網(wǎng)線上的電信號(hào)中間經(jīng)歷了什么反過(guò)來(lái)網(wǎng)線上一堆亂七八糟的字節(jié)流又是怎么被層層剝離最終變成你recv()函數(shù)能讀到的干凈數(shù)據(jù)的。這篇文章不會(huì)去抄教科書(shū)上那套“OSI七層模型”的官話我按自己實(shí)際開(kāi)發(fā)中理解它的方式來(lái)重新講一遍。你會(huì)看到每一層在嵌入式開(kāi)發(fā)里對(duì)應(yīng)的是什么組件、什么代碼、什么現(xiàn)象以及我在實(shí)際項(xiàng)目中踩過(guò)的和這些層直接相關(guān)的坑。2. 數(shù)據(jù)從應(yīng)用到網(wǎng)線一次發(fā)送請(qǐng)求的完整旅程2.1 應(yīng)用層你寫(xiě)的代碼只負(fù)責(zé)到這里拿lwIP一個(gè)輕量級(jí)TCP/IP協(xié)議棧在嵌入式領(lǐng)域用得非常多舉例。當(dāng)你在代碼里調(diào)用tcp_write()或者BSD Socket接口的send()時(shí)你以為數(shù)據(jù)已經(jīng)“發(fā)出去”了但實(shí)際上此刻數(shù)據(jù)只是被拷貝到了協(xié)議棧內(nèi)部的發(fā)送緩沖區(qū)里。這里有個(gè)很多人容易忽略的點(diǎn)send()函數(shù)返回成功只代表數(shù)據(jù)被協(xié)議棧接收了不代表數(shù)據(jù)已經(jīng)到達(dá)對(duì)端甚至不代表數(shù)據(jù)已經(jīng)離開(kāi)本機(jī)網(wǎng)卡。在TCP協(xié)議下如果你調(diào)用send()之后程序崩潰了數(shù)據(jù)很可能就丟在緩沖區(qū)里永遠(yuǎn)發(fā)不出去。應(yīng)用層在TCP/IP模型里的職責(zé)說(shuō)穿了就三件事第一把業(yè)務(wù)數(shù)據(jù)準(zhǔn)備好第二通過(guò)Socket接口把數(shù)據(jù)交給傳輸層第三指定跟誰(shuí)通信目標(biāo)IP和端口。至于數(shù)據(jù)怎么分包、怎么重傳、怎么路由到對(duì)端應(yīng)用層一概不管。這也意味著你代碼里寫(xiě)的所有跟“發(fā)送”相關(guān)的業(yè)務(wù)邏輯都屬于應(yīng)用層范疇。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)一種很典型的錯(cuò)誤寫(xiě)法用send()的返回值來(lái)判斷數(shù)據(jù)是否發(fā)送成功。如果返回值等于數(shù)據(jù)長(zhǎng)度就認(rèn)為發(fā)送成功然后立刻釋放緩沖區(qū)。這在局域網(wǎng)內(nèi)大概率沒(méi)事但在公網(wǎng)或者網(wǎng)絡(luò)抖動(dòng)的情況下這種判斷方式會(huì)出大問(wèn)題。正確的做法是send()只是入隊(duì)操作真正要確認(rèn)數(shù)據(jù)送到對(duì)端需要依賴應(yīng)用層的ACK機(jī)制、業(yè)務(wù)層的應(yīng)答包或者在TCP層面開(kāi)啟SO_LINGER等選項(xiàng)來(lái)檢測(cè)發(fā)送隊(duì)列的狀態(tài)。2.2 傳輸層TCP和UDP的分岔路口數(shù)據(jù)從應(yīng)用層下來(lái)進(jìn)入傳輸層。這一層是嵌入式網(wǎng)絡(luò)開(kāi)發(fā)中碰到的第一個(gè)真正有技術(shù)含量的分水嶺因?yàn)門(mén)CP和UDP的選擇直接影響整個(gè)通信架構(gòu)的設(shè)計(jì)。先看TCP。TCP的核心工作是給數(shù)據(jù)流“編號(hào)”和“記賬”把應(yīng)用層扔過(guò)來(lái)的一長(zhǎng)串字節(jié)切成一個(gè)個(gè)Segment報(bào)文段給每個(gè)Segment編上序號(hào)然后發(fā)送出去。接收端收到之后要回一個(gè)ACK確認(rèn)告訴發(fā)送端“我收到0到1000字節(jié)了”。如果發(fā)送端一段時(shí)間內(nèi)沒(méi)收到ACK就會(huì)觸發(fā)超時(shí)重傳——數(shù)據(jù)沒(méi)送達(dá)重發(fā)一遍。這個(gè)機(jī)制在嵌入式開(kāi)發(fā)里最直接的影響就是TCP是有狀態(tài)的而且狀態(tài)很多。建立一個(gè)連接要三次握手?jǐn)嚅_(kāi)要四次揮手中間還有各種狀態(tài)遷移SYN_SENT、ESTABLISHED、FIN_WAIT_1、TIME_WAIT等等。在MCU這種資源受限的環(huán)境里每一條TCP連接都需要占用幾十KB的RAM來(lái)維護(hù)發(fā)送緩沖區(qū)、接收緩沖區(qū)、擁塞窗口等狀態(tài)信息。這也是為什么很多低端MCU設(shè)備選擇UDP的原因之一——內(nèi)存實(shí)在扛不住。再看UDP。UDP就簡(jiǎn)單粗暴了數(shù)據(jù)報(bào)封裝好加上源端口和目的端口直接扔給網(wǎng)絡(luò)層發(fā)送完就完了。沒(méi)有ACK、沒(méi)有重傳、沒(méi)有擁塞控制、沒(méi)有連接狀態(tài)。所以UDP的頭開(kāi)銷(xiāo)極小處理邏輯也簡(jiǎn)單特別適合數(shù)據(jù)量小、實(shí)時(shí)性要求高、能容忍少量丟失的場(chǎng)景比如傳感器數(shù)據(jù)上報(bào)、設(shè)備狀態(tài)心跳、局域網(wǎng)內(nèi)的控制指令等。嵌入式開(kāi)發(fā)里經(jīng)常有一個(gè)誤區(qū)認(rèn)為“TCP比UDP可靠所以能用TCP就用TCP”。但在實(shí)際項(xiàng)目里TCP的可靠是有代價(jià)的它在網(wǎng)絡(luò)擁塞時(shí)會(huì)主動(dòng)降低發(fā)送速率擁塞控制延遲會(huì)變大而UDP雖然可能丟包但延遲穩(wěn)定可控。比如你要做一個(gè)實(shí)時(shí)音頻流傳輸TCP在丟包后的重傳反而會(huì)導(dǎo)致音頻卡頓UDP配合前向糾錯(cuò)才是更合理的選擇。選哪一層協(xié)議本質(zhì)是在丟包率、延遲、內(nèi)存開(kāi)銷(xiāo)之間做取舍而不是無(wú)腦選“可靠”的那個(gè)。2.3 網(wǎng)絡(luò)層IP地址和路由選擇傳輸層把數(shù)據(jù)交給了網(wǎng)絡(luò)層也就是IP層。這一層干的事情可以概括為在報(bào)文頭部寫(xiě)上源IP地址和目的IP地址然后根據(jù)目的IP查找路由表決定從哪個(gè)網(wǎng)口把數(shù)據(jù)發(fā)出去。對(duì)于嵌入式設(shè)備來(lái)說(shuō)這個(gè)“路由選擇”多數(shù)時(shí)候非常無(wú)腦——因?yàn)樵O(shè)備通常只有一張網(wǎng)卡所有非本機(jī)地址的數(shù)據(jù)默認(rèn)扔給默認(rèn)網(wǎng)關(guān)處理。但在某些場(chǎng)景下路由邏輯會(huì)變得復(fù)雜比如設(shè)備同時(shí)接了以太網(wǎng)和Wi-Fi或者設(shè)備承擔(dān)了某種網(wǎng)關(guān)功能需要對(duì)不同網(wǎng)段的數(shù)據(jù)做轉(zhuǎn)發(fā)。IP層的另一個(gè)重要工作是分片和重組。在嵌入式開(kāi)發(fā)里你更可能遇到的是MTU最大傳輸單元問(wèn)題以太網(wǎng)的MTU通常是1500字節(jié)如果你的應(yīng)用層一次性發(fā)送的數(shù)據(jù)超過(guò)這個(gè)值還要減去IP頭和TCP頭實(shí)際能承載的最大應(yīng)用數(shù)據(jù)大約是1460字節(jié)IP層就需要對(duì)數(shù)據(jù)分片。分片后的每個(gè)IP包如果有一個(gè)丟了整個(gè)原始數(shù)據(jù)包都要重傳效率極低。我在項(xiàng)目里遇到過(guò)一個(gè)典型問(wèn)題設(shè)備向服務(wù)器上傳圖片圖片大小在10KB左右。底層直接調(diào)用send()發(fā)送整個(gè)圖片緩沖區(qū)結(jié)果傳輸速度奇慢無(wú)比甚至偶爾還會(huì)超時(shí)。抓包一看發(fā)現(xiàn)數(shù)據(jù)被分成了二十多個(gè)分片在Wi-Fi網(wǎng)絡(luò)環(huán)境下丟包一多性能就崩了。解決方案其實(shí)不復(fù)雜在應(yīng)用層主動(dòng)把數(shù)據(jù)切成合適的大小通?？刂圃?400字節(jié)以內(nèi)而不是讓IP層去分片。這就是很多協(xié)議在設(shè)計(jì)時(shí)規(guī)定“一條消息不超過(guò)XXX字節(jié)”的原因。2.4 數(shù)據(jù)鏈路層和物理層網(wǎng)卡、驅(qū)動(dòng)和網(wǎng)線上的電信號(hào)最后數(shù)據(jù)到達(dá)數(shù)據(jù)鏈路層和物理層。這一層對(duì)于嵌入式工程師來(lái)說(shuō)就是網(wǎng)卡芯片和對(duì)應(yīng)的驅(qū)動(dòng)程序常見(jiàn)的有SPI接口的W5500、內(nèi)部集成的MAC外部PHY比如STM32的MAC配上LAN8720、或者是各種Wi-Fi模組內(nèi)部自帶的協(xié)議棧。MAC層負(fù)責(zé)把IP層傳下來(lái)的數(shù)據(jù)包封裝成以太網(wǎng)幀加上目的MAC地址、源MAC地址、類(lèi)型字段尾部再附上CRC校驗(yàn)。然后物理層把這個(gè)幀變成電信號(hào)或者光信號(hào)發(fā)到網(wǎng)線上。最直接的一個(gè)例子是兩塊板子用網(wǎng)線直連IP地址配在同一個(gè)網(wǎng)段它們能互相ping通但如果你用的路由器開(kāi)了端口隔離或者交換機(jī)配置了VLAN那么鏈路層可能出現(xiàn)“物理連接正常但數(shù)據(jù)不通”的詭異現(xiàn)象。這一層在開(kāi)發(fā)中最常遇到的問(wèn)題就是CRC錯(cuò)誤和過(guò)高的丟包率。CRC錯(cuò)誤意味著接收到的數(shù)據(jù)包在傳輸過(guò)程中被損壞了通常跟硬件布線有關(guān)——比如RJ45接口的差分信號(hào)線走的太長(zhǎng)、阻抗匹配沒(méi)做好、或者板子上的復(fù)位電路設(shè)計(jì)有問(wèn)題。我排查過(guò)一個(gè)案例板子在常溫下一切正常但放到高低溫環(huán)境中網(wǎng)絡(luò)就開(kāi)始頻繁斷開(kāi)重連最后查到是網(wǎng)口變壓器的選型不當(dāng)溫度漂移導(dǎo)致信號(hào)質(zhì)量嚴(yán)重劣化。3. TCP/IP模型在嵌入式協(xié)議棧中的實(shí)際映射3.1 三種典型的嵌入式協(xié)議棧形態(tài)TCP/IP模型在嵌入式平臺(tái)上的落地方式跟PC上完全不一樣。PC上是操作系統(tǒng)自帶完整的協(xié)議棧你只管調(diào)Socket API就行但在MCU世界里協(xié)議棧的形態(tài)直接決定了你能用它做什么、不能做什么。第一種形態(tài)硬件協(xié)議棧芯片典型代表是WIZnet的W5500。TCP/IP協(xié)議棧整個(gè)燒在芯片內(nèi)部MCU通過(guò)SPI接口跟芯片通信MCU只負(fù)責(zé)發(fā)數(shù)據(jù)、收數(shù)據(jù)所有TCP狀態(tài)機(jī)的維護(hù)、IP分片、校驗(yàn)和計(jì)算全在芯片里完成。好處是MCU內(nèi)存開(kāi)銷(xiāo)極小代碼邏輯簡(jiǎn)單壞處是功能固定靈活性差并發(fā)連接數(shù)通常有限協(xié)議棧的很多高級(jí)特性比如自定義擁塞控制、抓包調(diào)試用不上。第二種形態(tài)純軟件輕量級(jí)協(xié)議棧典型代表是lwIP、uIP、TinyTCP這類(lèi)開(kāi)源方案。協(xié)議棧代碼跟你的應(yīng)用代碼跑在同一個(gè)CPU上共同分享那幾百KB的RAM。這種方案靈活性最高你可以自己裁剪功能、打開(kāi)調(diào)試日志、甚至修改協(xié)議棧源碼來(lái)適配特殊場(chǎng)景。代價(jià)是需要占用一定的FLASH和RAM資源CPU也要花時(shí)間處理協(xié)議棧的運(yùn)算。lwIP是這類(lèi)方案里用得最多的后面重點(diǎn)講它。第三種形態(tài)RTOS自帶的協(xié)議棧比如FreeRTOSTCP、RT-Thread的SALSocket抽象層組件、ThreadX的NetX Duo。這類(lèi)協(xié)議棧跟操作系統(tǒng)的調(diào)度機(jī)制緊密結(jié)合TCP/IP的任務(wù)作為RTOS里的一個(gè)線程運(yùn)行應(yīng)用層通過(guò)標(biāo)準(zhǔn)Socket API或者RTOS自定義的接口來(lái)訪問(wèn)網(wǎng)絡(luò)。這種方案的好處是生態(tài)統(tǒng)一跟RTOS的其他組件信號(hào)量、消息隊(duì)列、互斥鎖聯(lián)動(dòng)方便但學(xué)習(xí)曲線比前兩種形態(tài)都陡。3.2 lwIP的分層架構(gòu)與內(nèi)存管理如何呼應(yīng)TCP/IP模型lwIP的分層設(shè)計(jì)非常清晰地映射了TCP/IP模型搞清楚這個(gè)映射關(guān)系對(duì)排查問(wèn)題非常有幫助。lwIP最底層是網(wǎng)絡(luò)接口層對(duì)應(yīng)到代碼里就是struct netif結(jié)構(gòu)體。你在代碼里寫(xiě)netif_add()就是向lwIP注冊(cè)一個(gè)物理網(wǎng)口。這個(gè)層面對(duì)應(yīng)TCP/IP模型里的數(shù)據(jù)鏈路層和物理層——它負(fù)責(zé)收發(fā)包把網(wǎng)卡驅(qū)動(dòng)收到的以太網(wǎng)幀轉(zhuǎn)交給上層或者把上層發(fā)下來(lái)的IP包交給網(wǎng)卡驅(qū)動(dòng)發(fā)出去。如果你在lwIP里開(kāi)了LWIP_NETIF_LINK_CALLBACK當(dāng)網(wǎng)線插拔時(shí)驅(qū)動(dòng)會(huì)通過(guò)回調(diào)函數(shù)告訴協(xié)議棧鏈路狀態(tài)變了這個(gè)過(guò)程就發(fā)生在這一層。再往上是網(wǎng)絡(luò)層對(duì)應(yīng)ip4.c、ip6.c這些文件。這一層處理IP頭部的解析和封裝、路由查找、分片重組。調(diào)試網(wǎng)絡(luò)問(wèn)題時(shí)經(jīng)常用到的pingICMP請(qǐng)求就是lwIP網(wǎng)絡(luò)層的一部分功能。然后是傳輸層對(duì)應(yīng)tcp.c、udp.c。tcp.c實(shí)現(xiàn)了完整的TCP狀態(tài)機(jī)——三次握手、滑動(dòng)窗口、重傳超時(shí)、擁塞控制全在這一層。lwIP號(hào)稱輕量級(jí)但對(duì)TCP的實(shí)現(xiàn)依然相當(dāng)完整代碼量很大這也是為什么lwIP的編譯配置項(xiàng)特別多的原因每個(gè)功能都可以通過(guò)宏開(kāi)關(guān)來(lái)裁剪。最上面是應(yīng)用層接口lwIP提供了兩種一種是BSD Socket API需要開(kāi)啟LWIP_SOCKET給人一種在PC上編程的熟悉感另一種是raw API或者叫callback API通過(guò)注冊(cè)回調(diào)函數(shù)來(lái)收發(fā)數(shù)據(jù)效率更高適合內(nèi)存緊張的場(chǎng)景。lwIP的內(nèi)存管理機(jī)制是理解這套架構(gòu)的關(guān)鍵。lwIP有兩種內(nèi)存模式一種是靜態(tài)內(nèi)存池提前分配好固定大小的內(nèi)存塊給PBUF包緩沖區(qū)用分配快、不會(huì)產(chǎn)生碎片但靈活性差大包裝不下另一種是動(dòng)態(tài)內(nèi)存堆heap靈活分配但反復(fù)分配釋放會(huì)產(chǎn)生碎片長(zhǎng)時(shí)間運(yùn)行后可能分配不出大的連續(xù)內(nèi)存。這個(gè)特性是很多嵌入式網(wǎng)絡(luò)設(shè)備“跑幾天就死機(jī)”的元兇之一——頻繁的tcp_write()和斷開(kāi)重連會(huì)產(chǎn)生內(nèi)存碎片最終導(dǎo)致pbuf_alloc()失敗TCP連接發(fā)不出去數(shù)據(jù)應(yīng)用程序表現(xiàn)就是“網(wǎng)絡(luò)卡死”。我調(diào)過(guò)的一個(gè)問(wèn)題非常有代表性設(shè)備每10秒上報(bào)一次數(shù)據(jù)但每次上報(bào)前都會(huì)建立一個(gè)TCP連接上報(bào)完就斷開(kāi)。運(yùn)行大約一天之后設(shè)備就再也沒(méi)法聯(lián)網(wǎng)了。查了很久最后確認(rèn)是tcp_abort()調(diào)用得太頻繁協(xié)議棧的PCBsProtocol Control Blocks資源耗盡。TCP/IP模型里的“傳輸層狀態(tài)機(jī)”映射到底層就是這些PCBs和緩沖區(qū)資源你在應(yīng)用層每建立一個(gè)連接都會(huì)占用一個(gè)PCB連接不在正確的時(shí)間釋放資源就會(huì)被慢慢耗盡。這個(gè)案例讓我真正理解了TCP/IP模型的每一層都不是概念而是實(shí)打?qū)嵉膬?nèi)存和狀態(tài)。3.3 狀態(tài)機(jī)與緩沖區(qū)傳輸層的兩個(gè)核心概念TCP的復(fù)雜本質(zhì)上來(lái)源于它是一個(gè)有限狀態(tài)機(jī)。從連接建立到數(shù)據(jù)傳輸?shù)竭B接關(guān)閉連接的狀態(tài)依次經(jīng)歷CLOSED、SYN_SENT、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT等若干狀態(tài)。每個(gè)狀態(tài)下收到什么樣的數(shù)據(jù)包應(yīng)該做什么樣的反應(yīng)都是由代碼預(yù)先定義好的。嵌入式開(kāi)發(fā)里最常碰到的狀態(tài)問(wèn)題有兩個(gè)。第一個(gè)是連接保持Keepalive問(wèn)題。TCP協(xié)議本身有一個(gè)Keepalive機(jī)制可以周期性發(fā)送探測(cè)包來(lái)檢查對(duì)端是否存活但它在lwIP里是默認(rèn)關(guān)閉的LWIP_TCP_KEEPALIVE宏為0因?yàn)闀?huì)額外消耗帶寬和CPU。很多設(shè)備長(zhǎng)期運(yùn)行后連接失效就是因?yàn)闆](méi)有開(kāi)Keepalive底層連接斷了應(yīng)用層卻不知道。第二個(gè)是TIME_WAIT問(wèn)題。主動(dòng)關(guān)閉連接的一方在收到對(duì)端最后一個(gè)ACK之后會(huì)進(jìn)入TIME_WAIT狀態(tài)等2個(gè)最大報(bào)文段壽命MSL后才真正釋放連接。如果設(shè)備頻繁主動(dòng)斷開(kāi)連接同時(shí)又沒(méi)有什么地址和端口復(fù)用配置就會(huì)出現(xiàn)端口被占滿、無(wú)法建立新連接的尷尬。緩沖區(qū)的概念也很重要。TCP發(fā)送方有一個(gè)發(fā)送緩沖區(qū)接收方有一個(gè)接收緩沖區(qū)。send()成功只是把數(shù)據(jù)放進(jìn)了發(fā)送緩沖區(qū)緩沖區(qū)什么時(shí)候真正被清空取決于網(wǎng)絡(luò)擁塞情況和對(duì)端接收窗口的大小。接收緩沖區(qū)同理對(duì)端發(fā)的數(shù)據(jù)到達(dá)后如果應(yīng)用層不及時(shí)recv()緩沖區(qū)就會(huì)滿TCP的流控機(jī)制會(huì)通知對(duì)端把發(fā)送窗口調(diào)小數(shù)據(jù)發(fā)送速度就會(huì)降下來(lái)。這個(gè)“滑動(dòng)窗口”機(jī)制在嵌入式設(shè)備上表現(xiàn)得很直接如果你接收端的應(yīng)用線程處理速度慢偶爾卡一下就會(huì)看到對(duì)端的上報(bào)頻率變慢。我個(gè)人建議任何做嵌入式TCP開(kāi)發(fā)的人都應(yīng)該養(yǎng)成一個(gè)習(xí)慣在腦子里把TCP的每一次收發(fā)都過(guò)一遍狀態(tài)機(jī)。發(fā)了一個(gè)SYN包期望收到SYNACK收不到就是連接超時(shí)連接建立好了數(shù)據(jù)發(fā)送后要啟動(dòng)重傳定時(shí)器收到ACK就取消定時(shí)器收不到就重傳。這個(gè)思維模式建立起來(lái)了網(wǎng)絡(luò)問(wèn)題排查的能力會(huì)上升一個(gè)臺(tái)階。4. 用抓包和日志驗(yàn)證模型一次溫控設(shè)備的數(shù)據(jù)交互拆解4.1 搭建一個(gè)最小的抓包分析環(huán)境理論說(shuō)得再多不如實(shí)際操作一遍。在嵌入式開(kāi)發(fā)中驗(yàn)證TCP/IP模型理解程度的最好工具就是抓包軟件——PC端用Wireshark板子端配合Wireshark抓包。為了演示我以一塊搭載了lwIP協(xié)議棧的以太網(wǎng)板子為例。板子的IP地址設(shè)為192.168.1.100PC的IP地址設(shè)為192.168.1.50兩者通過(guò)一臺(tái)交換機(jī)連接。板子每秒向PC的7000端口發(fā)送一組數(shù)據(jù)內(nèi)容是溫濕度傳感器的數(shù)值比如“T25.3,H60.1”。抓包分兩種情況第一種數(shù)據(jù)只經(jīng)過(guò)交換機(jī)PC的網(wǎng)卡能直接看到所有廣播幀和發(fā)給自己的單播幀第二種板子發(fā)出的數(shù)據(jù)走了路由PC放在另一個(gè)網(wǎng)段這時(shí)需要在交換機(jī)和路由器上配置端口鏡像把板子的流量鏡像到PC網(wǎng)卡。絕大部分調(diào)試場(chǎng)景是第一種結(jié)構(gòu)非常簡(jiǎn)單。在PC上打開(kāi)Wireshark選擇PC的以太網(wǎng)卡過(guò)濾器輸入tcp.port 7000回車(chē)開(kāi)始抓包。如果你的板子SOCKET綁定的是7000端口你立刻就能看到板子發(fā)上來(lái)的TCP報(bào)文。你會(huì)看到連接建立時(shí)先是SYN包接著板子收到PC回復(fù)的SYN, ACK再是板子發(fā)出的ACK——三次握手三個(gè)包次序特別清晰然后就是一堆PSH, ACK包這是TCP層攜帶應(yīng)用數(shù)據(jù)的包最后斷開(kāi)連接時(shí)是FIN, ACK的交互過(guò)程。這個(gè)場(chǎng)景雖然簡(jiǎn)單但如果你想驗(yàn)證自己是否真的理解TCP/IP模型先把這個(gè)流程從抓包里完整地指認(rèn)出來(lái)哪個(gè)是SYN、哪個(gè)是ACK、哪個(gè)是應(yīng)用數(shù)據(jù)、IP頭部里源地址是多少、MAC幀里目標(biāo)地址又是多少、CRC校驗(yàn)在哪一層做的、應(yīng)用層的數(shù)據(jù)在圖上哪個(gè)位置能看到。能答清楚這些TCP/IP模型就不再是概念了。4.2 從抓包結(jié)果逐層讀數(shù)據(jù)拿其中一個(gè)PSH, ACK包來(lái)逐層拆解。Wireshark打開(kāi)這個(gè)包從上到下依次是四段信息。第一段是**Frame幀**信息幀總長(zhǎng)度126字節(jié)這是物理層和鏈路層看到的數(shù)據(jù)——整個(gè)以太網(wǎng)幀的長(zhǎng)度。第二段是**Ethernet II以太網(wǎng)幀頭**信息目的MAC地址是PC網(wǎng)卡的MAC源MAC地址是板子MAC類(lèi)型字段0x0800表示上層承載的是IPv4數(shù)據(jù)報(bào)。這里有個(gè)小細(xì)節(jié)如果路由器做了NAT轉(zhuǎn)發(fā)Wireshark抓到的包可能來(lái)自不同源MAC如果板子發(fā)送的時(shí)候用錯(cuò)了MAC地址比如MAC沒(méi)有燒錄導(dǎo)致全是FF或者和同網(wǎng)段另一塊板子沖突數(shù)據(jù)就會(huì)發(fā)不出去。鏈路層在嵌入式開(kāi)發(fā)里比想象中重要很多。第三段是**Internet Protocol Version 4IP頭**信息協(xié)議字段值為6表示上層是TCP源IP是192.168.1.100目的IP是192.168.1.50頭部長(zhǎng)度20字節(jié)IHL: 5表示5個(gè)32位字標(biāo)識(shí)字段Identification是針對(duì)原始數(shù)據(jù)包的分片ID這里的數(shù)據(jù)包從未分片。還有一個(gè)很重要的字段是TTLTime To Live每經(jīng)過(guò)一個(gè)路由器減1如果減到0包就會(huì)被丟棄。開(kāi)發(fā)中偶爾會(huì)遇到TTL配置過(guò)小導(dǎo)致多跳網(wǎng)絡(luò)不通的情況大多發(fā)生在復(fù)雜局域網(wǎng)場(chǎng)景中。第四段是**Transmission Control ProtocolTCP頭**信息源端口隨機(jī)分配的一個(gè)高位端口目的端口是7000Sequence Number是數(shù)據(jù)字節(jié)流的序號(hào)Acknowledgment Number是期望對(duì)端下一個(gè)發(fā)的字節(jié)序號(hào)也就是“你的序號(hào)N表示N字節(jié)之前的數(shù)據(jù)全部收到”頭部偏移20字節(jié)表示TCP頭長(zhǎng)度。如果你展開(kāi)TCP頭的Flags字段會(huì)看到Push和Ack置位。Push表示發(fā)送緩沖區(qū)有數(shù)據(jù)要立即交給應(yīng)用層處理Ack表示這是一個(gè)確認(rèn)包。TCP頭部之后就是Wireshark解析出來(lái)的應(yīng)用層數(shù)據(jù)這里是T25.3,H60.1十四個(gè)字符。這一層一層地拆下來(lái)其實(shí)就是TCP/IP模型的解碼過(guò)程鏈路層看MAC幀頭網(wǎng)絡(luò)層看IP頭傳輸層看TCP頭應(yīng)用層看真正的業(yè)務(wù)數(shù)據(jù)。反過(guò)來(lái)你要從板子發(fā)送數(shù)據(jù)的角度整體看這個(gè)過(guò)程就是從應(yīng)用層數(shù)據(jù)開(kāi)始逐層加頭、封裝最后變成一個(gè)以太網(wǎng)幀發(fā)出去。4.3 抓包中常見(jiàn)的異?，F(xiàn)象和排查思路抓包分析的最大價(jià)值不是看正常情況而是看異常情況。分享幾個(gè)我在嵌入式調(diào)試中實(shí)際遇到過(guò)的異?！，F(xiàn)象一只有SYN發(fā)出沒(méi)有回應(yīng)。Wireshark里看到板子發(fā)了SYN包但之后沒(méi)有任何包回過(guò)來(lái)。先查網(wǎng)絡(luò)層Ping板子的IP看通不通。如果不通大概率是IP地址沖突或ARP解析失敗板子沒(méi)有回答ARP請(qǐng)求。如果通再看傳輸層PC上對(duì)應(yīng)的端口有沒(méi)有開(kāi)監(jiān)聽(tīng)有沒(méi)有防火墻規(guī)則攔掉了入站連接通常我會(huì)用netstat在PC上查端口監(jiān)聽(tīng)狀態(tài)?，F(xiàn)象二TCP報(bào)文出現(xiàn)大量Dup ACK和Retransmission。丟包率升高了說(shuō)明鏈路質(zhì)量差。在嵌入式場(chǎng)景下首先查的是硬件問(wèn)題網(wǎng)線接觸不良、PHY芯片配置錯(cuò)誤導(dǎo)致速率和雙工模式不匹配比如一邊是100M全雙工一邊是自動(dòng)協(xié)商成了10M半雙工這就會(huì)出現(xiàn)大量沖突和重傳、PCB板上差分信號(hào)走線過(guò)長(zhǎng)導(dǎo)致信號(hào)完整性差。其次查CPU負(fù)載如果MCU中斷優(yōu)先級(jí)配置不合理網(wǎng)卡驅(qū)動(dòng)的中斷被頻繁搶占協(xié)議棧處理不過(guò)來(lái)也會(huì)導(dǎo)致丟包重傳?，F(xiàn)象三接收緩沖區(qū)被撐爆TCP窗口變成0。Wireshark里能看到Win0的包。這說(shuō)明接收端應(yīng)用層取數(shù)據(jù)的速度太慢接收緩沖區(qū)滿了。嵌入式設(shè)備上最常見(jiàn)的原因是接收線程優(yōu)先級(jí)設(shè)置太低被其他任務(wù)餓死了或者代碼里在recv()回調(diào)中做了耗時(shí)的數(shù)據(jù)處理比如加了文件寫(xiě)入、加了解密操作把接收通路堵死了。這個(gè)現(xiàn)象在TCP/IP模型里對(duì)應(yīng)的是傳輸層的流控機(jī)制在正常工作——它不是在制造故障而是防止數(shù)據(jù)溢出。5. 嵌入式網(wǎng)絡(luò)開(kāi)發(fā)中與模型強(qiáng)相關(guān)的常見(jiàn)坑5.1 板子能Ping通但TCP連不上端口、防火墻和半開(kāi)連接“Ping得通但TCP連不上”是在嵌入式集成調(diào)試中排名前三的怪問(wèn)題。Ping用的是ICMP協(xié)議走的是網(wǎng)絡(luò)層TCP連接建立走的是傳輸層這兩者的故障路徑完全不同所以Ping通不代表一切正常。遇到這個(gè)問(wèn)題時(shí)排查順序應(yīng)該是先確認(rèn)PC或服務(wù)器端的服務(wù)端口有沒(méi)有監(jiān)聽(tīng)。在Linux下用ss -lntp在Windows下用netstat -an | findstr 7000。然后關(guān)掉或者放行對(duì)應(yīng)端口的防火墻規(guī)則。如果這兩步都確認(rèn)了沒(méi)問(wèn)題就要考慮是不是設(shè)備端創(chuàng)建TCP連接失敗——看一下lwIP的tcp_connect()返回值常見(jiàn)的錯(cuò)誤是ERR_MEM內(nèi)存不夠和ERR_VAL參數(shù)錯(cuò)誤。對(duì)于前者要調(diào)大MEMP_NUM_TCP_PCB和MEM_SIZE。還有一個(gè)非常隱蔽的坑是半開(kāi)連接Half-open Connection設(shè)備斷電重啟之前沒(méi)有正常關(guān)閉TCP連接服務(wù)器端保留了半開(kāi)狀態(tài)此時(shí)遠(yuǎn)程服務(wù)器會(huì)認(rèn)為舊連接還存在而設(shè)備端重啟后試圖用新的連接配置不當(dāng)會(huì)在服務(wù)器端出現(xiàn)端口占用或者連接重置。解決方式見(jiàn)仁見(jiàn)智我習(xí)慣在所有TCP客戶端里設(shè)置足夠的重傳超時(shí)參數(shù)并且在設(shè)備喚醒時(shí)主動(dòng)清理掉所有遺留的TCP狀態(tài)然后在應(yīng)用層實(shí)現(xiàn)一個(gè)“心跳重連”的機(jī)制。5.2 黏包與拆包問(wèn)題TCP的字節(jié)流特性TCP是流協(xié)議不是消息協(xié)議這一點(diǎn)在嵌入式里會(huì)引發(fā)非常經(jīng)典的問(wèn)題——黏包和拆包。先看黏包設(shè)備連續(xù)調(diào)用兩次send()發(fā)送兩條消息比如先發(fā)“HELLO”再發(fā)“WORLD”。接收端調(diào)用兩次recv()理論上期望先收到“HELLO”再收到“WORLD”但實(shí)際上兩次recv()中第一次收到的可能是“HELLOWORLD”——因?yàn)門(mén)CP層會(huì)把小塊數(shù)據(jù)累積在一起一次性提交給應(yīng)用層這就是黏包。再看拆包設(shè)備一次send()發(fā)送一個(gè)很大的數(shù)據(jù)塊超過(guò)接收端的接收緩沖區(qū)或MTU接收端需要多次recv()才能收到完整數(shù)據(jù)——每一次recv()收到的是整個(gè)消息的一部分這就是拆包。解決黏包、拆包問(wèn)題的核心是在應(yīng)用層設(shè)計(jì)一種“幀格式”或者說(shuō)“消息協(xié)議”。最簡(jiǎn)單的做法是“長(zhǎng)度前綴法”每條消息由“4字節(jié)消息長(zhǎng)度消息正文”組成。接收端先收4個(gè)字節(jié)解析出消息長(zhǎng)度再收對(duì)應(yīng)長(zhǎng)度的正文數(shù)據(jù)控制好緩沖區(qū)邊界就行復(fù)雜一點(diǎn)的做法是使用特殊的幀分隔符比如AT指令的\r\n結(jié)尾但需要對(duì)正文做轉(zhuǎn)義處理起來(lái)稍繁瑣。從TCP/IP模型的角度看黏包和拆包是TCP的字節(jié)流特性在應(yīng)用層的體現(xiàn)。TCP只保證字節(jié)的可靠有序不保證字節(jié)的邊界。你的應(yīng)用層必須自己處理邊界。做了這么多年代碼我的強(qiáng)烈建議是所有設(shè)備上行的數(shù)據(jù)統(tǒng)一設(shè)計(jì)成固定格式的JSON或者TLVType-Length-Value并且劃分好命令I(lǐng)D和數(shù)據(jù)長(zhǎng)度這樣無(wú)論對(duì)端是PC、是網(wǎng)關(guān)還是云平臺(tái)大家都有統(tǒng)一的解析規(guī)則。5.3 IP分片導(dǎo)致的性能問(wèn)題這個(gè)問(wèn)題在前面第2.3節(jié)提到過(guò)但值得單獨(dú)列出來(lái)再講一遍因?yàn)樗且粋€(gè)隱蔽又影響巨大的優(yōu)化點(diǎn)。嵌入式設(shè)備偶爾需要上報(bào)較大的數(shù)據(jù)塊比如OTA升級(jí)包的分包下發(fā)、設(shè)備日志批量上傳、圖片抓拍上傳。如果你在應(yīng)用層直接把大塊數(shù)據(jù)交給send()底層就會(huì)進(jìn)行IP分片。IP分片在日常網(wǎng)絡(luò)環(huán)境里能工作但性能非常差。原因在于IP分片的重組機(jī)制接收端收到第一個(gè)分片后會(huì)占據(jù)一個(gè)重組緩沖區(qū)等待其他分片到齊。只要有一個(gè)分片丟失整個(gè)原始分組就要全部重傳。Wi-Fi環(huán)境的丟包率本來(lái)就比有線網(wǎng)絡(luò)高分片越多整體丟失概率就越大再加上重傳的數(shù)據(jù)包要全部重新走一遍T(mén)CP如果是TCP的話效率極其低下。解決方案前面提過(guò)應(yīng)用層自己做分包。在TCP場(chǎng)景下把每個(gè)發(fā)送單元控制在基于MSS最大分段大小的一個(gè)安全值以內(nèi)通常是1200字節(jié)比較保守但也最穩(wěn)。在UDP場(chǎng)景下更需要注意因?yàn)閁DP報(bào)文分片后任何一個(gè)分片丟失整個(gè)數(shù)據(jù)報(bào)就廢了而且UDP沒(méi)有重傳機(jī)制。所以要嚴(yán)格把每個(gè)UDP數(shù)據(jù)報(bào)的大小控制在鏈路MTU減去IP頭和UDP頭的范圍內(nèi)。5.4 啟動(dòng)過(guò)程中協(xié)議棧初始化順序問(wèn)題嵌入式網(wǎng)絡(luò)設(shè)備的啟動(dòng)過(guò)程實(shí)際上比看起來(lái)復(fù)雜得多。大部分MCU上電后要完成時(shí)鐘初始化、GPIO配置、MAC外設(shè)初始化、PHY芯片復(fù)位、讀取PHY狀態(tài)、分配MAC地址、協(xié)議棧初始化、創(chuàng)建Socket、綁定端口、開(kāi)始監(jiān)聽(tīng)或連接。如果這個(gè)順序錯(cuò)了就會(huì)出現(xiàn)上電后第一次網(wǎng)絡(luò)連接失敗的詭異問(wèn)題。我遇到過(guò)最典型的例子板子重新上電后需要大約30秒才能ping通但如果板子在啟動(dòng)過(guò)程中同時(shí)被串口中斷反復(fù)打擾偶爾會(huì)永遠(yuǎn)ping不通。抓日志發(fā)現(xiàn)PHY芯片的復(fù)位引腳拉低時(shí)間不夠長(zhǎng)PHY沒(méi)有完成內(nèi)部初始化就開(kāi)始訓(xùn)練鏈路。PHY芯片的自動(dòng)協(xié)商Auto-Negotiation在嵌入式開(kāi)發(fā)里是個(gè)大頭尤其是一些低成本的PHY上電穩(wěn)定時(shí)間很長(zhǎng)。解決方案其實(shí)很簡(jiǎn)單上電后給PHY留足穩(wěn)定時(shí)間不要立即查詢它的狀態(tài)寄存器要輪詢直到狀態(tài)寄存器的鏈路建立標(biāo)志位置1然后才開(kāi)始配置MAC和協(xié)議棧。這一步看著不起眼但對(duì)產(chǎn)品上電一次成功率影響極大。5.5 應(yīng)用層重傳與底層重傳的疊加陷阱最后聊一個(gè)很容易被忽視的系統(tǒng)性問(wèn)題應(yīng)用層重傳和TCP底層重傳疊加后會(huì)導(dǎo)致“數(shù)據(jù)風(fēng)暴”。很多嵌入式工程師為了“可靠”在應(yīng)用層實(shí)現(xiàn)了一套超時(shí)重傳機(jī)制發(fā)送一條指令后如果5秒內(nèi)沒(méi)有收到應(yīng)答就重發(fā)。這個(gè)策略本身沒(méi)有問(wèn)題但如果底層的TCP也在做重傳兩個(gè)機(jī)制就會(huì)疊加。假設(shè)網(wǎng)絡(luò)狀況不好TCP的重傳定時(shí)器設(shè)的是3秒應(yīng)用層的超時(shí)時(shí)間也是5秒那應(yīng)用層就會(huì)在TCP還沒(méi)成功送出數(shù)據(jù)時(shí)啟動(dòng)重傳最終導(dǎo)致同一份數(shù)據(jù)被重復(fù)發(fā)送多次對(duì)端收到一堆重復(fù)的指令處理邏輯如果沒(méi)做去重就會(huì)出現(xiàn)重復(fù)下單、重復(fù)控制等嚴(yán)重問(wèn)題。正確的設(shè)計(jì)是明確分工TCP底層負(fù)責(zé)數(shù)據(jù)到達(dá)對(duì)端的可靠性應(yīng)用層負(fù)責(zé)業(yè)務(wù)級(jí)別的確認(rèn)和邏輯去重。如果業(yè)務(wù)確實(shí)需要應(yīng)用層確認(rèn)比如指令要執(zhí)行完成才算數(shù)那么應(yīng)用層的超時(shí)時(shí)間一定要設(shè)計(jì)得比底層TCP最大重傳時(shí)間大很多不能跟TCP的重傳定時(shí)器在同一數(shù)量級(jí)。這個(gè)“明確分工”的思路其實(shí)也是在使用TCP/IP模型時(shí)最重要的一條心法每一層解決每一層的問(wèn)題不要越層也不要重疊。6. 調(diào)試TCP/IP棧時(shí)的幾個(gè)實(shí)用工具與命令原理講清楚了再說(shuō)一下我平時(shí)調(diào)試嵌入式TCP/IP棧時(shí)幾乎必用的工具和手段它們能讓你在工作時(shí)省掉非常多的冤枉路。第一是串口打印時(shí)間戳。在lwIP里打開(kāi)LWIP_DEBUG配合LWIP_DBG_ON和對(duì)應(yīng)的層調(diào)試開(kāi)關(guān)LWIP_DBG_TCP_ON等可以在串口上看到協(xié)議棧內(nèi)部打印的大量狀態(tài)變化。如果是自己寫(xiě)的協(xié)議棧代碼也建議在關(guān)鍵的收包入口、發(fā)包入口、狀態(tài)遷移處打印帶毫秒級(jí)時(shí)間戳的日志。嵌入式系統(tǒng)沒(méi)有g(shù)db遠(yuǎn)程調(diào)試網(wǎng)絡(luò)協(xié)議棧的便利條件串口頭日志就是最可靠的觀測(cè)手段。第二是Wireshark的過(guò)濾器語(yǔ)法。不要看到一堆包就懵。常用的幾組過(guò)濾表達(dá)式tcp.port 7000只看跟7000端口相關(guān)的TCP流量ip.src 192.168.1.100只看某個(gè)源IP的包tcp.flags.syn 1只看SYN包用來(lái)分析連接建立過(guò)程tcp.analysis.retransmission高亮所有TCP重傳包觀察丟包情況http、mqtt、dns按應(yīng)用層協(xié)議過(guò)濾服務(wù)器調(diào)試時(shí)非常常用這里有個(gè)經(jīng)驗(yàn)是抓包時(shí)要盡量直接抓在嵌入式設(shè)備發(fā)出來(lái)的那個(gè)網(wǎng)段不要隔著路由器抓。隔著路由抓到的包經(jīng)過(guò)了NAT和重新封裝源IP、源端口都可能變化根本認(rèn)不出來(lái)哪個(gè)包是設(shè)備發(fā)的。第三是主動(dòng)注入故障來(lái)驗(yàn)證您的排錯(cuò)思路。比如你想確認(rèn)丟包重傳機(jī)制是否工作正?？梢灾苯釉诮粨Q機(jī)和設(shè)備之間加一個(gè)可編程的損耗模塊模擬5%的丟包率然后觀察設(shè)備端是否發(fā)生TCP重傳、延遲有多高。這種主動(dòng)測(cè)試的好處是等到最終上線時(shí)遇到類(lèi)似問(wèn)題你已經(jīng)知道根因在哪一層了。在開(kāi)發(fā)階段做這種測(cè)試的成本遠(yuǎn)遠(yuǎn)低于在客戶現(xiàn)場(chǎng)調(diào)試的代價(jià)。第四是協(xié)議棧統(tǒng)計(jì)信息的暴露。lwIP提供了stats.h里的全局統(tǒng)計(jì)結(jié)構(gòu)體可以讀出TCP重傳次數(shù)、丟棄包數(shù)量、內(nèi)存分配失敗次數(shù)等等。我用過(guò)不少客戶的固件在出廠時(shí)把這些統(tǒng)計(jì)接口全部裁剪掉了調(diào)試時(shí)無(wú)從下手。我一般是保留統(tǒng)計(jì)功能但只在調(diào)試版開(kāi)啟正式發(fā)布時(shí)再裁剪。這樣出問(wèn)題時(shí)只要客戶能反饋一個(gè)統(tǒng)計(jì)信息往往比看串口日志還管用。7. 針對(duì)嵌入式場(chǎng)景的TCP/IP模型優(yōu)化建議7.1 調(diào)整內(nèi)核參數(shù)適配資源受限環(huán)境嵌入式設(shè)備的內(nèi)存資源極其有限需要對(duì)協(xié)議棧參數(shù)做精細(xì)化調(diào)整。不同協(xié)議棧的宏定義名稱不同但優(yōu)化的維度大致相同。TCP PCB數(shù)量默認(rèn)情況下lwIP只支持MEMB_NUM_TCP_PCB個(gè)并發(fā)TCP控制塊mini版本這個(gè)值只有幾個(gè)。如果你的設(shè)備需要同時(shí)維持多個(gè)連接比如一個(gè)連云端、一個(gè)連配置工具就要相應(yīng)調(diào)大。但每個(gè)PCB會(huì)占掉幾百字節(jié)的RAM在MCU上要精打細(xì)算。發(fā)送和接收緩沖區(qū)大小lwIP里對(duì)應(yīng)的宏是TCP_SND_BUF和TCP_WND。發(fā)送緩沖區(qū)小了大塊數(shù)據(jù)要被拆成很多個(gè)TCP段發(fā)送效率低接收窗口小了對(duì)端的發(fā)送速度會(huì)被流控壓住。但調(diào)大又占內(nèi)存。一般我會(huì)先用Wireshark統(tǒng)計(jì)設(shè)備在正常業(yè)務(wù)下的最大吞吐量把緩沖區(qū)設(shè)置成夠用但留存30%余量的水平。注意TCP_WND如果太小會(huì)讓TCP的吞吐量大打折扣而且遇到高延遲網(wǎng)絡(luò)時(shí)性能會(huì)非常差。這個(gè)窗口大小在嵌入式里是很有講究的不是越大越好要在內(nèi)存和性能之間取一個(gè)平衡點(diǎn)。重傳超時(shí)參數(shù)lwIP的TCP_RTO_MS和TCP_RTO_MAX控制重傳定時(shí)器的最小值和最大值。對(duì)于室內(nèi)局域網(wǎng)環(huán)境默認(rèn)值夠用對(duì)于跨公網(wǎng)通信的設(shè)備建議把RTO的最小值調(diào)大一些避免在擁塞情況下瘋狂重傳浪費(fèi)帶寬。這個(gè)參數(shù)如果不調(diào)設(shè)備在弱網(wǎng)環(huán)境下的表現(xiàn)會(huì)非常糟糕。7.2 零拷貝與內(nèi)存池的取舍嵌入式協(xié)議棧的性能瓶頸經(jīng)常不在CPU而在內(nèi)存拷貝。每次數(shù)據(jù)在應(yīng)用層緩沖區(qū)和內(nèi)核緩沖區(qū)之間拷貝都要消耗CPU周期和總線帶寬。lwIP提供了一種思路通過(guò)PBUF的引用計(jì)數(shù)機(jī)制讓?xiě)?yīng)用層直接對(duì)接協(xié)議棧的緩沖區(qū)減少一次拷貝。這個(gè)機(jī)制在數(shù)據(jù)量大的時(shí)候收益非常明顯。但要注意的是零拷貝意味著緩沖區(qū)所有權(quán)和管理權(quán)要交給協(xié)議棧應(yīng)用層不能隨意釋放。這在使用上容易引入內(nèi)存泄漏。如果你的應(yīng)用場(chǎng)景是高頻小包就只有幾十字節(jié)左右零拷貝的收益不大反而增加代碼復(fù)雜度如果你要傳輸音頻、視頻這種大塊數(shù)據(jù)零拷貝就是必選項(xiàng)。我個(gè)人的原則是600字節(jié)以下的數(shù)據(jù)走普通路徑1KB以上的數(shù)據(jù)考慮零拷貝方案。內(nèi)存池和動(dòng)態(tài)堆的選擇也是一樣。內(nèi)存池管理固定大小內(nèi)存塊分配快、無(wú)碎化、確定性高在中斷回調(diào)函數(shù)里分配PBUF時(shí)幾乎只能選它動(dòng)態(tài)堆靈活但長(zhǎng)時(shí)間運(yùn)行之后可能碎片化。lwIP默認(rèn)是內(nèi)存池動(dòng)態(tài)堆結(jié)合的方案PBUF_POOL用于接收PBUF_RAM用于發(fā)送。一個(gè)經(jīng)驗(yàn)法則是接收側(cè)用池因?yàn)榻邮瞻拇笮∠鄬?duì)可控發(fā)送側(cè)用堆因?yàn)閼?yīng)用數(shù)據(jù)大小多變。這樣配置可以在內(nèi)存碎片和分配效率之間取得平衡。7.3 設(shè)計(jì)低功耗設(shè)備時(shí)的網(wǎng)絡(luò)策略低功耗是嵌入式網(wǎng)絡(luò)設(shè)備繞不開(kāi)的話題而TCP/IP協(xié)議棧恰好是低功耗的大敵。TCP連接需要周期性發(fā)送Keepalive包來(lái)維持連接Wi-Fi模組在接收模式下功耗極高UDP雖然開(kāi)銷(xiāo)小但也需要定期向服務(wù)器發(fā)送心跳才能讓NAT映射不老化。低功耗設(shè)備通常采用非對(duì)稱通信模式設(shè)備大部分時(shí)間在休眠只在需要上報(bào)數(shù)據(jù)時(shí)醒來(lái)快速發(fā)送數(shù)據(jù)然后再次休眠。這種模式下TCP長(zhǎng)連接不適合因?yàn)榫S持一條空閑TCP連接的開(kāi)銷(xiāo)遠(yuǎn)超傳輸幾字節(jié)數(shù)據(jù)的收益。更合理的方案是UDP應(yīng)用層心跳或者M(jìn)QTT/CoAP這類(lèi)針對(duì)受限設(shè)備設(shè)計(jì)的應(yīng)用層協(xié)議它們本身有輕量級(jí)的連接?；顧C(jī)制。再往深一層講低功耗設(shè)備的網(wǎng)絡(luò)策略不應(yīng)只考慮功耗還要考慮“窄帶物聯(lián)網(wǎng)”、“LoRa”這類(lèi)傳輸帶寬極小、半雙工的特點(diǎn)。在這種鏈路上跑TCP基本上是個(gè)反模式因?yàn)門(mén)CP的頭開(kāi)銷(xiāo)大、重傳機(jī)制在極窄帶上會(huì)雪崩。正確的做法是用UDP加上前向糾錯(cuò)或使用CoAP這種基于UDP的應(yīng)用層協(xié)議。理解這一點(diǎn)也就能理解為什么LwIP在很多NB-IoT模組里被裁剪到只剩UDP功能了。8. 編譯運(yùn)行一個(gè)基于lwIP的最小實(shí)例講了這么多理論最后用一段可以直接跑的代碼來(lái)收尾。這是一個(gè)基于lwIP STM32F429 Discovery板子的最小TCP客戶端上電后自動(dòng)獲取IPDHCP連接一個(gè)固定的TCP服務(wù)器每秒發(fā)送一條消息。這段代碼雖然簡(jiǎn)單但囊括了從PHY初始化、MAC注冊(cè)、協(xié)議棧初始化到Socket收發(fā)完整流程。首先要做的準(zhǔn)備工作是把lwIP的源碼我用的是2.1.2版本比較穩(wěn)定放進(jìn)工程并在lwipopts.h里配置好關(guān)鍵宏// lwipopts.h 核心配置 #define NO_SYS 0 // 使用RTOS #define LWIP_SOCKET 1 // 啟用Socket API #define LWIP_NETCONN 1 // 啟用netconn API #define LWIP_DHCP 1 // 啟用DHCP客戶端 #define LWIP_STATS 1 // 啟用統(tǒng)計(jì)信息 #define MEM_SIZE (1600 * 10) // 內(nèi)存堆大小 #define TCP_MSS 1460 #define TCP_WND (4 * TCP_MSS) // 接收窗口 #define TCP_SND_BUF (8 * TCP_MSS) // 發(fā)送緩沖區(qū)主程序里主要的初始化流程大致是這樣精簡(jiǎn)版忽略了一些底層驅(qū)動(dòng)細(xì)節(jié)// main.c 核心流程 #include stm32f4xx.h #include lwip/init.h #include lwip/dhcp.h #include lwip/sockets.h #include netif/etharp.h static struct netif g_netif; static cyw43_t cyw43; // 以CYW43為例實(shí)際根據(jù)網(wǎng)卡更改 static char server_ip[] 192.168.1.50; static int server_port 7000; static struct dhcp *g_dhcp; static void network_init(void) { // 1. MAC驅(qū)動(dòng)和PHY初始化這里省略具體硬件操作 cyw43_init(cyw43); // 2. 向lwIP注冊(cè)網(wǎng)卡接口 netif_add(g_netif, NULL, NULL, NULL, cyw43, low_level_output, // 驅(qū)動(dòng)發(fā)送接口 low_level_init, // 驅(qū)動(dòng)初始化接口 ethernet_input); // 收包入口 netif_set_default(g_netif); netif_set_up(g_netif); // 3. 啟動(dòng)DHCP獲取IP地址 g_dhcp dhcp_start(g_netif); while (g_dhcp-state ! DHCP_STATE_BOUND) { sys_check_timeouts(); // 處理協(xié)議棧定時(shí)器 HAL_Delay(10); } } static void tcp_client_task(void *arg) { int sock -1; char buf[64]; for (;;) { if (sock 0) { // 1. 創(chuàng)建Socket sock socket(AF_INET, SOCK_STREAM, 0); if (sock 0) { vTaskDelay(pdMS_TO_TICKS(1000)); continue; } // 2. 連接服務(wù)器 struct sockaddr_in saddr; saddr.sin_family AF_INET; saddr.sin_port htons(server_port); saddr.sin_addr.s_addr inet_addr(server_ip); if (connect(sock, (struct sockaddr *)saddr, sizeof(saddr)) ! 0) { close(sock); sock -1; vTaskDelay(pdMS_TO_TICKS(5000)); continue; } } // 3. 模擬采集溫濕度并上報(bào) float temp 25.0 (rand() % 10) / 10.0; float hum 60.0 (rand() % 10) / 10.0; int len snprintf(buf, sizeof(buf), T%.1f,H%.1f\r\n, temp, hum); int ret send(sock, buf, len, 0); if (ret 0) { close(sock); sock -1; } vTaskDelay(pdMS_TO_TICKS(1000)); // 1秒發(fā)送一次 } }這里有個(gè)非常重要的細(xì)節(jié)TCP客戶端的重連邏輯。這段代碼中如果connect()失敗、send()返回值異常就關(guān)閉Socket并重新創(chuàng)建。如果不寫(xiě)這段邏輯設(shè)備在服務(wù)器重啟或網(wǎng)絡(luò)斷開(kāi)的場(chǎng)景下會(huì)永遠(yuǎn)卡在舊連接上。這是嵌入式TCP客戶端最基本也最核心的可靠性設(shè)計(jì)之一。此外lwIP是一個(gè)非阻塞的事件驅(qū)動(dòng)協(xié)議棧它必須通過(guò)sys_check_timeouts()周期性地處理重傳定時(shí)器、ARP老化等內(nèi)部事件。在裸機(jī)環(huán)境下你要在主循環(huán)里調(diào)用它在上面的RTOS環(huán)境下也要有某個(gè)任務(wù)負(fù)責(zé)周期性調(diào)用它。初學(xué)者最容易犯的錯(cuò)就是忘了調(diào)這個(gè)函數(shù)導(dǎo)致TCP連接永遠(yuǎn)建立不起來(lái)、ARP表永遠(yuǎn)不刷新。編譯燒錄之后在PC上用nc -l 7000監(jiān)聽(tīng)端口板子上電啟動(dòng)后你應(yīng)該能在終端看到每秒一行Txx.x,Hxx.x的輸出。如果看到這個(gè)輸出恭喜你的板子已經(jīng)能通過(guò)完整的TCP/IP模型鏈路收發(fā)數(shù)據(jù)了。這時(shí)候再回頭看我前兩章講的那些概念你會(huì)有一個(gè)完全不同的感受——它們不再是紙面上的圖而是實(shí)實(shí)在在地在你的板子和PC之間流動(dòng)著。 嵌入式工程師必讀：深入理解TCP/IP模型與lwIP協(xié)議棧實(shí)戰(zhàn)
1. 為什么嵌入式工程師需要真正理解TCP/IP模型先從一個(gè)真實(shí)場(chǎng)景說(shuō)起。我調(diào)試過(guò)一塊基于Cortex-M4的板子跑的是輕量級(jí)協(xié)議棧設(shè)備需要定時(shí)向服務(wù)器上報(bào)溫濕度數(shù)據(jù)。功能代碼很快就寫(xiě)完了但聯(lián)調(diào)時(shí)發(fā)現(xiàn)一個(gè)詭異的現(xiàn)象設(shè)備運(yùn)行幾個(gè)小時(shí)之后服務(wù)器端就收不到數(shù)據(jù)了ping設(shè)備卻一直通。折騰了大半天最后定位到問(wèn)題出在TCP連接沒(méi)有做異常斷線檢測(cè)服務(wù)器早就把連接斷開(kāi)了設(shè)備端卻還傻傻地以為連接是好的一直往一個(gè)失效的連接上寫(xiě)數(shù)據(jù)。這個(gè)問(wèn)題的根子其實(shí)就在對(duì)TCP/IP模型的理解不夠透徹。當(dāng)時(shí)我只知道“要建立一個(gè)TCP連接”但不清楚這個(gè)連接在協(xié)議棧內(nèi)部到底是怎么維護(hù)的、服務(wù)器斷開(kāi)時(shí)設(shè)備端為什么感知不到、數(shù)據(jù)從應(yīng)用層到網(wǎng)口之間到底經(jīng)過(guò)了哪些處理。對(duì)于搞嵌入式網(wǎng)絡(luò)開(kāi)發(fā)的人來(lái)說(shuō)TCP/IP模型不是一門(mén)需要死記硬背的理論課而是排查問(wèn)題的底層工具。你不需要像計(jì)算機(jī)網(wǎng)絡(luò)專(zhuān)業(yè)的學(xué)生那樣把每個(gè)RFC都翻一遍但你必須要搞清楚數(shù)據(jù)從你的send()函數(shù)出發(fā)到變成網(wǎng)線上的電信號(hào)中間經(jīng)歷了什么反過(guò)來(lái)網(wǎng)線上一堆亂七八糟的字節(jié)流又是怎么被層層剝離最終變成你recv()函數(shù)能讀到的干凈數(shù)據(jù)的。這篇文章不會(huì)去抄教科書(shū)上那套“OSI七層模型”的官話我按自己實(shí)際開(kāi)發(fā)中理解它的方式來(lái)重新講一遍。你會(huì)看到每一層在嵌入式開(kāi)發(fā)里對(duì)應(yīng)的是什么組件、什么代碼、什么現(xiàn)象以及我在實(shí)際項(xiàng)目中踩過(guò)的和這些層直接相關(guān)的坑。2. 數(shù)據(jù)從應(yīng)用到網(wǎng)線一次發(fā)送請(qǐng)求的完整旅程2.1 應(yīng)用層你寫(xiě)的代碼只負(fù)責(zé)到這里拿lwIP一個(gè)輕量級(jí)TCP/IP協(xié)議棧在嵌入式領(lǐng)域用得非常多舉例。當(dāng)你在代碼里調(diào)用tcp_write()或者BSD Socket接口的send()時(shí)你以為數(shù)據(jù)已經(jīng)“發(fā)出去”了但實(shí)際上此刻數(shù)據(jù)只是被拷貝到了協(xié)議棧內(nèi)部的發(fā)送緩沖區(qū)里。這里有個(gè)很多人容易忽略的點(diǎn)send()函數(shù)返回成功只代表數(shù)據(jù)被協(xié)議棧接收了不代表數(shù)據(jù)已經(jīng)到達(dá)對(duì)端甚至不代表數(shù)據(jù)已經(jīng)離開(kāi)本機(jī)網(wǎng)卡。在TCP協(xié)議下如果你調(diào)用send()之后程序崩潰了數(shù)據(jù)很可能就丟在緩沖區(qū)里永遠(yuǎn)發(fā)不出去。應(yīng)用層在TCP/IP模型里的職責(zé)說(shuō)穿了就三件事第一把業(yè)務(wù)數(shù)據(jù)準(zhǔn)備好第二通過(guò)Socket接口把數(shù)據(jù)交給傳輸層第三指定跟誰(shuí)通信目標(biāo)IP和端口。至于數(shù)據(jù)怎么分包、怎么重傳、怎么路由到對(duì)端應(yīng)用層一概不管。這也意味著你代碼里寫(xiě)的所有跟“發(fā)送”相關(guān)的業(yè)務(wù)邏輯都屬于應(yīng)用層范疇。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)一種很典型的錯(cuò)誤寫(xiě)法用send()的返回值來(lái)判斷數(shù)據(jù)是否發(fā)送成功。如果返回值等于數(shù)據(jù)長(zhǎng)度就認(rèn)為發(fā)送成功然后立刻釋放緩沖區(qū)。這在局域網(wǎng)內(nèi)大概率沒(méi)事但在公網(wǎng)或者網(wǎng)絡(luò)抖動(dòng)的情況下這種判斷方式會(huì)出大問(wèn)題。正確的做法是send()只是入隊(duì)操作真正要確認(rèn)數(shù)據(jù)送到對(duì)端需要依賴應(yīng)用層的ACK機(jī)制、業(yè)務(wù)層的應(yīng)答包或者在TCP層面開(kāi)啟SO_LINGER等選項(xiàng)來(lái)檢測(cè)發(fā)送隊(duì)列的狀態(tài)。2.2 傳輸層TCP和UDP的分岔路口數(shù)據(jù)從應(yīng)用層下來(lái)進(jìn)入傳輸層。這一層是嵌入式網(wǎng)絡(luò)開(kāi)發(fā)中碰到的第一個(gè)真正有技術(shù)含量的分水嶺因?yàn)門(mén)CP和UDP的選擇直接影響整個(gè)通信架構(gòu)的設(shè)計(jì)。先看TCP。TCP的核心工作是給數(shù)據(jù)流“編號(hào)”和“記賬”把應(yīng)用層扔過(guò)來(lái)的一長(zhǎng)串字節(jié)切成一個(gè)個(gè)Segment報(bào)文段給每個(gè)Segment編上序號(hào)然后發(fā)送出去。接收端收到之后要回一個(gè)ACK確認(rèn)告訴發(fā)送端“我收到0到1000字節(jié)了”。如果發(fā)送端一段時(shí)間內(nèi)沒(méi)收到ACK就會(huì)觸發(fā)超時(shí)重傳——數(shù)據(jù)沒(méi)送達(dá)重發(fā)一遍。這個(gè)機(jī)制在嵌入式開(kāi)發(fā)里最直接的影響就是TCP是有狀態(tài)的而且狀態(tài)很多。建立一個(gè)連接要三次握手?jǐn)嚅_(kāi)要四次揮手中間還有各種狀態(tài)遷移SYN_SENT、ESTABLISHED、FIN_WAIT_1、TIME_WAIT等等。在MCU這種資源受限的環(huán)境里每一條TCP連接都需要占用幾十KB的RAM來(lái)維護(hù)發(fā)送緩沖區(qū)、接收緩沖區(qū)、擁塞窗口等狀態(tài)信息。這也是為什么很多低端MCU設(shè)備選擇UDP的原因之一——內(nèi)存實(shí)在扛不住。再看UDP。UDP就簡(jiǎn)單粗暴了數(shù)據(jù)報(bào)封裝好加上源端口和目的端口直接扔給網(wǎng)絡(luò)層發(fā)送完就完了。沒(méi)有ACK、沒(méi)有重傳、沒(méi)有擁塞控制、沒(méi)有連接狀態(tài)。所以UDP的頭開(kāi)銷(xiāo)極小處理邏輯也簡(jiǎn)單特別適合數(shù)據(jù)量小、實(shí)時(shí)性要求高、能容忍少量丟失的場(chǎng)景比如傳感器數(shù)據(jù)上報(bào)、設(shè)備狀態(tài)心跳、局域網(wǎng)內(nèi)的控制指令等。嵌入式開(kāi)發(fā)里經(jīng)常有一個(gè)誤區(qū)認(rèn)為“TCP比UDP可靠所以能用TCP就用TCP”。但在實(shí)際項(xiàng)目里TCP的可靠是有代價(jià)的它在網(wǎng)絡(luò)擁塞時(shí)會(huì)主動(dòng)降低發(fā)送速率擁塞控制延遲會(huì)變大而UDP雖然可能丟包但延遲穩(wěn)定可控。比如你要做一個(gè)實(shí)時(shí)音頻流傳輸TCP在丟包后的重傳反而會(huì)導(dǎo)致音頻卡頓UDP配合前向糾錯(cuò)才是更合理的選擇。選哪一層協(xié)議本質(zhì)是在丟包率、延遲、內(nèi)存開(kāi)銷(xiāo)之間做取舍而不是無(wú)腦選“可靠”的那個(gè)。2.3 網(wǎng)絡(luò)層IP地址和路由選擇傳輸層把數(shù)據(jù)交給了網(wǎng)絡(luò)層也就是IP層。這一層干的事情可以概括為在報(bào)文頭部寫(xiě)上源IP地址和目的IP地址然后根據(jù)目的IP查找路由表決定從哪個(gè)網(wǎng)口把數(shù)據(jù)發(fā)出去。對(duì)于嵌入式設(shè)備來(lái)說(shuō)這個(gè)“路由選擇”多數(shù)時(shí)候非常無(wú)腦——因?yàn)樵O(shè)備通常只有一張網(wǎng)卡所有非本機(jī)地址的數(shù)據(jù)默認(rèn)扔給默認(rèn)網(wǎng)關(guān)處理。但在某些場(chǎng)景下路由邏輯會(huì)變得復(fù)雜比如設(shè)備同時(shí)接了以太網(wǎng)和Wi-Fi或者設(shè)備承擔(dān)了某種網(wǎng)關(guān)功能需要對(duì)不同網(wǎng)段的數(shù)據(jù)做轉(zhuǎn)發(fā)。IP層的另一個(gè)重要工作是分片和重組。在嵌入式開(kāi)發(fā)里你更可能遇到的是MTU最大傳輸單元問(wèn)題以太網(wǎng)的MTU通常是1500字節(jié)如果你的應(yīng)用層一次性發(fā)送的數(shù)據(jù)超過(guò)這個(gè)值還要減去IP頭和TCP頭實(shí)際能承載的最大應(yīng)用數(shù)據(jù)大約是1460字節(jié)IP層就需要對(duì)數(shù)據(jù)分片。分片后的每個(gè)IP包如果有一個(gè)丟了整個(gè)原始數(shù)據(jù)包都要重傳效率極低。我在項(xiàng)目里遇到過(guò)一個(gè)典型問(wèn)題設(shè)備向服務(wù)器上傳圖片圖片大小在10KB左右。底層直接調(diào)用send()發(fā)送整個(gè)圖片緩沖區(qū)結(jié)果傳輸速度奇慢無(wú)比甚至偶爾還會(huì)超時(shí)。抓包一看發(fā)現(xiàn)數(shù)據(jù)被分成了二十多個(gè)分片在Wi-Fi網(wǎng)絡(luò)環(huán)境下丟包一多性能就崩了。解決方案其實(shí)不復(fù)雜在應(yīng)用層主動(dòng)把數(shù)據(jù)切成合適的大小通?？刂圃?400字節(jié)以內(nèi)而不是讓IP層去分片。這就是很多協(xié)議在設(shè)計(jì)時(shí)規(guī)定“一條消息不超過(guò)XXX字節(jié)”的原因。2.4 數(shù)據(jù)鏈路層和物理層網(wǎng)卡、驅(qū)動(dòng)和網(wǎng)線上的電信號(hào)最后數(shù)據(jù)到達(dá)數(shù)據(jù)鏈路層和物理層。這一層對(duì)于嵌入式工程師來(lái)說(shuō)就是網(wǎng)卡芯片和對(duì)應(yīng)的驅(qū)動(dòng)程序常見(jiàn)的有SPI接口的W5500、內(nèi)部集成的MAC外部PHY比如STM32的MAC配上LAN8720、或者是各種Wi-Fi模組內(nèi)部自帶的協(xié)議棧。MAC層負(fù)責(zé)把IP層傳下來(lái)的數(shù)據(jù)包封裝成以太網(wǎng)幀加上目的MAC地址、源MAC地址、類(lèi)型字段尾部再附上CRC校驗(yàn)。然后物理層把這個(gè)幀變成電信號(hào)或者光信號(hào)發(fā)到網(wǎng)線上。最直接的一個(gè)例子是兩塊板子用網(wǎng)線直連IP地址配在同一個(gè)網(wǎng)段它們能互相ping通但如果你用的路由器開(kāi)了端口隔離或者交換機(jī)配置了VLAN那么鏈路層可能出現(xiàn)“物理連接正常但數(shù)據(jù)不通”的詭異現(xiàn)象。這一層在開(kāi)發(fā)中最常遇到的問(wèn)題就是CRC錯(cuò)誤和過(guò)高的丟包率。CRC錯(cuò)誤意味著接收到的數(shù)據(jù)包在傳輸過(guò)程中被損壞了通常跟硬件布線有關(guān)——比如RJ45接口的差分信號(hào)線走的太長(zhǎng)、阻抗匹配沒(méi)做好、或者板子上的復(fù)位電路設(shè)計(jì)有問(wèn)題。我排查過(guò)一個(gè)案例板子在常溫下一切正常但放到高低溫環(huán)境中網(wǎng)絡(luò)就開(kāi)始頻繁斷開(kāi)重連最后查到是網(wǎng)口變壓器的選型不當(dāng)溫度漂移導(dǎo)致信號(hào)質(zhì)量嚴(yán)重劣化。3. TCP/IP模型在嵌入式協(xié)議棧中的實(shí)際映射3.1 三種典型的嵌入式協(xié)議棧形態(tài)TCP/IP模型在嵌入式平臺(tái)上的落地方式跟PC上完全不一樣。PC上是操作系統(tǒng)自帶完整的協(xié)議棧你只管調(diào)Socket API就行但在MCU世界里協(xié)議棧的形態(tài)直接決定了你能用它做什么、不能做什么。第一種形態(tài)硬件協(xié)議棧芯片典型代表是WIZnet的W5500。TCP/IP協(xié)議棧整個(gè)燒在芯片內(nèi)部MCU通過(guò)SPI接口跟芯片通信MCU只負(fù)責(zé)發(fā)數(shù)據(jù)、收數(shù)據(jù)所有TCP狀態(tài)機(jī)的維護(hù)、IP分片、校驗(yàn)和計(jì)算全在芯片里完成。好處是MCU內(nèi)存開(kāi)銷(xiāo)極小代碼邏輯簡(jiǎn)單壞處是功能固定靈活性差并發(fā)連接數(shù)通常有限協(xié)議棧的很多高級(jí)特性比如自定義擁塞控制、抓包調(diào)試用不上。第二種形態(tài)純軟件輕量級(jí)協(xié)議棧典型代表是lwIP、uIP、TinyTCP這類(lèi)開(kāi)源方案。協(xié)議棧代碼跟你的應(yīng)用代碼跑在同一個(gè)CPU上共同分享那幾百KB的RAM。這種方案靈活性最高你可以自己裁剪功能、打開(kāi)調(diào)試日志、甚至修改協(xié)議棧源碼來(lái)適配特殊場(chǎng)景。代價(jià)是需要占用一定的FLASH和RAM資源CPU也要花時(shí)間處理協(xié)議棧的運(yùn)算。lwIP是這類(lèi)方案里用得最多的后面重點(diǎn)講它。第三種形態(tài)RTOS自帶的協(xié)議棧比如FreeRTOSTCP、RT-Thread的SALSocket抽象層組件、ThreadX的NetX Duo。這類(lèi)協(xié)議棧跟操作系統(tǒng)的調(diào)度機(jī)制緊密結(jié)合TCP/IP的任務(wù)作為RTOS里的一個(gè)線程運(yùn)行應(yīng)用層通過(guò)標(biāo)準(zhǔn)Socket API或者RTOS自定義的接口來(lái)訪問(wèn)網(wǎng)絡(luò)。這種方案的好處是生態(tài)統(tǒng)一跟RTOS的其他組件信號(hào)量、消息隊(duì)列、互斥鎖聯(lián)動(dòng)方便但學(xué)習(xí)曲線比前兩種形態(tài)都陡。3.2 lwIP的分層架構(gòu)與內(nèi)存管理如何呼應(yīng)TCP/IP模型lwIP的分層設(shè)計(jì)非常清晰地映射了TCP/IP模型搞清楚這個(gè)映射關(guān)系對(duì)排查問(wèn)題非常有幫助。lwIP最底層是網(wǎng)絡(luò)接口層對(duì)應(yīng)到代碼里就是struct netif結(jié)構(gòu)體。你在代碼里寫(xiě)netif_add()就是向lwIP注冊(cè)一個(gè)物理網(wǎng)口。這個(gè)層面對(duì)應(yīng)TCP/IP模型里的數(shù)據(jù)鏈路層和物理層——它負(fù)責(zé)收發(fā)包把網(wǎng)卡驅(qū)動(dòng)收到的以太網(wǎng)幀轉(zhuǎn)交給上層或者把上層發(fā)下來(lái)的IP包交給網(wǎng)卡驅(qū)動(dòng)發(fā)出去。如果你在lwIP里開(kāi)了LWIP_NETIF_LINK_CALLBACK當(dāng)網(wǎng)線插拔時(shí)驅(qū)動(dòng)會(huì)通過(guò)回調(diào)函數(shù)告訴協(xié)議棧鏈路狀態(tài)變了這個(gè)過(guò)程就發(fā)生在這一層。再往上是網(wǎng)絡(luò)層對(duì)應(yīng)ip4.c、ip6.c這些文件。這一層處理IP頭部的解析和封裝、路由查找、分片重組。調(diào)試網(wǎng)絡(luò)問(wèn)題時(shí)經(jīng)常用到的pingICMP請(qǐng)求就是lwIP網(wǎng)絡(luò)層的一部分功能。然后是傳輸層對(duì)應(yīng)tcp.c、udp.c。tcp.c實(shí)現(xiàn)了完整的TCP狀態(tài)機(jī)——三次握手、滑動(dòng)窗口、重傳超時(shí)、擁塞控制全在這一層。lwIP號(hào)稱輕量級(jí)但對(duì)TCP的實(shí)現(xiàn)依然相當(dāng)完整代碼量很大這也是為什么lwIP的編譯配置項(xiàng)特別多的原因每個(gè)功能都可以通過(guò)宏開(kāi)關(guān)來(lái)裁剪。最上面是應(yīng)用層接口lwIP提供了兩種一種是BSD Socket API需要開(kāi)啟LWIP_SOCKET給人一種在PC上編程的熟悉感另一種是raw API或者叫callback API通過(guò)注冊(cè)回調(diào)函數(shù)來(lái)收發(fā)數(shù)據(jù)效率更高適合內(nèi)存緊張的場(chǎng)景。lwIP的內(nèi)存管理機(jī)制是理解這套架構(gòu)的關(guān)鍵。lwIP有兩種內(nèi)存模式一種是靜態(tài)內(nèi)存池提前分配好固定大小的內(nèi)存塊給PBUF包緩沖區(qū)用分配快、不會(huì)產(chǎn)生碎片但靈活性差大包裝不下另一種是動(dòng)態(tài)內(nèi)存堆heap靈活分配但反復(fù)分配釋放會(huì)產(chǎn)生碎片長(zhǎng)時(shí)間運(yùn)行后可能分配不出大的連續(xù)內(nèi)存。這個(gè)特性是很多嵌入式網(wǎng)絡(luò)設(shè)備“跑幾天就死機(jī)”的元兇之一——頻繁的tcp_write()和斷開(kāi)重連會(huì)產(chǎn)生內(nèi)存碎片最終導(dǎo)致pbuf_alloc()失敗TCP連接發(fā)不出去數(shù)據(jù)應(yīng)用程序表現(xiàn)就是“網(wǎng)絡(luò)卡死”。我調(diào)過(guò)的一個(gè)問(wèn)題非常有代表性設(shè)備每10秒上報(bào)一次數(shù)據(jù)但每次上報(bào)前都會(huì)建立一個(gè)TCP連接上報(bào)完就斷開(kāi)。運(yùn)行大約一天之后設(shè)備就再也沒(méi)法聯(lián)網(wǎng)了。查了很久最后確認(rèn)是tcp_abort()調(diào)用得太頻繁協(xié)議棧的PCBsProtocol Control Blocks資源耗盡。TCP/IP模型里的“傳輸層狀態(tài)機(jī)”映射到底層就是這些PCBs和緩沖區(qū)資源你在應(yīng)用層每建立一個(gè)連接都會(huì)占用一個(gè)PCB連接不在正確的時(shí)間釋放資源就會(huì)被慢慢耗盡。這個(gè)案例讓我真正理解了TCP/IP模型的每一層都不是概念而是實(shí)打?qū)嵉膬?nèi)存和狀態(tài)。3.3 狀態(tài)機(jī)與緩沖區(qū)傳輸層的兩個(gè)核心概念TCP的復(fù)雜本質(zhì)上來(lái)源于它是一個(gè)有限狀態(tài)機(jī)。從連接建立到數(shù)據(jù)傳輸?shù)竭B接關(guān)閉連接的狀態(tài)依次經(jīng)歷CLOSED、SYN_SENT、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT等若干狀態(tài)。每個(gè)狀態(tài)下收到什么樣的數(shù)據(jù)包應(yīng)該做什么樣的反應(yīng)都是由代碼預(yù)先定義好的。嵌入式開(kāi)發(fā)里最常碰到的狀態(tài)問(wèn)題有兩個(gè)。第一個(gè)是連接保持Keepalive問(wèn)題。TCP協(xié)議本身有一個(gè)Keepalive機(jī)制可以周期性發(fā)送探測(cè)包來(lái)檢查對(duì)端是否存活但它在lwIP里是默認(rèn)關(guān)閉的LWIP_TCP_KEEPALIVE宏為0因?yàn)闀?huì)額外消耗帶寬和CPU。很多設(shè)備長(zhǎng)期運(yùn)行后連接失效就是因?yàn)闆](méi)有開(kāi)Keepalive底層連接斷了應(yīng)用層卻不知道。第二個(gè)是TIME_WAIT問(wèn)題。主動(dòng)關(guān)閉連接的一方在收到對(duì)端最后一個(gè)ACK之后會(huì)進(jìn)入TIME_WAIT狀態(tài)等2個(gè)最大報(bào)文段壽命MSL后才真正釋放連接。如果設(shè)備頻繁主動(dòng)斷開(kāi)連接同時(shí)又沒(méi)有什么地址和端口復(fù)用配置就會(huì)出現(xiàn)端口被占滿、無(wú)法建立新連接的尷尬。緩沖區(qū)的概念也很重要。TCP發(fā)送方有一個(gè)發(fā)送緩沖區(qū)接收方有一個(gè)接收緩沖區(qū)。send()成功只是把數(shù)據(jù)放進(jìn)了發(fā)送緩沖區(qū)緩沖區(qū)什么時(shí)候真正被清空取決于網(wǎng)絡(luò)擁塞情況和對(duì)端接收窗口的大小。接收緩沖區(qū)同理對(duì)端發(fā)的數(shù)據(jù)到達(dá)后如果應(yīng)用層不及時(shí)recv()緩沖區(qū)就會(huì)滿TCP的流控機(jī)制會(huì)通知對(duì)端把發(fā)送窗口調(diào)小數(shù)據(jù)發(fā)送速度就會(huì)降下來(lái)。這個(gè)“滑動(dòng)窗口”機(jī)制在嵌入式設(shè)備上表現(xiàn)得很直接如果你接收端的應(yīng)用線程處理速度慢偶爾卡一下就會(huì)看到對(duì)端的上報(bào)頻率變慢。我個(gè)人建議任何做嵌入式TCP開(kāi)發(fā)的人都應(yīng)該養(yǎng)成一個(gè)習(xí)慣在腦子里把TCP的每一次收發(fā)都過(guò)一遍狀態(tài)機(jī)。發(fā)了一個(gè)SYN包期望收到SYNACK收不到就是連接超時(shí)連接建立好了數(shù)據(jù)發(fā)送后要啟動(dòng)重傳定時(shí)器收到ACK就取消定時(shí)器收不到就重傳。這個(gè)思維模式建立起來(lái)了網(wǎng)絡(luò)問(wèn)題排查的能力會(huì)上升一個(gè)臺(tái)階。4. 用抓包和日志驗(yàn)證模型一次溫控設(shè)備的數(shù)據(jù)交互拆解4.1 搭建一個(gè)最小的抓包分析環(huán)境理論說(shuō)得再多不如實(shí)際操作一遍。在嵌入式開(kāi)發(fā)中驗(yàn)證TCP/IP模型理解程度的最好工具就是抓包軟件——PC端用Wireshark板子端配合Wireshark抓包。為了演示我以一塊搭載了lwIP協(xié)議棧的以太網(wǎng)板子為例。板子的IP地址設(shè)為192.168.1.100PC的IP地址設(shè)為192.168.1.50兩者通過(guò)一臺(tái)交換機(jī)連接。板子每秒向PC的7000端口發(fā)送一組數(shù)據(jù)內(nèi)容是溫濕度傳感器的數(shù)值比如“T25.3,H60.1”。抓包分兩種情況第一種數(shù)據(jù)只經(jīng)過(guò)交換機(jī)PC的網(wǎng)卡能直接看到所有廣播幀和發(fā)給自己的單播幀第二種板子發(fā)出的數(shù)據(jù)走了路由PC放在另一個(gè)網(wǎng)段這時(shí)需要在交換機(jī)和路由器上配置端口鏡像把板子的流量鏡像到PC網(wǎng)卡。絕大部分調(diào)試場(chǎng)景是第一種結(jié)構(gòu)非常簡(jiǎn)單。在PC上打開(kāi)Wireshark選擇PC的以太網(wǎng)卡過(guò)濾器輸入tcp.port 7000回車(chē)開(kāi)始抓包。如果你的板子SOCKET綁定的是7000端口你立刻就能看到板子發(fā)上來(lái)的TCP報(bào)文。你會(huì)看到連接建立時(shí)先是SYN包接著板子收到PC回復(fù)的SYN, ACK再是板子發(fā)出的ACK——三次握手三個(gè)包次序特別清晰然后就是一堆PSH, ACK包這是TCP層攜帶應(yīng)用數(shù)據(jù)的包最后斷開(kāi)連接時(shí)是FIN, ACK的交互過(guò)程。這個(gè)場(chǎng)景雖然簡(jiǎn)單但如果你想驗(yàn)證自己是否真的理解TCP/IP模型先把這個(gè)流程從抓包里完整地指認(rèn)出來(lái)哪個(gè)是SYN、哪個(gè)是ACK、哪個(gè)是應(yīng)用數(shù)據(jù)、IP頭部里源地址是多少、MAC幀里目標(biāo)地址又是多少、CRC校驗(yàn)在哪一層做的、應(yīng)用層的數(shù)據(jù)在圖上哪個(gè)位置能看到。能答清楚這些TCP/IP模型就不再是概念了。4.2 從抓包結(jié)果逐層讀數(shù)據(jù)拿其中一個(gè)PSH, ACK包來(lái)逐層拆解。Wireshark打開(kāi)這個(gè)包從上到下依次是四段信息。第一段是**Frame幀**信息幀總長(zhǎng)度126字節(jié)這是物理層和鏈路層看到的數(shù)據(jù)——整個(gè)以太網(wǎng)幀的長(zhǎng)度。第二段是**Ethernet II以太網(wǎng)幀頭**信息目的MAC地址是PC網(wǎng)卡的MAC源MAC地址是板子MAC類(lèi)型字段0x0800表示上層承載的是IPv4數(shù)據(jù)報(bào)。這里有個(gè)小細(xì)節(jié)如果路由器做了NAT轉(zhuǎn)發(fā)Wireshark抓到的包可能來(lái)自不同源MAC如果板子發(fā)送的時(shí)候用錯(cuò)了MAC地址比如MAC沒(méi)有燒錄導(dǎo)致全是FF或者和同網(wǎng)段另一塊板子沖突數(shù)據(jù)就會(huì)發(fā)不出去。鏈路層在嵌入式開(kāi)發(fā)里比想象中重要很多。第三段是**Internet Protocol Version 4IP頭**信息協(xié)議字段值為6表示上層是TCP源IP是192.168.1.100目的IP是192.168.1.50頭部長(zhǎng)度20字節(jié)IHL: 5表示5個(gè)32位字標(biāo)識(shí)字段Identification是針對(duì)原始數(shù)據(jù)包的分片ID這里的數(shù)據(jù)包從未分片。還有一個(gè)很重要的字段是TTLTime To Live每經(jīng)過(guò)一個(gè)路由器減1如果減到0包就會(huì)被丟棄。開(kāi)發(fā)中偶爾會(huì)遇到TTL配置過(guò)小導(dǎo)致多跳網(wǎng)絡(luò)不通的情況大多發(fā)生在復(fù)雜局域網(wǎng)場(chǎng)景中。第四段是**Transmission Control ProtocolTCP頭**信息源端口隨機(jī)分配的一個(gè)高位端口目的端口是7000Sequence Number是數(shù)據(jù)字節(jié)流的序號(hào)Acknowledgment Number是期望對(duì)端下一個(gè)發(fā)的字節(jié)序號(hào)也就是“你的序號(hào)N表示N字節(jié)之前的數(shù)據(jù)全部收到”頭部偏移20字節(jié)表示TCP頭長(zhǎng)度。如果你展開(kāi)TCP頭的Flags字段會(huì)看到Push和Ack置位。Push表示發(fā)送緩沖區(qū)有數(shù)據(jù)要立即交給應(yīng)用層處理Ack表示這是一個(gè)確認(rèn)包。TCP頭部之后就是Wireshark解析出來(lái)的應(yīng)用層數(shù)據(jù)這里是T25.3,H60.1十四個(gè)字符。這一層一層地拆下來(lái)其實(shí)就是TCP/IP模型的解碼過(guò)程鏈路層看MAC幀頭網(wǎng)絡(luò)層看IP頭傳輸層看TCP頭應(yīng)用層看真正的業(yè)務(wù)數(shù)據(jù)。反過(guò)來(lái)你要從板子發(fā)送數(shù)據(jù)的角度整體看這個(gè)過(guò)程就是從應(yīng)用層數(shù)據(jù)開(kāi)始逐層加頭、封裝最后變成一個(gè)以太網(wǎng)幀發(fā)出去。4.3 抓包中常見(jiàn)的異?，F(xiàn)象和排查思路抓包分析的最大價(jià)值不是看正常情況而是看異常情況。分享幾個(gè)我在嵌入式調(diào)試中實(shí)際遇到過(guò)的異?！，F(xiàn)象一只有SYN發(fā)出沒(méi)有回應(yīng)。Wireshark里看到板子發(fā)了SYN包但之后沒(méi)有任何包回過(guò)來(lái)。先查網(wǎng)絡(luò)層Ping板子的IP看通不通。如果不通大概率是IP地址沖突或ARP解析失敗板子沒(méi)有回答ARP請(qǐng)求。如果通再看傳輸層PC上對(duì)應(yīng)的端口有沒(méi)有開(kāi)監(jiān)聽(tīng)有沒(méi)有防火墻規(guī)則攔掉了入站連接通常我會(huì)用netstat在PC上查端口監(jiān)聽(tīng)狀態(tài)?，F(xiàn)象二TCP報(bào)文出現(xiàn)大量Dup ACK和Retransmission。丟包率升高了說(shuō)明鏈路質(zhì)量差。在嵌入式場(chǎng)景下首先查的是硬件問(wèn)題網(wǎng)線接觸不良、PHY芯片配置錯(cuò)誤導(dǎo)致速率和雙工模式不匹配比如一邊是100M全雙工一邊是自動(dòng)協(xié)商成了10M半雙工這就會(huì)出現(xiàn)大量沖突和重傳、PCB板上差分信號(hào)走線過(guò)長(zhǎng)導(dǎo)致信號(hào)完整性差。其次查CPU負(fù)載如果MCU中斷優(yōu)先級(jí)配置不合理網(wǎng)卡驅(qū)動(dòng)的中斷被頻繁搶占協(xié)議棧處理不過(guò)來(lái)也會(huì)導(dǎo)致丟包重傳?，F(xiàn)象三接收緩沖區(qū)被撐爆TCP窗口變成0。Wireshark里能看到Win0的包。這說(shuō)明接收端應(yīng)用層取數(shù)據(jù)的速度太慢接收緩沖區(qū)滿了。嵌入式設(shè)備上最常見(jiàn)的原因是接收線程優(yōu)先級(jí)設(shè)置太低被其他任務(wù)餓死了或者代碼里在recv()回調(diào)中做了耗時(shí)的數(shù)據(jù)處理比如加了文件寫(xiě)入、加了解密操作把接收通路堵死了。這個(gè)現(xiàn)象在TCP/IP模型里對(duì)應(yīng)的是傳輸層的流控機(jī)制在正常工作——它不是在制造故障而是防止數(shù)據(jù)溢出。5. 嵌入式網(wǎng)絡(luò)開(kāi)發(fā)中與模型強(qiáng)相關(guān)的常見(jiàn)坑5.1 板子能Ping通但TCP連不上端口、防火墻和半開(kāi)連接“Ping得通但TCP連不上”是在嵌入式集成調(diào)試中排名前三的怪問(wèn)題。Ping用的是ICMP協(xié)議走的是網(wǎng)絡(luò)層TCP連接建立走的是傳輸層這兩者的故障路徑完全不同所以Ping通不代表一切正常。遇到這個(gè)問(wèn)題時(shí)排查順序應(yīng)該是先確認(rèn)PC或服務(wù)器端的服務(wù)端口有沒(méi)有監(jiān)聽(tīng)。在Linux下用ss -lntp在Windows下用netstat -an | findstr 7000。然后關(guān)掉或者放行對(duì)應(yīng)端口的防火墻規(guī)則。如果這兩步都確認(rèn)了沒(méi)問(wèn)題就要考慮是不是設(shè)備端創(chuàng)建TCP連接失敗——看一下lwIP的tcp_connect()返回值常見(jiàn)的錯(cuò)誤是ERR_MEM內(nèi)存不夠和ERR_VAL參數(shù)錯(cuò)誤。對(duì)于前者要調(diào)大MEMP_NUM_TCP_PCB和MEM_SIZE。還有一個(gè)非常隱蔽的坑是半開(kāi)連接Half-open Connection設(shè)備斷電重啟之前沒(méi)有正常關(guān)閉TCP連接服務(wù)器端保留了半開(kāi)狀態(tài)此時(shí)遠(yuǎn)程服務(wù)器會(huì)認(rèn)為舊連接還存在而設(shè)備端重啟后試圖用新的連接配置不當(dāng)會(huì)在服務(wù)器端出現(xiàn)端口占用或者連接重置。解決方式見(jiàn)仁見(jiàn)智我習(xí)慣在所有TCP客戶端里設(shè)置足夠的重傳超時(shí)參數(shù)并且在設(shè)備喚醒時(shí)主動(dòng)清理掉所有遺留的TCP狀態(tài)然后在應(yīng)用層實(shí)現(xiàn)一個(gè)“心跳重連”的機(jī)制。5.2 黏包與拆包問(wèn)題TCP的字節(jié)流特性TCP是流協(xié)議不是消息協(xié)議這一點(diǎn)在嵌入式里會(huì)引發(fā)非常經(jīng)典的問(wèn)題——黏包和拆包。先看黏包設(shè)備連續(xù)調(diào)用兩次send()發(fā)送兩條消息比如先發(fā)“HELLO”再發(fā)“WORLD”。接收端調(diào)用兩次recv()理論上期望先收到“HELLO”再收到“WORLD”但實(shí)際上兩次recv()中第一次收到的可能是“HELLOWORLD”——因?yàn)門(mén)CP層會(huì)把小塊數(shù)據(jù)累積在一起一次性提交給應(yīng)用層這就是黏包。再看拆包設(shè)備一次send()發(fā)送一個(gè)很大的數(shù)據(jù)塊超過(guò)接收端的接收緩沖區(qū)或MTU接收端需要多次recv()才能收到完整數(shù)據(jù)——每一次recv()收到的是整個(gè)消息的一部分這就是拆包。解決黏包、拆包問(wèn)題的核心是在應(yīng)用層設(shè)計(jì)一種“幀格式”或者說(shuō)“消息協(xié)議”。最簡(jiǎn)單的做法是“長(zhǎng)度前綴法”每條消息由“4字節(jié)消息長(zhǎng)度消息正文”組成。接收端先收4個(gè)字節(jié)解析出消息長(zhǎng)度再收對(duì)應(yīng)長(zhǎng)度的正文數(shù)據(jù)控制好緩沖區(qū)邊界就行復(fù)雜一點(diǎn)的做法是使用特殊的幀分隔符比如AT指令的\r\n結(jié)尾但需要對(duì)正文做轉(zhuǎn)義處理起來(lái)稍繁瑣。從TCP/IP模型的角度看黏包和拆包是TCP的字節(jié)流特性在應(yīng)用層的體現(xiàn)。TCP只保證字節(jié)的可靠有序不保證字節(jié)的邊界。你的應(yīng)用層必須自己處理邊界。做了這么多年代碼我的強(qiáng)烈建議是所有設(shè)備上行的數(shù)據(jù)統(tǒng)一設(shè)計(jì)成固定格式的JSON或者TLVType-Length-Value并且劃分好命令I(lǐng)D和數(shù)據(jù)長(zhǎng)度這樣無(wú)論對(duì)端是PC、是網(wǎng)關(guān)還是云平臺(tái)大家都有統(tǒng)一的解析規(guī)則。5.3 IP分片導(dǎo)致的性能問(wèn)題這個(gè)問(wèn)題在前面第2.3節(jié)提到過(guò)但值得單獨(dú)列出來(lái)再講一遍因?yàn)樗且粋€(gè)隱蔽又影響巨大的優(yōu)化點(diǎn)。嵌入式設(shè)備偶爾需要上報(bào)較大的數(shù)據(jù)塊比如OTA升級(jí)包的分包下發(fā)、設(shè)備日志批量上傳、圖片抓拍上傳。如果你在應(yīng)用層直接把大塊數(shù)據(jù)交給send()底層就會(huì)進(jìn)行IP分片。IP分片在日常網(wǎng)絡(luò)環(huán)境里能工作但性能非常差。原因在于IP分片的重組機(jī)制接收端收到第一個(gè)分片后會(huì)占據(jù)一個(gè)重組緩沖區(qū)等待其他分片到齊。只要有一個(gè)分片丟失整個(gè)原始分組就要全部重傳。Wi-Fi環(huán)境的丟包率本來(lái)就比有線網(wǎng)絡(luò)高分片越多整體丟失概率就越大再加上重傳的數(shù)據(jù)包要全部重新走一遍T(mén)CP如果是TCP的話效率極其低下。解決方案前面提過(guò)應(yīng)用層自己做分包。在TCP場(chǎng)景下把每個(gè)發(fā)送單元控制在基于MSS最大分段大小的一個(gè)安全值以內(nèi)通常是1200字節(jié)比較保守但也最穩(wěn)。在UDP場(chǎng)景下更需要注意因?yàn)閁DP報(bào)文分片后任何一個(gè)分片丟失整個(gè)數(shù)據(jù)報(bào)就廢了而且UDP沒(méi)有重傳機(jī)制。所以要嚴(yán)格把每個(gè)UDP數(shù)據(jù)報(bào)的大小控制在鏈路MTU減去IP頭和UDP頭的范圍內(nèi)。5.4 啟動(dòng)過(guò)程中協(xié)議棧初始化順序問(wèn)題嵌入式網(wǎng)絡(luò)設(shè)備的啟動(dòng)過(guò)程實(shí)際上比看起來(lái)復(fù)雜得多。大部分MCU上電后要完成時(shí)鐘初始化、GPIO配置、MAC外設(shè)初始化、PHY芯片復(fù)位、讀取PHY狀態(tài)、分配MAC地址、協(xié)議棧初始化、創(chuàng)建Socket、綁定端口、開(kāi)始監(jiān)聽(tīng)或連接。如果這個(gè)順序錯(cuò)了就會(huì)出現(xiàn)上電后第一次網(wǎng)絡(luò)連接失敗的詭異問(wèn)題。我遇到過(guò)最典型的例子板子重新上電后需要大約30秒才能ping通但如果板子在啟動(dòng)過(guò)程中同時(shí)被串口中斷反復(fù)打擾偶爾會(huì)永遠(yuǎn)ping不通。抓日志發(fā)現(xiàn)PHY芯片的復(fù)位引腳拉低時(shí)間不夠長(zhǎng)PHY沒(méi)有完成內(nèi)部初始化就開(kāi)始訓(xùn)練鏈路。PHY芯片的自動(dòng)協(xié)商Auto-Negotiation在嵌入式開(kāi)發(fā)里是個(gè)大頭尤其是一些低成本的PHY上電穩(wěn)定時(shí)間很長(zhǎng)。解決方案其實(shí)很簡(jiǎn)單上電后給PHY留足穩(wěn)定時(shí)間不要立即查詢它的狀態(tài)寄存器要輪詢直到狀態(tài)寄存器的鏈路建立標(biāo)志位置1然后才開(kāi)始配置MAC和協(xié)議棧。這一步看著不起眼但對(duì)產(chǎn)品上電一次成功率影響極大。5.5 應(yīng)用層重傳與底層重傳的疊加陷阱最后聊一個(gè)很容易被忽視的系統(tǒng)性問(wèn)題應(yīng)用層重傳和TCP底層重傳疊加后會(huì)導(dǎo)致“數(shù)據(jù)風(fēng)暴”。很多嵌入式工程師為了“可靠”在應(yīng)用層實(shí)現(xiàn)了一套超時(shí)重傳機(jī)制發(fā)送一條指令后如果5秒內(nèi)沒(méi)有收到應(yīng)答就重發(fā)。這個(gè)策略本身沒(méi)有問(wèn)題但如果底層的TCP也在做重傳兩個(gè)機(jī)制就會(huì)疊加。假設(shè)網(wǎng)絡(luò)狀況不好TCP的重傳定時(shí)器設(shè)的是3秒應(yīng)用層的超時(shí)時(shí)間也是5秒那應(yīng)用層就會(huì)在TCP還沒(méi)成功送出數(shù)據(jù)時(shí)啟動(dòng)重傳最終導(dǎo)致同一份數(shù)據(jù)被重復(fù)發(fā)送多次對(duì)端收到一堆重復(fù)的指令處理邏輯如果沒(méi)做去重就會(huì)出現(xiàn)重復(fù)下單、重復(fù)控制等嚴(yán)重問(wèn)題。正確的設(shè)計(jì)是明確分工TCP底層負(fù)責(zé)數(shù)據(jù)到達(dá)對(duì)端的可靠性應(yīng)用層負(fù)責(zé)業(yè)務(wù)級(jí)別的確認(rèn)和邏輯去重。如果業(yè)務(wù)確實(shí)需要應(yīng)用層確認(rèn)比如指令要執(zhí)行完成才算數(shù)那么應(yīng)用層的超時(shí)時(shí)間一定要設(shè)計(jì)得比底層TCP最大重傳時(shí)間大很多不能跟TCP的重傳定時(shí)器在同一數(shù)量級(jí)。這個(gè)“明確分工”的思路其實(shí)也是在使用TCP/IP模型時(shí)最重要的一條心法每一層解決每一層的問(wèn)題不要越層也不要重疊。6. 調(diào)試TCP/IP棧時(shí)的幾個(gè)實(shí)用工具與命令原理講清楚了再說(shuō)一下我平時(shí)調(diào)試嵌入式TCP/IP棧時(shí)幾乎必用的工具和手段它們能讓你在工作時(shí)省掉非常多的冤枉路。第一是串口打印時(shí)間戳。在lwIP里打開(kāi)LWIP_DEBUG配合LWIP_DBG_ON和對(duì)應(yīng)的層調(diào)試開(kāi)關(guān)LWIP_DBG_TCP_ON等可以在串口上看到協(xié)議棧內(nèi)部打印的大量狀態(tài)變化。如果是自己寫(xiě)的協(xié)議棧代碼也建議在關(guān)鍵的收包入口、發(fā)包入口、狀態(tài)遷移處打印帶毫秒級(jí)時(shí)間戳的日志。嵌入式系統(tǒng)沒(méi)有g(shù)db遠(yuǎn)程調(diào)試網(wǎng)絡(luò)協(xié)議棧的便利條件串口頭日志就是最可靠的觀測(cè)手段。第二是Wireshark的過(guò)濾器語(yǔ)法。不要看到一堆包就懵。常用的幾組過(guò)濾表達(dá)式tcp.port 7000只看跟7000端口相關(guān)的TCP流量ip.src 192.168.1.100只看某個(gè)源IP的包tcp.flags.syn 1只看SYN包用來(lái)分析連接建立過(guò)程tcp.analysis.retransmission高亮所有TCP重傳包觀察丟包情況http、mqtt、dns按應(yīng)用層協(xié)議過(guò)濾服務(wù)器調(diào)試時(shí)非常常用這里有個(gè)經(jīng)驗(yàn)是抓包時(shí)要盡量直接抓在嵌入式設(shè)備發(fā)出來(lái)的那個(gè)網(wǎng)段不要隔著路由器抓。隔著路由抓到的包經(jīng)過(guò)了NAT和重新封裝源IP、源端口都可能變化根本認(rèn)不出來(lái)哪個(gè)包是設(shè)備發(fā)的。第三是主動(dòng)注入故障來(lái)驗(yàn)證您的排錯(cuò)思路。比如你想確認(rèn)丟包重傳機(jī)制是否工作正?？梢灾苯釉诮粨Q機(jī)和設(shè)備之間加一個(gè)可編程的損耗模塊模擬5%的丟包率然后觀察設(shè)備端是否發(fā)生TCP重傳、延遲有多高。這種主動(dòng)測(cè)試的好處是等到最終上線時(shí)遇到類(lèi)似問(wèn)題你已經(jīng)知道根因在哪一層了。在開(kāi)發(fā)階段做這種測(cè)試的成本遠(yuǎn)遠(yuǎn)低于在客戶現(xiàn)場(chǎng)調(diào)試的代價(jià)。第四是協(xié)議棧統(tǒng)計(jì)信息的暴露。lwIP提供了stats.h里的全局統(tǒng)計(jì)結(jié)構(gòu)體可以讀出TCP重傳次數(shù)、丟棄包數(shù)量、內(nèi)存分配失敗次數(shù)等等。我用過(guò)不少客戶的固件在出廠時(shí)把這些統(tǒng)計(jì)接口全部裁剪掉了調(diào)試時(shí)無(wú)從下手。我一般是保留統(tǒng)計(jì)功能但只在調(diào)試版開(kāi)啟正式發(fā)布時(shí)再裁剪。這樣出問(wèn)題時(shí)只要客戶能反饋一個(gè)統(tǒng)計(jì)信息往往比看串口日志還管用。7. 針對(duì)嵌入式場(chǎng)景的TCP/IP模型優(yōu)化建議7.1 調(diào)整內(nèi)核參數(shù)適配資源受限環(huán)境嵌入式設(shè)備的內(nèi)存資源極其有限需要對(duì)協(xié)議棧參數(shù)做精細(xì)化調(diào)整。不同協(xié)議棧的宏定義名稱不同但優(yōu)化的維度大致相同。TCP PCB數(shù)量默認(rèn)情況下lwIP只支持MEMB_NUM_TCP_PCB個(gè)并發(fā)TCP控制塊mini版本這個(gè)值只有幾個(gè)。如果你的設(shè)備需要同時(shí)維持多個(gè)連接比如一個(gè)連云端、一個(gè)連配置工具就要相應(yīng)調(diào)大。但每個(gè)PCB會(huì)占掉幾百字節(jié)的RAM在MCU上要精打細(xì)算。發(fā)送和接收緩沖區(qū)大小lwIP里對(duì)應(yīng)的宏是TCP_SND_BUF和TCP_WND。發(fā)送緩沖區(qū)小了大塊數(shù)據(jù)要被拆成很多個(gè)TCP段發(fā)送效率低接收窗口小了對(duì)端的發(fā)送速度會(huì)被流控壓住。但調(diào)大又占內(nèi)存。一般我會(huì)先用Wireshark統(tǒng)計(jì)設(shè)備在正常業(yè)務(wù)下的最大吞吐量把緩沖區(qū)設(shè)置成夠用但留存30%余量的水平。注意TCP_WND如果太小會(huì)讓TCP的吞吐量大打折扣而且遇到高延遲網(wǎng)絡(luò)時(shí)性能會(huì)非常差。這個(gè)窗口大小在嵌入式里是很有講究的不是越大越好要在內(nèi)存和性能之間取一個(gè)平衡點(diǎn)。重傳超時(shí)參數(shù)lwIP的TCP_RTO_MS和TCP_RTO_MAX控制重傳定時(shí)器的最小值和最大值。對(duì)于室內(nèi)局域網(wǎng)環(huán)境默認(rèn)值夠用對(duì)于跨公網(wǎng)通信的設(shè)備建議把RTO的最小值調(diào)大一些避免在擁塞情況下瘋狂重傳浪費(fèi)帶寬。這個(gè)參數(shù)如果不調(diào)設(shè)備在弱網(wǎng)環(huán)境下的表現(xiàn)會(huì)非常糟糕。7.2 零拷貝與內(nèi)存池的取舍嵌入式協(xié)議棧的性能瓶頸經(jīng)常不在CPU而在內(nèi)存拷貝。每次數(shù)據(jù)在應(yīng)用層緩沖區(qū)和內(nèi)核緩沖區(qū)之間拷貝都要消耗CPU周期和總線帶寬。lwIP提供了一種思路通過(guò)PBUF的引用計(jì)數(shù)機(jī)制讓?xiě)?yīng)用層直接對(duì)接協(xié)議棧的緩沖區(qū)減少一次拷貝。這個(gè)機(jī)制在數(shù)據(jù)量大的時(shí)候收益非常明顯。但要注意的是零拷貝意味著緩沖區(qū)所有權(quán)和管理權(quán)要交給協(xié)議棧應(yīng)用層不能隨意釋放。這在使用上容易引入內(nèi)存泄漏。如果你的應(yīng)用場(chǎng)景是高頻小包就只有幾十字節(jié)左右零拷貝的收益不大反而增加代碼復(fù)雜度如果你要傳輸音頻、視頻這種大塊數(shù)據(jù)零拷貝就是必選項(xiàng)。我個(gè)人的原則是600字節(jié)以下的數(shù)據(jù)走普通路徑1KB以上的數(shù)據(jù)考慮零拷貝方案。內(nèi)存池和動(dòng)態(tài)堆的選擇也是一樣。內(nèi)存池管理固定大小內(nèi)存塊分配快、無(wú)碎化、確定性高在中斷回調(diào)函數(shù)里分配PBUF時(shí)幾乎只能選它動(dòng)態(tài)堆靈活但長(zhǎng)時(shí)間運(yùn)行之后可能碎片化。lwIP默認(rèn)是內(nèi)存池動(dòng)態(tài)堆結(jié)合的方案PBUF_POOL用于接收PBUF_RAM用于發(fā)送。一個(gè)經(jīng)驗(yàn)法則是接收側(cè)用池因?yàn)榻邮瞻拇笮∠鄬?duì)可控發(fā)送側(cè)用堆因?yàn)閼?yīng)用數(shù)據(jù)大小多變。這樣配置可以在內(nèi)存碎片和分配效率之間取得平衡。7.3 設(shè)計(jì)低功耗設(shè)備時(shí)的網(wǎng)絡(luò)策略低功耗是嵌入式網(wǎng)絡(luò)設(shè)備繞不開(kāi)的話題而TCP/IP協(xié)議棧恰好是低功耗的大敵。TCP連接需要周期性發(fā)送Keepalive包來(lái)維持連接Wi-Fi模組在接收模式下功耗極高UDP雖然開(kāi)銷(xiāo)小但也需要定期向服務(wù)器發(fā)送心跳才能讓NAT映射不老化。低功耗設(shè)備通常采用非對(duì)稱通信模式設(shè)備大部分時(shí)間在休眠只在需要上報(bào)數(shù)據(jù)時(shí)醒來(lái)快速發(fā)送數(shù)據(jù)然后再次休眠。這種模式下TCP長(zhǎng)連接不適合因?yàn)榫S持一條空閑TCP連接的開(kāi)銷(xiāo)遠(yuǎn)超傳輸幾字節(jié)數(shù)據(jù)的收益。更合理的方案是UDP應(yīng)用層心跳或者M(jìn)QTT/CoAP這類(lèi)針對(duì)受限設(shè)備設(shè)計(jì)的應(yīng)用層協(xié)議它們本身有輕量級(jí)的連接?；顧C(jī)制。再往深一層講低功耗設(shè)備的網(wǎng)絡(luò)策略不應(yīng)只考慮功耗還要考慮“窄帶物聯(lián)網(wǎng)”、“LoRa”這類(lèi)傳輸帶寬極小、半雙工的特點(diǎn)。在這種鏈路上跑TCP基本上是個(gè)反模式因?yàn)門(mén)CP的頭開(kāi)銷(xiāo)大、重傳機(jī)制在極窄帶上會(huì)雪崩。正確的做法是用UDP加上前向糾錯(cuò)或使用CoAP這種基于UDP的應(yīng)用層協(xié)議。理解這一點(diǎn)也就能理解為什么LwIP在很多NB-IoT模組里被裁剪到只剩UDP功能了。8. 編譯運(yùn)行一個(gè)基于lwIP的最小實(shí)例講了這么多理論最后用一段可以直接跑的代碼來(lái)收尾。這是一個(gè)基于lwIP STM32F429 Discovery板子的最小TCP客戶端上電后自動(dòng)獲取IPDHCP連接一個(gè)固定的TCP服務(wù)器每秒發(fā)送一條消息。這段代碼雖然簡(jiǎn)單但囊括了從PHY初始化、MAC注冊(cè)、協(xié)議棧初始化到Socket收發(fā)完整流程。首先要做的準(zhǔn)備工作是把lwIP的源碼我用的是2.1.2版本比較穩(wěn)定放進(jìn)工程并在lwipopts.h里配置好關(guān)鍵宏// lwipopts.h 核心配置 #define NO_SYS 0 // 使用RTOS #define LWIP_SOCKET 1 // 啟用Socket API #define LWIP_NETCONN 1 // 啟用netconn API #define LWIP_DHCP 1 // 啟用DHCP客戶端 #define LWIP_STATS 1 // 啟用統(tǒng)計(jì)信息 #define MEM_SIZE (1600 * 10) // 內(nèi)存堆大小 #define TCP_MSS 1460 #define TCP_WND (4 * TCP_MSS) // 接收窗口 #define TCP_SND_BUF (8 * TCP_MSS) // 發(fā)送緩沖區(qū)主程序里主要的初始化流程大致是這樣精簡(jiǎn)版忽略了一些底層驅(qū)動(dòng)細(xì)節(jié)// main.c 核心流程 #include stm32f4xx.h #include lwip/init.h #include lwip/dhcp.h #include lwip/sockets.h #include netif/etharp.h static struct netif g_netif; static cyw43_t cyw43; // 以CYW43為例實(shí)際根據(jù)網(wǎng)卡更改 static char server_ip[] 192.168.1.50; static int server_port 7000; static struct dhcp *g_dhcp; static void network_init(void) { // 1. MAC驅(qū)動(dòng)和PHY初始化這里省略具體硬件操作 cyw43_init(cyw43); // 2. 向lwIP注冊(cè)網(wǎng)卡接口 netif_add(g_netif, NULL, NULL, NULL, cyw43, low_level_output, // 驅(qū)動(dòng)發(fā)送接口 low_level_init, // 驅(qū)動(dòng)初始化接口 ethernet_input); // 收包入口 netif_set_default(g_netif); netif_set_up(g_netif); // 3. 啟動(dòng)DHCP獲取IP地址 g_dhcp dhcp_start(g_netif); while (g_dhcp-state ! DHCP_STATE_BOUND) { sys_check_timeouts(); // 處理協(xié)議棧定時(shí)器 HAL_Delay(10); } } static void tcp_client_task(void *arg) { int sock -1; char buf[64]; for (;;) { if (sock 0) { // 1. 創(chuàng)建Socket sock socket(AF_INET, SOCK_STREAM, 0); if (sock 0) { vTaskDelay(pdMS_TO_TICKS(1000)); continue; } // 2. 連接服務(wù)器 struct sockaddr_in saddr; saddr.sin_family AF_INET; saddr.sin_port htons(server_port); saddr.sin_addr.s_addr inet_addr(server_ip); if (connect(sock, (struct sockaddr *)saddr, sizeof(saddr)) ! 0) { close(sock); sock -1; vTaskDelay(pdMS_TO_TICKS(5000)); continue; } } // 3. 模擬采集溫濕度并上報(bào) float temp 25.0 (rand() % 10) / 10.0; float hum 60.0 (rand() % 10) / 10.0; int len snprintf(buf, sizeof(buf), T%.1f,H%.1f\r\n, temp, hum); int ret send(sock, buf, len, 0); if (ret 0) { close(sock); sock -1; } vTaskDelay(pdMS_TO_TICKS(1000)); // 1秒發(fā)送一次 } }這里有個(gè)非常重要的細(xì)節(jié)TCP客戶端的重連邏輯。這段代碼中如果connect()失敗、send()返回值異常就關(guān)閉Socket并重新創(chuàng)建。如果不寫(xiě)這段邏輯設(shè)備在服務(wù)器重啟或網(wǎng)絡(luò)斷開(kāi)的場(chǎng)景下會(huì)永遠(yuǎn)卡在舊連接上。這是嵌入式TCP客戶端最基本也最核心的可靠性設(shè)計(jì)之一。此外lwIP是一個(gè)非阻塞的事件驅(qū)動(dòng)協(xié)議棧它必須通過(guò)sys_check_timeouts()周期性地處理重傳定時(shí)器、ARP老化等內(nèi)部事件。在裸機(jī)環(huán)境下你要在主循環(huán)里調(diào)用它在上面的RTOS環(huán)境下也要有某個(gè)任務(wù)負(fù)責(zé)周期性調(diào)用它。初學(xué)者最容易犯的錯(cuò)就是忘了調(diào)這個(gè)函數(shù)導(dǎo)致TCP連接永遠(yuǎn)建立不起來(lái)、ARP表永遠(yuǎn)不刷新。編譯燒錄之后在PC上用nc -l 7000監(jiān)聽(tīng)端口板子上電啟動(dòng)后你應(yīng)該能在終端看到每秒一行Txx.x,Hxx.x的輸出。如果看到這個(gè)輸出恭喜你的板子已經(jīng)能通過(guò)完整的TCP/IP模型鏈路收發(fā)數(shù)據(jù)了。這時(shí)候再回頭看我前兩章講的那些概念你會(huì)有一個(gè)完全不同的感受——它們不再是紙面上的圖而是實(shí)實(shí)在在地在你的板子和PC之間流動(dòng)著。