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