議棧：從分層原理到Socket編程與嵌入式實戰(zhàn))
1. 先搞明白TCP/IP協(xié)議棧到底是個什么東西很多人一聽到“TCP/IP協(xié)議?！边@七個字就開始頭皮發(fā)麻腦子里全是大學(xué)《計算機(jī)網(wǎng)絡(luò)》教材上那些密密麻麻的分層圖解、三次握手四次揮手、各種報文字段說明。說實話當(dāng)年我也一樣對著課本背了好幾遍考完試全忘了直到后來自己上手抓包、寫Socket程序、做嵌入式網(wǎng)絡(luò)網(wǎng)關(guān)才真正把這一套東西的內(nèi)核給吃透了。先給沒基礎(chǔ)的朋友一句話交代清楚TCP/IP協(xié)議棧本質(zhì)上就是一套“互聯(lián)網(wǎng)世界的快遞系統(tǒng)”的規(guī)則總和。你發(fā)一條微信、打開一個網(wǎng)頁、推送一幀設(shè)備數(shù)據(jù)背后都是數(shù)據(jù)包在網(wǎng)絡(luò)上跑。而數(shù)據(jù)包怎么打包、怎么寫地址、怎么運(yùn)輸、怎么確認(rèn)對方收到了這套完整規(guī)則就是TCP/IP協(xié)議棧。它不是一個協(xié)議而是一組協(xié)議按照分工、分層組織起來的集合“棧”這個字說的就是它們一層摞一層、各管一段的工作方式。這玩意兒能解決的問題往大說是全互聯(lián)網(wǎng)設(shè)備互聯(lián)互通的問題往小說是你手頭一個單片機(jī)的數(shù)據(jù)怎么發(fā)給云端服務(wù)器的問題。不管你是做后端開發(fā)、嵌入式開發(fā)、網(wǎng)絡(luò)運(yùn)維還是單純想搞明白“打開網(wǎng)頁的瞬間到底發(fā)生了什么”TCP/IP協(xié)議棧都是繞不開的那條主線。這篇內(nèi)容我會講清楚它的設(shè)計思路、各層職責(zé)、數(shù)據(jù)流動的完整路徑再配合實際抓包和代碼示例深入拆解最后聊聊我踩過的那些坑。2. 協(xié)議棧為什么非要分層這套設(shè)計到底精妙在哪2.1 沒有分層之前通信是什么鬼樣子要理解TCP/IP協(xié)議棧的價值最好先看一眼沒有分層的時候通信是什么狀態(tài)。早期的網(wǎng)絡(luò)通信基本是兩家廠商各自定義一套自己的規(guī)則物理接口怎么定義、數(shù)據(jù)怎么編碼、怎么尋址、怎么檢測錯誤全都揉在一起。結(jié)果是A廠商的設(shè)備只能跟A廠商的設(shè)備通信想接入B廠商的系統(tǒng)對不起不兼容。這就好比你想寄快遞結(jié)果每個快遞公司都有自己的箱子尺寸、填單格式、運(yùn)輸路線你寄順豐的包裹圓通不認(rèn)圓通寫好的單子申通看不懂——整個物流系統(tǒng)完全亂套。而分層做的事情就是把快遞整個流程拆成幾個獨(dú)立環(huán)節(jié)你只管把東西交給前臺、前臺負(fù)責(zé)打包貼單、運(yùn)輸隊負(fù)責(zé)把包裹送到另一個城市、派送員負(fù)責(zé)送到收件人手上。每一層只需要跟自己上面和下面的環(huán)節(jié)打交道不需要管其他環(huán)節(jié)怎么實現(xiàn)。2.2 四層模型每一層到底管什么標(biāo)準(zhǔn)的TCP/IP模型分四層從上到下分別是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、網(wǎng)絡(luò)接口層。注意很多教材里會把網(wǎng)絡(luò)接口層再拆成數(shù)據(jù)鏈路層和物理層對應(yīng)OSI七層模型的說法但在實戰(zhàn)中我們基本都是按四層來理解和排查問題的。我用快遞類比把這四層說清楚應(yīng)用層就是你寄快遞時填寫的那張寄件單上面寫著“我要寄什么內(nèi)容”。對應(yīng)到技術(shù)上HTTP、HTTPS、FTP、DNS、MQTT這些協(xié)議都住在這一層它們定義了數(shù)據(jù)的具體格式和業(yè)務(wù)語義。你在瀏覽器里輸入的網(wǎng)址、App里刷的信息流最終都是靠應(yīng)用層協(xié)議來表達(dá)的。傳輸層相當(dāng)于快遞公司的客服中心負(fù)責(zé)確認(rèn)“這個包裹到底該不該寄、寄了有沒有丟”。它給數(shù)據(jù)加上端口號標(biāo)識出這份數(shù)據(jù)是給哪個應(yīng)用程序的同時負(fù)責(zé)分片、重組、流量控制。TCP和UDP就是這一層的大佬。網(wǎng)絡(luò)層相當(dāng)于快遞的干線運(yùn)輸網(wǎng)絡(luò)負(fù)責(zé)規(guī)劃路徑、決定包裹從哪個城市經(jīng)轉(zhuǎn)、最終到達(dá)哪個城市。IP協(xié)議是這一層的核心它給每臺設(shè)備編一個邏輯地址IP地址然后通過路由協(xié)議找到一條能到達(dá)目的地址的路。網(wǎng)絡(luò)接口層相當(dāng)于快遞的末端運(yùn)輸負(fù)責(zé)把包裹在具體的物理線路比如網(wǎng)線、光纖、Wi-Fi無線電波上傳出去還負(fù)責(zé)把IP地址翻譯成硬件地址MAC地址。這四層之間的關(guān)系關(guān)鍵在于每一層只依賴下一層提供的服務(wù)不需要關(guān)心下一層具體怎么實現(xiàn)。傳輸層不需要知道數(shù)據(jù)到底走的是光纖還是Wi-Fi網(wǎng)絡(luò)層不需要知道上層是HTTP還是MQTT。這種“高內(nèi)聚、低耦合”的設(shè)計是整個互聯(lián)網(wǎng)能夠以極低代價接入新協(xié)議、新硬件的前提。2.3 分層帶來的實際好處不是理論空談分層的優(yōu)點做工程的人體會最深。我舉三個實際場景第一個是故障排查。網(wǎng)絡(luò)出了問題工程師有一個默認(rèn)的排查順序先看物理層通不通網(wǎng)線插好沒、再看鏈路層MAC地址、ARP、然后看網(wǎng)絡(luò)層IP通不通、路由對不對、再看傳輸層端口通不通、TCP連接建沒建立、最后才看應(yīng)用層HTTP狀態(tài)碼。每一層都有獨(dú)立的排查工具和手段你不需要一上來就把整個協(xié)議棧的每個字節(jié)都翻一遍。分層最大的工程意義就是把“網(wǎng)絡(luò)壞了”這個大問題拆成了多個可以獨(dú)立定位的小問題。第二個是技術(shù)演進(jìn)。今天你的網(wǎng)絡(luò)接入從百兆以太網(wǎng)換成了Wi-Fi 6甚至換成了5G蜂窩網(wǎng)絡(luò)需要替換的只有最底下那層——網(wǎng)絡(luò)接口層。上面的TCP/IP協(xié)議棧根本不用改。反過來你想從HTTP升級到HTTP/3也只動了最上面應(yīng)用層底下的TCP/IP該怎么跑還是怎么跑。這種“局部替換、全局不動”的能力是互聯(lián)網(wǎng)技術(shù)能夠快速迭代的重要基礎(chǔ)。第三個是安全隔離。每一層都可以獨(dú)立做安全檢查網(wǎng)絡(luò)層可以做IP白名單傳輸層可以做端口管控應(yīng)用層可以做內(nèi)容過濾。層次清晰安全策略就能在不同環(huán)節(jié)獨(dú)立部署而不會胡亂糾纏在一起。3. 核心機(jī)制深度拆解IP、TCP、UDP到底在干什么3.1 網(wǎng)絡(luò)層核心IP協(xié)議如何完成尋址和路由IP協(xié)議是這個協(xié)議棧里真正承擔(dān)“互聯(lián)網(wǎng)尋址”功能的角色。每一臺接入網(wǎng)絡(luò)的設(shè)備都會有一個IP地址就像你家門牌號。數(shù)據(jù)包要到達(dá)目的地網(wǎng)絡(luò)層的路由器就負(fù)責(zé)根據(jù)目的IP地址一跳一跳地把數(shù)據(jù)轉(zhuǎn)發(fā)過去。IP協(xié)議有兩個版本IPv4和IPv6。我們平時最常見的IPv4地址是32位的比如192.168.1.100這種格式理論上能提供的地址總數(shù)是2的32次方大約43億個。聽著多但放到全球幾十億設(shè)備上網(wǎng)的今天早就捉襟見肘了。這也是IPv6要把地址擴(kuò)展到128位的原因——數(shù)量多到幾乎可以給地球上每一粒沙子都分配一個IP。但I(xiàn)P協(xié)議本身只負(fù)責(zé)“盡力而為”地投遞它不保證數(shù)據(jù)包一定能到達(dá)目的地。它做了三件事給數(shù)據(jù)包加上源IP地址和目的IP地址、根據(jù)路由表決定下一跳走向、如果數(shù)據(jù)包太大就進(jìn)行分片。至于到了沒有、順序?qū)Σ粚Α⒂袥]有丟包IP協(xié)議一概不管。所以大家常說IP協(xié)議是“不可靠的”。那“不可靠”是不是意味著IP協(xié)議很弱恰恰相反這種設(shè)計是故意的。網(wǎng)絡(luò)環(huán)境千差萬別如果在IP這一層就要保證可靠那所有中間設(shè)備都必須維護(hù)海量的狀態(tài)信息代價高到難以想象。不如讓IP層做到最簡把可靠性的問題甩給上層去解決——這就引出了TCP存在的意義。3.2 傳輸層核心TCP怎么把“不可靠”變成“可靠”TCP做的事情通俗點講就是在IP“盡力而為”的基礎(chǔ)上增加了三重保險確認(rèn)機(jī)制、重傳機(jī)制、順序控制。先說確認(rèn)機(jī)制。發(fā)送方每發(fā)出一個數(shù)據(jù)包接收方收到之后要給發(fā)送方回一個ACK確認(rèn)應(yīng)答相當(dāng)于快遞簽收回執(zhí)。發(fā)送方如果一段時間內(nèi)沒收到某個包的ACK就認(rèn)為這個包丟了于是重傳一次。這個“超時重傳”機(jī)制是TCP可靠性的基石。再說順序控制。IP層轉(zhuǎn)發(fā)數(shù)據(jù)的時候每個數(shù)據(jù)包走的路由可能不一樣先發(fā)的包未必先到。TCP在每個數(shù)據(jù)包上打上序號接收方根據(jù)序號重新排序保證交給應(yīng)用層的數(shù)據(jù)是完整有序的。這也是為什么下載大文件時即使網(wǎng)絡(luò)有抖動最終拼出來的文件還是分毫不差。還有一個大家面試經(jīng)常被問到的“三次握手”。建立連接時客戶端先發(fā)一個SYN包服務(wù)端回一個SYNACK包客戶端再回一個ACK包。為啥要三次握手簡單的回答是需要雙方都確認(rèn)“我發(fā)的你能收到你發(fā)的我也能收到”。第一次握手讓服務(wù)端確認(rèn)客戶端能發(fā)第二次握手讓客戶端確認(rèn)服務(wù)端能收也能發(fā)第三次握手讓服務(wù)端確認(rèn)客戶端能收。只握兩次的話服務(wù)端沒法確認(rèn)客戶端是否收到了自己的回應(yīng)連接狀態(tài)可能不一致。TCP還有一套復(fù)雜的流量控制和擁塞控制機(jī)制涉及滑動窗口、慢啟動、擁塞避免、快重傳這些概念。篇幅有限不全部展開但大家記住一個核心TCP本質(zhì)上是在用“犧牲一點傳輸效率”來換取“數(shù)據(jù)的可靠交付”它適合對數(shù)據(jù)完整性要求高的場景——比如網(wǎng)頁瀏覽、文件傳輸、郵件收發(fā)。3.3 傳輸層另一面UDP為什么延遲低、開銷小有TCP在前面撐著可靠性為什么還需要UDP因為不是所有場景都“非可靠不可”。UDP做的事情極其簡單把數(shù)據(jù)包從一端丟到另一端不加序號、不確認(rèn)、不重傳。它只比IP多了一個端口號的概念讓數(shù)據(jù)能送到指定的應(yīng)用程序。UDP的好處很明顯頭部開銷小固定8字節(jié)TCP頭部最少20字節(jié)、沒有連接建立的延遲、沒有確認(rèn)和重傳機(jī)制帶來的等待。這就是為什么實時音視頻通話、在線游戲、DNS查詢這些“低延遲優(yōu)先、偶爾掉一兩幀沒關(guān)系”的場景都首選UDP。比如視頻通話的時候如果中間網(wǎng)絡(luò)抖動丟了一幀畫面TCP會怎么做它會重傳這一幀結(jié)果視頻畫面等了一輪重傳才補(bǔ)上來整體反而更卡。UDP的做法是丟了就丟了下一幀馬上接著來用戶感知上反而是流暢的?！翱煽俊辈⒉挥肋h(yuǎn)是“最優(yōu)”很多時候“及時”比“完整”更重要。3.4 應(yīng)用層常見協(xié)議從HTTP到MQTT應(yīng)用層的協(xié)議是普通開發(fā)者接觸最多的一層其中HTTP/HTTPS是絕對的主角。HTTP規(guī)定了客戶端比如瀏覽器和服務(wù)端比如Web服務(wù)器之間請求-響應(yīng)的交互格式請求行、請求頭、請求體響應(yīng)行、響應(yīng)頭、響應(yīng)體。HTTPS則是在HTTP和TCP之間加了一層TLS加密讓明文數(shù)據(jù)變成密文傳輸。在實際工程項目里除了HTTP還有幾個高頻出現(xiàn)的應(yīng)用層協(xié)議值得留意DNS負(fù)責(zé)把域名比如www.example.com解析成IP地址這是打開網(wǎng)頁的第一步。MQTT專為物聯(lián)網(wǎng)設(shè)備設(shè)計的輕量級消息協(xié)議基于TCP發(fā)布/訂閱模式很適合嵌入式設(shè)備上報數(shù)據(jù)。CoAP基于UDP的物聯(lián)網(wǎng)協(xié)議比MQTT更輕面向資源受限的設(shè)備。FTP/SFTP文件傳輸專用。很多人在做項目的時候糾結(jié)“該用HTTP還是MQTT”我的判斷標(biāo)準(zhǔn)很簡單如果設(shè)備需要頻繁雙向通信、需要服務(wù)端主動推送消息MQTT更合適如果只是周期性上報數(shù)據(jù)或者需要跟Web系統(tǒng)打通HTTP更簡單直接。這個后面實操章節(jié)我還會再談。4. 從一個數(shù)據(jù)包看完整旅程抓包實測與封裝拆裝4.1 數(shù)據(jù)包的封裝從HTTP請求到鏈路層幀理論講得再多不如看一次真實的數(shù)據(jù)包流動。我來模擬一個最簡單的場景你在瀏覽器里訪問一個網(wǎng)站看看一次HTTP請求是怎么從上到下被“加工”成可以在網(wǎng)線上傳輸?shù)男盘?。第一步?yīng)用層。瀏覽器構(gòu)造一個HTTP請求報文里面包含請求行GET /index.html HTTP/1.1、請求頭Host、User-Agent之類的字段、可能還有請求體。第二步傳輸層。TCP協(xié)議把這個HTTP報文當(dāng)作自己的“數(shù)據(jù)載荷”在前面加上一個TCP頭部。TCP頭部里最關(guān)鍵的字段是源端口比如瀏覽器隨機(jī)分配一個如54321和目的端口HTTP默認(rèn)80HTTPS默認(rèn)443以及剛才提到的序號和確認(rèn)號。這時候數(shù)據(jù)塊被叫做“TCP段”Segment。第三步網(wǎng)絡(luò)層。IP協(xié)議把整個TCP段當(dāng)作載荷加上一個IP頭部。IP頭部的關(guān)鍵字段包括源IP地址你本機(jī)的地址和目的IP地址服務(wù)器地址還有總長度、協(xié)議號6代表TCP17代表UDP。這時候數(shù)據(jù)塊叫做“IP數(shù)據(jù)報”Packet。第四步網(wǎng)絡(luò)接口層。數(shù)據(jù)鏈路層再把整個IP數(shù)據(jù)報當(dāng)作載荷加上以太網(wǎng)幀頭——幀頭里包含源MAC地址和目的MAC地址。那目的MAC地址怎么確定如果目的IP跟自己不在同一網(wǎng)段數(shù)據(jù)包要先發(fā)給網(wǎng)關(guān)通常是路由器所以這里的“目的MAC地址”實際上是網(wǎng)關(guān)的MAC地址由ARP協(xié)議負(fù)責(zé)查詢。這一層生成的是“以太網(wǎng)幀”Frame。到了接收端整個流程反過來網(wǎng)卡收到以太網(wǎng)幀剝掉幀頭發(fā)現(xiàn)里面是個IP數(shù)據(jù)報IP層剝掉IP頭發(fā)現(xiàn)里面是個TCP段TCP層剝掉TCP頭確認(rèn)是給自己的數(shù)據(jù)再把HTTP報文交給瀏覽器解析。每一層只處理自己關(guān)心的頭部信息然后把剩下的載荷原封不動地往上交。這就是所謂的“分層解封裝”。4.2 用Wireshark看一次真實的HTTP請求理論描述終究不如現(xiàn)場抓包我推薦大家安裝一個Wireshark自己動手做一次抓包實驗。操作很簡單打開Wireshark選擇正在使用的網(wǎng)卡設(shè)置過濾條件http然后隨便訪問一個HTTP網(wǎng)站注意要訪問HTTP的因為HTTPS的載荷是加密的你只能看到TLS握手看不到明文HTTP內(nèi)容。如果你找不到HTTP網(wǎng)站可以本地起一個簡單的Python HTTP服務(wù)在某個目錄下執(zhí)行python3 -m http.server 8000然后用瀏覽器訪問http://localhost:8000。你會看到Wireshark里捕獲到一串?dāng)?shù)據(jù)包。點開其中一個帶HTTP GET標(biāo)識的包能看到完整的四層信息Frame層顯示物理層信息包括幀長度等。Ethernet II層顯示源MAC、目的MAC、上層協(xié)議類型0x0800表示上層是IPv4。Internet Protocol Version 4層顯示源IP、目的IP、協(xié)議號6TCP、TTL、校驗和等。Transmission Control Protocol層顯示源端口、目的端口、Seq序號、Ack確認(rèn)號、Window窗口大小等。Hypertext Transfer Protocol層顯示實際的HTTP請求行和請求頭。建議各位看的時候有個心理準(zhǔn)備一個看起來簡簡單單的網(wǎng)頁請求在Wireshark里往往對應(yīng)幾十上百個數(shù)據(jù)包。因為除了頁面本身的HTML瀏覽器還會并行發(fā)起CSS、JS、圖片等資源的請求而且每個TCP請求之前都先有三次握手之后可能還有四次揮手。這種“肉眼可見的復(fù)雜”就是真實互聯(lián)網(wǎng)的日常。4.3 為什么說抓包是學(xué)習(xí)協(xié)議棧最快的方式很多人學(xué)TCP/IP最容易犯的毛病是只看書不抓包。書上的報文格式畫得再清楚都是靜態(tài)的文字你真正在抓包工具里看到一個一個字段躺在那里、跟著一次請求從頭到尾走一遍才真正理解“誰在什么時候加什么頭、每個字段到底干什么用”。我建議一個遞進(jìn)式的學(xué)習(xí)路線先開著Wireshark逛幾個網(wǎng)頁不設(shè)置過濾只看數(shù)據(jù)包數(shù)量的暴增感受一下握手的全過程。設(shè)過濾條件tcp觀察一條TCP連接從SYN、SYNACK、ACK到后面?zhèn)鬏敂?shù)據(jù)、最后FIN結(jié)束的完整生命周期。設(shè)過濾條件dns看看瀏覽器訪問網(wǎng)站之前DNS查詢是怎么用UDP包往返的。設(shè)過濾條件http配合瀏覽器訪問一次HTTP站點把請求-響應(yīng)對應(yīng)起來看。最后嘗試自己寫一個TCP服務(wù)器和客戶端用抓包軟件觀察自己代碼發(fā)出的數(shù)據(jù)包長什么樣。走到第五步你對協(xié)議棧的理解基本就站在一個非常扎實的水平了。5. Socket編程實操用C語言手寫一個TCP通信5.1 什么是Socket它不是協(xié)議是接口很多做嵌入式或者剛?cè)腴T服務(wù)端開發(fā)的同學(xué)總把Socket和TCP/IP混為一談。我不止一次被人問“TCP和Socket有什么區(qū)別”——這個問題要回答清楚得先說結(jié)論Socket不是協(xié)議它是操作系統(tǒng)提供給我們調(diào)用TCP/IP協(xié)議棧的編程接口。TCP/IP協(xié)議棧雖然內(nèi)置于操作系統(tǒng)內(nèi)核里但你不能直接拿根針戳進(jìn)內(nèi)核去操作它。內(nèi)核對外開了一組系統(tǒng)調(diào)用讓你可以創(chuàng)建連接、發(fā)送數(shù)據(jù)、接收數(shù)據(jù)、關(guān)閉連接這一組接口就是Socket API?？梢园阉斫鉃椴蛷d的菜單后廚有一套復(fù)雜的做菜流程協(xié)議棧你不需要進(jìn)后廚你只需要按菜單點菜調(diào)用Socket API菜就能端到你面前。5.2 完整實現(xiàn)TCP服務(wù)端和客戶端我直接給出一份最精簡但五臟俱全的C語言TCP通信代碼包含了服務(wù)端和客戶端。這段代碼沒有做詳細(xì)的錯誤處理但完整的骨架都在適合對照著學(xué)習(xí)。服務(wù)端代碼#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h int main() { int server_fd, client_fd; struct sockaddr_in server_addr, client_addr; socklen_t addr_len sizeof(client_addr); char buffer[1024] {0}; char *response Hello from TCP Server; // 1. 創(chuàng)建socketAF_INET表示IPv4SOCK_STREAM表示TCP server_fd socket(AF_INET, SOCK_STREAM, 0); if (server_fd 0) { perror(socket); exit(EXIT_FAILURE); } // 2. 綁定端口和地址 server_addr.sin_family AF_INET; server_addr.sin_addr.s_addr INADDR_ANY; // 綁定所有網(wǎng)卡 server_addr.sin_port htons(8080); // 端口號轉(zhuǎn)網(wǎng)絡(luò)字節(jié)序 if (bind(server_fd, (struct sockaddr *)server_addr, sizeof(server_addr)) 0) { perror(bind); close(server_fd); exit(EXIT_FAILURE); } // 3. 監(jiān)聽最大等待隊列長度設(shè)為3 if (listen(server_fd, 3) 0) { perror(listen); close(server_fd); exit(EXIT_FAILURE); } printf(Server listening on port 8080...\n); // 4. 接受客戶端連接阻塞等待 client_fd accept(server_fd, (struct sockaddr *)client_addr, addr_len); if (client_fd 0) { perror(accept); close(server_fd); exit(EXIT_FAILURE); } printf(Client connected: %s\n, inet_ntoa(client_addr.sin_addr)); // 5. 接收數(shù)據(jù)并響應(yīng) int bytes_read read(client_fd, buffer, sizeof(buffer)); printf(Received: %s\n, buffer); send(client_fd, response, strlen(response), 0); // 6. 關(guān)閉連接 close(client_fd); close(server_fd); return 0; }客戶端代碼#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h int main() { int sock_fd; struct sockaddr_in server_addr; char buffer[1024] {0}; char *message Hello from TCP Client; // 1. 創(chuàng)建socket sock_fd socket(AF_INET, SOCK_STREAM, 0); if (sock_fd 0) { perror(socket); exit(EXIT_FAILURE); } // 2. 設(shè)置服務(wù)器地址 server_addr.sin_family AF_INET; server_addr.sin_addr.s_addr inet_addr(127.0.0.1); // 本機(jī)回環(huán)地址 server_addr.sin_port htons(8080); // 3. 連接服務(wù)器 if (connect(sock_fd, (struct sockaddr *)server_addr, sizeof(server_addr)) 0) { perror(connect); close(sock_fd); exit(EXIT_FAILURE); } printf(Connected to server.\n); // 4. 發(fā)送數(shù)據(jù) send(sock_fd, message, strlen(message), 0); // 5. 接收響應(yīng) int bytes_read read(sock_fd, buffer, sizeof(buffer)); printf(Server response: %s\n, buffer); // 6. 關(guān)閉連接 close(sock_fd); return 0; }編譯方式gcc tcp_server.c -o tcp_server gcc tcp_client.c -o tcp_client先在一個終端運(yùn)行./tcp_server再開另一個終端運(yùn)行./tcp_client就能看到數(shù)據(jù)通暢地在兩端之間流動。5.3 幾個關(guān)鍵細(xì)節(jié)搞清楚才算真會了上面代碼看著簡單但里面有幾個關(guān)鍵細(xì)節(jié)值得展開說說。第一個是htons()函數(shù)。這里用到了“網(wǎng)絡(luò)字節(jié)序”的概念。不同的CPU在內(nèi)存里存放多字節(jié)整數(shù)的方式不一樣有的用大端、有的用小端。為了保證所有設(shè)備之間數(shù)據(jù)能正確解析網(wǎng)絡(luò)傳輸統(tǒng)一使用大端字節(jié)序也叫網(wǎng)絡(luò)字節(jié)序。我們的端口號8080在本地內(nèi)存里可能是小端存儲的直接放到報文里發(fā)出去對端解析必然出錯。所以發(fā)送前必須用htons()把主機(jī)字節(jié)序轉(zhuǎn)換成網(wǎng)絡(luò)字節(jié)序接收端再通過ntohs()轉(zhuǎn)回來。別小看這個細(xì)節(jié)很多新手第一次寫網(wǎng)絡(luò)程序報錯半天找不到原因最后發(fā)現(xiàn)是字節(jié)序沒轉(zhuǎn)。第二個是accept()返回的新socket。注意服務(wù)端有兩個文件描述符一個是server_fd負(fù)責(zé)監(jiān)聽新連接另一個是client_fd負(fù)責(zé)跟已經(jīng)連接的客戶端通信。監(jiān)聽的socket只負(fù)責(zé)“接客”真正“聊天”的是accept返回的新socket。一個監(jiān)聽socket可以accept出多個連接socket這是并發(fā)服務(wù)器的底層基礎(chǔ)。第三個是客戶端connect()建立的連接。connect的過程在底層就是發(fā)送SYN、接收SYNACK、發(fā)送ACK的三次握手。你調(diào)用connect時如果網(wǎng)絡(luò)不通或者服務(wù)器沒監(jiān)聽對應(yīng)端口connect會阻塞一段時間然后報錯。這段阻塞期間底層TCP重傳機(jī)制一直在努力很多莫名其妙網(wǎng)絡(luò)“卡頓”的感知其實都是TCP在默默重試。5.4 從C代碼到真實的工程項目差距在哪上面的代碼只是個模型。真實的服務(wù)器程序不可能只處理一個客戶端連接——它需要持續(xù)監(jiān)聽、同時服務(wù)大量連接。這意味著你需要用到多線程、IO多路復(fù)用select/poll/epoll、事件驅(qū)動模型這些更進(jìn)階的技術(shù)。但這并不意味著這份入門代碼沒有價值。它最大的價值是讓你看到TCP操作的完整流程理解每個步驟在協(xié)議棧里對應(yīng)什么動作。先跑通它再去學(xué)epoll、學(xué)Reactor模型你的理解曲線會平滑得多。6. 嵌入式場景實戰(zhàn)STM32 lwIP協(xié)議棧移植要點6.1 為什么嵌入式設(shè)備需要lwIP前面聊的主要是PC和服務(wù)器的場景。這幾年我做嵌入式項目比較多發(fā)現(xiàn)越來越多的設(shè)備要求聯(lián)網(wǎng)傳感器數(shù)據(jù)要上云、設(shè)備要遠(yuǎn)程控制、固件要在線升級。這些場景里跑在STM32這類MCU上的TCP/IP協(xié)議棧最常用的就是lwIP。lwIP的全稱是Lightweight IP是一個開源的精簡TCP/IP協(xié)議棧專門為資源受限的嵌入式系統(tǒng)設(shè)計。跟PC上的協(xié)議棧相比lwIP最核心的設(shè)計目標(biāo)就是在極小的內(nèi)存占用下盡可能提供完整的TCP/IP功能。它支持TCP、UDP、ICMP、DHCP、自動網(wǎng)卡配置等常用功能還提供了一個精簡的Socket API雖然跟標(biāo)準(zhǔn)Socket API不完全兼容但概念一致。為什么很多項目選lwIP而不是直接在MCU上跑標(biāo)準(zhǔn)協(xié)議棧原因很直接標(biāo)準(zhǔn)協(xié)議棧對內(nèi)存的功耗要求太高。一個完整的TCP連接需要維護(hù)發(fā)送緩沖區(qū)、接收緩沖區(qū)、滑動窗口狀態(tài)等光靠MCU上那幾十到幾百KB級別的內(nèi)存根本吃不消。lwIP通過減少緩存區(qū)大小、簡化協(xié)議狀態(tài)、允許用戶自行配置內(nèi)存池等策略把內(nèi)存占用壓到極低水平。6.2 STM32移植lwIP的核心步驟用CubeMX做STM32的lwIP移植是目前最主流的方式流程可以概括為以下幾步第一步在CubeMX里配置好以太網(wǎng)外設(shè)。選擇目標(biāo)MCU型號打開ETH外設(shè)配置RMII接口模式、PHY芯片地址、時鐘等。如果板子上接了LAN8720之類的PHY芯片注意把PHY Address設(shè)置好比如LAN8720默認(rèn)地址是0。第二步在Middleware里勾選LwIP。此時需要設(shè)置協(xié)議棧的關(guān)鍵參數(shù)內(nèi)存堆大小MEM_SIZE、內(nèi)存池數(shù)量MEMP_NUMBER、最大TCP連接數(shù)MEMP_NUM_TCP_SEG、TCP接收窗口大小TCP_WND等。這些參數(shù)直接決定協(xié)議棧能支持多少并發(fā)連接、緩沖區(qū)多大、內(nèi)存占用多高需要根據(jù)MCU的RAM容量來調(diào)整。第三步配置網(wǎng)卡驅(qū)動和PHY驅(qū)動。CubeMX生成的模板內(nèi)置了常見PHY芯片的驅(qū)動支持但有些板子的PHY型號需要自己適配。第四步修改LAN8720相關(guān)的底層函數(shù)。這塊往往是最容易出錯的地方因為不同PHY芯片的寄存器操作方式差異很大。需要確認(rèn)PHY地址、復(fù)位引腳、中斷引腳在代碼里的配置是否正確。第五步在主循環(huán)里調(diào)用MX_LWIP_Process()這個函數(shù)負(fù)責(zé)讓協(xié)議棧周期性地處理定時器事件、ARP緩存過期、TCP重傳等問題。如果你沒用RTOS這個函數(shù)必須高頻調(diào)用比如每1-2ms一次否則TCP連接建立不起來、或者連接保持不住。6.3 我踩過的嵌入式網(wǎng)絡(luò)坑嵌入式TCP/IP開發(fā)跟PC端開發(fā)最大的區(qū)別是沒有現(xiàn)成的調(diào)試工具鏈所有問題都得靠日志和示波器一點一點摳。我在這里列幾個我實際遇到過的坑都是血淚教訓(xùn)。第一個坑是PHY地址配錯導(dǎo)致Link Up不了。這個現(xiàn)象最常見eth網(wǎng)卡初始化正常但狀態(tài)一直停在線路檢測不過去。排查方法是用示波器或者邏輯分析儀看PHY的中斷引腳有沒有拉低再對照PHY芯片手冊看寄存器狀態(tài)。有一次我把LAN8720的地址配置成1實際上芯片是0結(jié)果receive和transmit完全不通白白查了一天。第二個坑是lwIP內(nèi)存池太小導(dǎo)致TCP傳輸丟數(shù)據(jù)。表現(xiàn)是小包傳輸正常大文件傳輸?shù)揭话脒B接斷開或者數(shù)據(jù)錯亂。原因多半是MEM_SIZE配得太小導(dǎo)致協(xié)議棧沒有足夠的緩沖區(qū)接收大尺寸TCP段。這個問題的排查思路是打開lwIP的調(diào)試輸出功能跟蹤內(nèi)存申請失敗的錯誤日志同時把抓包工具接進(jìn)來看TCP窗口是不是頻繁收縮到0。第三個坑是MAC地址沒有唯一性。這個問題在局域網(wǎng)測試時不容易發(fā)現(xiàn)因為網(wǎng)絡(luò)規(guī)模小MAC沖突概率低。但一旦設(shè)備部署到企業(yè)或者公網(wǎng)的真實環(huán)境中MAC地址沖突會導(dǎo)致嚴(yán)重的通信故障而且極難排查。做量產(chǎn)設(shè)備時每個設(shè)備必須燒錄獨(dú)立的MAC地址這一點務(wù)必提前設(shè)計進(jìn)生產(chǎn)線流程里。7. 經(jīng)典問題排查實錄從三次握手到粘包處理7.1 排查思路先分層再逐段驗證講了這么多理論最后落到實際操作最關(guān)鍵的環(huán)節(jié)當(dāng)你的程序跑不通到底怎么排查問題我一直強(qiáng)調(diào)一個原則永遠(yuǎn)先確定問題出在哪個層再動手排查。我給你一個我自己常用的排查順序先ping目的IP地址。能通說明網(wǎng)絡(luò)層以下沒問題不通檢查本機(jī)IP配置、網(wǎng)關(guān)設(shè)置、物理連接。再測端口連通性。用telnet 目的IP 端口或者nc -zv 目的IP 端口能連上說明TCP層沒問題連不上檢查服務(wù)端是否啟動、防火墻是否擋了端口。再測應(yīng)用層。通過curl或者自己寫的客戶端程序訪問如果請求通了返回內(nèi)容說明應(yīng)用層也正常如果返回錯誤碼針對錯誤碼去查應(yīng)用層邏輯。如果ping通過但TCP連不上大概率問題出在防火墻或監(jiān)聽進(jìn)程如果TCP能連上但數(shù)據(jù)收發(fā)異常重點看應(yīng)用層協(xié)議格式。7.2 TIME_WAIT堆積高并發(fā)場景的隱形殺手TCP四次揮手之后主動關(guān)閉方會進(jìn)入一個叫做TIME_WAIT的狀態(tài)并且默認(rèn)要等2MSL最大報文段生存時間的兩倍通常是2分鐘才徹底釋放連接。很多做高并發(fā)服務(wù)端開發(fā)的同事都被TIME_WAIT坑過。具體場景是這樣的你跑一個壓力測試發(fā)現(xiàn)系統(tǒng)性能上不去大量連接報錯“Cannot assign requested address”。你查看系統(tǒng)狀態(tài)發(fā)現(xiàn)幾萬個連接卡在TIME_WAIT狀態(tài)。原因在于短連接建連、傳輸、斷開場景下主動關(guān)閉方如果承擔(dān)了大量連接關(guān)閉操作每個連接都要排隊等2分鐘才能釋放端口資源端口很快就被占滿了。我提供幾個實際有效的優(yōu)化手段調(diào)低net.ipv4.tcp_fin_timeout讓TIME_WAIT更快回收。開啟net.ipv4.tcp_tw_reuse允許內(nèi)核在安全條件下復(fù)用TIME_WAIT狀態(tài)的連接。如果服務(wù)端程序壓力特別大可以考慮讓客戶端主動關(guān)閉連接盡量把主動關(guān)閉一側(cè)放在連接數(shù)更少的那一端。更徹底的方案是用連接池代替反復(fù)創(chuàng)建短連接從源頭上減少TIME_WAIT的產(chǎn)生。但也要提醒一句tcp_tw_reuse這些參數(shù)需要確認(rèn)內(nèi)核版本與場景是否匹配不是所有環(huán)境都適合照搬。生產(chǎn)環(huán)境改動網(wǎng)絡(luò)內(nèi)核參數(shù)之前務(wù)必先在測試環(huán)境壓測驗證。7.3 TCP粘包與拆包應(yīng)用層協(xié)議設(shè)計的必修課“TCP粘包”是一個在面試和實際開發(fā)里都高頻出現(xiàn)的話題。很多初學(xué)者一聽到粘包就以為TCP協(xié)議本身有毛病會合并數(shù)據(jù)包。實際上TCP面向的是字節(jié)流它在傳輸層并不關(guān)心你一次寫了多少字節(jié)也不會自動幫你劃分消息邊界。如果你連續(xù)發(fā)送了兩次send()數(shù)據(jù)接收方客戶端可能一次性讀到了兩份數(shù)據(jù)合在一起如果一次send()的數(shù)據(jù)太大接收方也可能分成兩次recv()才能讀完。解決粘包問題的核心是在應(yīng)用層自己定義消息邊界。常見方案有三種第一種固定長度。每條消息的字節(jié)數(shù)都相同接收方按固定長度切割。實現(xiàn)最簡單但如果消息內(nèi)容長度參差不齊會浪費(fèi)很多帶寬。第二種分隔符。每條消息末尾加特定分隔符比如\n或者\(yùn)r\n接收方讀到分隔符就認(rèn)為一條消息結(jié)束。HTTP協(xié)議早期就是用空行來分隔頭部和身體。第三種長度字段。消息頭里定義一個固定長度的字段存儲這條消息總的字節(jié)數(shù)接收方先讀取頭再根據(jù)長度讀滿整個消息判定一條消息完整了。這也是工業(yè)界最常用的做法像是很多通信協(xié)議、MQTT的固定頭都用了類似思路。拿嵌入式場景舉例我寫過一套Modbus TCP的采集程序就是采用“4字節(jié)消息頭包含長度消息體”的方案。解析流程是先用recv()讀4字節(jié)消息頭解析出消息體的長度然后循環(huán)調(diào)用recv()直到讀夠長度為止如果一次recv()讀多了把多余的部分緩存起來跟下一輪頭部數(shù)據(jù)拼接后再解析。這樣一個邏輯嚴(yán)密的消息邊界處理流程才算真正把粘包拆包的問題解決了。7.4 一對多通信從modbus到CAN協(xié)議棧的選擇做設(shè)備聯(lián)網(wǎng)的時候經(jīng)常還需要處理現(xiàn)場總線的通信問題比如Modbus TCP和CAN協(xié)議的互聯(lián)。熱詞里提到了CAN協(xié)議棧和CANopen協(xié)議棧這里多聊幾句因為它們跟TCP/IP協(xié)議棧經(jīng)常出現(xiàn)在同一個網(wǎng)關(guān)設(shè)備里。CAN是一個底層總線協(xié)議工作在OSI模型的數(shù)據(jù)鏈路層跟TCP/IP不是一個層級的協(xié)議。你可以用CAN總線來采集現(xiàn)場的傳感器數(shù)據(jù)、控制設(shè)備動作但CAN本身沒有TCP/IP那樣的路由和傳輸層能力通常局限在一個總線網(wǎng)絡(luò)上。如果你的設(shè)備需要把CAN總線的數(shù)據(jù)上報到云端服務(wù)器或者讓兩個CAN網(wǎng)絡(luò)之間跨路由通信就必須在一臺嵌入式網(wǎng)關(guān)設(shè)備上同時管理CAN協(xié)議棧和TCP/IP協(xié)議棧。網(wǎng)關(guān)一邊通過CAN接口采集現(xiàn)場數(shù)據(jù)另一邊用lwIP協(xié)議棧把數(shù)據(jù)通過以太網(wǎng)或者Wi-Fi上傳。那需要移植CANopen協(xié)議棧嗎我的建議是如果項目需要對接標(biāo)準(zhǔn)化的CANopen設(shè)備比如伺服驅(qū)動器、IO模塊、傳感器并且設(shè)備間需要標(biāo)準(zhǔn)化的PDO/SDO通信那就必須移植一套成熟的CANopen協(xié)議棧。常見的開源方案有CANopenNode等。如果只是自己定義簡單的CAN報文格式、自己板子之間互傳數(shù)據(jù)直接用裸CAN收發(fā)即可不需要引入CANopen的復(fù)雜度。最大的誤區(qū)是以為CAN和TCP/IP可以“直接轉(zhuǎn)換”——實際不是。CAN的報文是8字節(jié)的短幀TCP/IP是一次性傳輸大段的數(shù)據(jù)流網(wǎng)關(guān)在做協(xié)議轉(zhuǎn)換時必須自己設(shè)計數(shù)據(jù)映射規(guī)則把哪幾個CAN報文組合成一包TCP消息、按什么周期上報、錯誤怎么處理。這些規(guī)則的合理性直接決定整個系統(tǒng)的實時性和可靠性。8. 寫在最后我的一些實戰(zhàn)體會文章寫到這里TCP/IP協(xié)議棧從設(shè)計思路到分層細(xì)節(jié)、從Socket編程到嵌入式移植、從抓包觀察到問題排查基本都覆蓋到了。最后分享幾點我這些年做網(wǎng)絡(luò)項目總結(jié)出來的體會算是一些題外話第一學(xué)協(xié)議棧千萬不要死記硬背報文格式。我最開始學(xué)的時候把所有TCP頭部的字段背得滾瓜爛熟結(jié)果真到了抓包分析的時候反而對著一個不常見的數(shù)據(jù)包發(fā)懵。報文格式這種東西用的時候打開參考資料看就可以了真正應(yīng)該爛熟于心的是“數(shù)據(jù)是怎么流動的、每一層在做什么判斷”。第二抓包工具一定要常備。Wireshark不光是排查問題的時候才用。平時寫完一段網(wǎng)絡(luò)通信代碼主動抓包看看自己代碼發(fā)出去的數(shù)據(jù)長什么樣和協(xié)議文檔對一下能幫你發(fā)現(xiàn)很多自己不以為意但不能忽略的細(xì)節(jié)問題。我的習(xí)慣是凡是涉及網(wǎng)絡(luò)通信的模塊開發(fā)階段必須至少抓包驗證一次。第三嵌入式做網(wǎng)絡(luò)開發(fā)要把底層環(huán)境的極限參數(shù)摸清楚。在MCU上跑協(xié)議棧和PC上不一樣內(nèi)存不夠你隨時可以加MCU是焊死在板子上的一旦內(nèi)存估錯了整個方案可能就要重做。拿lwIP來說打開哪些功能、關(guān)閉哪些功能、每個緩沖池配多大都要對著RAM的剩余空間精打細(xì)算。第四協(xié)議棧是工具不是目的。很多工程師容易陷入“我要把TCP/IP吃透”的技術(shù)執(zhí)念里反而忘記了自己做項目的真正目標(biāo)是解決業(yè)務(wù)問題。協(xié)議棧的各個協(xié)議就是工具箱里的扳手和螺絲刀今天需要用HTTP就調(diào)HTTP需要MQTT就上MQTT不要為了炫技而使用復(fù)雜方案。不知道你們最近在做什么網(wǎng)絡(luò)相關(guān)的項目遇到過的比較頭疼的問題是什么可以在評論區(qū)聊聊我看到了會盡量回復(fù)。 一文講透TCP/IP協(xié)議棧：從分層原理到Socket編程與嵌入式實戰(zhàn)
1. 先搞明白TCP/IP協(xié)議棧到底是個什么東西很多人一聽到“TCP/IP協(xié)議?！边@七個字就開始頭皮發(fā)麻腦子里全是大學(xué)《計算機(jī)網(wǎng)絡(luò)》教材上那些密密麻麻的分層圖解、三次握手四次揮手、各種報文字段說明。說實話當(dāng)年我也一樣對著課本背了好幾遍考完試全忘了直到后來自己上手抓包、寫Socket程序、做嵌入式網(wǎng)絡(luò)網(wǎng)關(guān)才真正把這一套東西的內(nèi)核給吃透了。先給沒基礎(chǔ)的朋友一句話交代清楚TCP/IP協(xié)議棧本質(zhì)上就是一套“互聯(lián)網(wǎng)世界的快遞系統(tǒng)”的規(guī)則總和。你發(fā)一條微信、打開一個網(wǎng)頁、推送一幀設(shè)備數(shù)據(jù)背后都是數(shù)據(jù)包在網(wǎng)絡(luò)上跑。而數(shù)據(jù)包怎么打包、怎么寫地址、怎么運(yùn)輸、怎么確認(rèn)對方收到了這套完整規(guī)則就是TCP/IP協(xié)議棧。它不是一個協(xié)議而是一組協(xié)議按照分工、分層組織起來的集合“棧”這個字說的就是它們一層摞一層、各管一段的工作方式。這玩意兒能解決的問題往大說是全互聯(lián)網(wǎng)設(shè)備互聯(lián)互通的問題往小說是你手頭一個單片機(jī)的數(shù)據(jù)怎么發(fā)給云端服務(wù)器的問題。不管你是做后端開發(fā)、嵌入式開發(fā)、網(wǎng)絡(luò)運(yùn)維還是單純想搞明白“打開網(wǎng)頁的瞬間到底發(fā)生了什么”TCP/IP協(xié)議棧都是繞不開的那條主線。這篇內(nèi)容我會講清楚它的設(shè)計思路、各層職責(zé)、數(shù)據(jù)流動的完整路徑再配合實際抓包和代碼示例深入拆解最后聊聊我踩過的那些坑。2. 協(xié)議棧為什么非要分層這套設(shè)計到底精妙在哪2.1 沒有分層之前通信是什么鬼樣子要理解TCP/IP協(xié)議棧的價值最好先看一眼沒有分層的時候通信是什么狀態(tài)。早期的網(wǎng)絡(luò)通信基本是兩家廠商各自定義一套自己的規(guī)則物理接口怎么定義、數(shù)據(jù)怎么編碼、怎么尋址、怎么檢測錯誤全都揉在一起。結(jié)果是A廠商的設(shè)備只能跟A廠商的設(shè)備通信想接入B廠商的系統(tǒng)對不起不兼容。這就好比你想寄快遞結(jié)果每個快遞公司都有自己的箱子尺寸、填單格式、運(yùn)輸路線你寄順豐的包裹圓通不認(rèn)圓通寫好的單子申通看不懂——整個物流系統(tǒng)完全亂套。而分層做的事情就是把快遞整個流程拆成幾個獨(dú)立環(huán)節(jié)你只管把東西交給前臺、前臺負(fù)責(zé)打包貼單、運(yùn)輸隊負(fù)責(zé)把包裹送到另一個城市、派送員負(fù)責(zé)送到收件人手上。每一層只需要跟自己上面和下面的環(huán)節(jié)打交道不需要管其他環(huán)節(jié)怎么實現(xiàn)。2.2 四層模型每一層到底管什么標(biāo)準(zhǔn)的TCP/IP模型分四層從上到下分別是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、網(wǎng)絡(luò)接口層。注意很多教材里會把網(wǎng)絡(luò)接口層再拆成數(shù)據(jù)鏈路層和物理層對應(yīng)OSI七層模型的說法但在實戰(zhàn)中我們基本都是按四層來理解和排查問題的。我用快遞類比把這四層說清楚應(yīng)用層就是你寄快遞時填寫的那張寄件單上面寫著“我要寄什么內(nèi)容”。對應(yīng)到技術(shù)上HTTP、HTTPS、FTP、DNS、MQTT這些協(xié)議都住在這一層它們定義了數(shù)據(jù)的具體格式和業(yè)務(wù)語義。你在瀏覽器里輸入的網(wǎng)址、App里刷的信息流最終都是靠應(yīng)用層協(xié)議來表達(dá)的。傳輸層相當(dāng)于快遞公司的客服中心負(fù)責(zé)確認(rèn)“這個包裹到底該不該寄、寄了有沒有丟”。它給數(shù)據(jù)加上端口號標(biāo)識出這份數(shù)據(jù)是給哪個應(yīng)用程序的同時負(fù)責(zé)分片、重組、流量控制。TCP和UDP就是這一層的大佬。網(wǎng)絡(luò)層相當(dāng)于快遞的干線運(yùn)輸網(wǎng)絡(luò)負(fù)責(zé)規(guī)劃路徑、決定包裹從哪個城市經(jīng)轉(zhuǎn)、最終到達(dá)哪個城市。IP協(xié)議是這一層的核心它給每臺設(shè)備編一個邏輯地址IP地址然后通過路由協(xié)議找到一條能到達(dá)目的地址的路。網(wǎng)絡(luò)接口層相當(dāng)于快遞的末端運(yùn)輸負(fù)責(zé)把包裹在具體的物理線路比如網(wǎng)線、光纖、Wi-Fi無線電波上傳出去還負(fù)責(zé)把IP地址翻譯成硬件地址MAC地址。這四層之間的關(guān)系關(guān)鍵在于每一層只依賴下一層提供的服務(wù)不需要關(guān)心下一層具體怎么實現(xiàn)。傳輸層不需要知道數(shù)據(jù)到底走的是光纖還是Wi-Fi網(wǎng)絡(luò)層不需要知道上層是HTTP還是MQTT。這種“高內(nèi)聚、低耦合”的設(shè)計是整個互聯(lián)網(wǎng)能夠以極低代價接入新協(xié)議、新硬件的前提。2.3 分層帶來的實際好處不是理論空談分層的優(yōu)點做工程的人體會最深。我舉三個實際場景第一個是故障排查。網(wǎng)絡(luò)出了問題工程師有一個默認(rèn)的排查順序先看物理層通不通網(wǎng)線插好沒、再看鏈路層MAC地址、ARP、然后看網(wǎng)絡(luò)層IP通不通、路由對不對、再看傳輸層端口通不通、TCP連接建沒建立、最后才看應(yīng)用層HTTP狀態(tài)碼。每一層都有獨(dú)立的排查工具和手段你不需要一上來就把整個協(xié)議棧的每個字節(jié)都翻一遍。分層最大的工程意義就是把“網(wǎng)絡(luò)壞了”這個大問題拆成了多個可以獨(dú)立定位的小問題。第二個是技術(shù)演進(jìn)。今天你的網(wǎng)絡(luò)接入從百兆以太網(wǎng)換成了Wi-Fi 6甚至換成了5G蜂窩網(wǎng)絡(luò)需要替換的只有最底下那層——網(wǎng)絡(luò)接口層。上面的TCP/IP協(xié)議棧根本不用改。反過來你想從HTTP升級到HTTP/3也只動了最上面應(yīng)用層底下的TCP/IP該怎么跑還是怎么跑。這種“局部替換、全局不動”的能力是互聯(lián)網(wǎng)技術(shù)能夠快速迭代的重要基礎(chǔ)。第三個是安全隔離。每一層都可以獨(dú)立做安全檢查網(wǎng)絡(luò)層可以做IP白名單傳輸層可以做端口管控應(yīng)用層可以做內(nèi)容過濾。層次清晰安全策略就能在不同環(huán)節(jié)獨(dú)立部署而不會胡亂糾纏在一起。3. 核心機(jī)制深度拆解IP、TCP、UDP到底在干什么3.1 網(wǎng)絡(luò)層核心IP協(xié)議如何完成尋址和路由IP協(xié)議是這個協(xié)議棧里真正承擔(dān)“互聯(lián)網(wǎng)尋址”功能的角色。每一臺接入網(wǎng)絡(luò)的設(shè)備都會有一個IP地址就像你家門牌號。數(shù)據(jù)包要到達(dá)目的地網(wǎng)絡(luò)層的路由器就負(fù)責(zé)根據(jù)目的IP地址一跳一跳地把數(shù)據(jù)轉(zhuǎn)發(fā)過去。IP協(xié)議有兩個版本IPv4和IPv6。我們平時最常見的IPv4地址是32位的比如192.168.1.100這種格式理論上能提供的地址總數(shù)是2的32次方大約43億個。聽著多但放到全球幾十億設(shè)備上網(wǎng)的今天早就捉襟見肘了。這也是IPv6要把地址擴(kuò)展到128位的原因——數(shù)量多到幾乎可以給地球上每一粒沙子都分配一個IP。但I(xiàn)P協(xié)議本身只負(fù)責(zé)“盡力而為”地投遞它不保證數(shù)據(jù)包一定能到達(dá)目的地。它做了三件事給數(shù)據(jù)包加上源IP地址和目的IP地址、根據(jù)路由表決定下一跳走向、如果數(shù)據(jù)包太大就進(jìn)行分片。至于到了沒有、順序?qū)Σ粚Α⒂袥]有丟包IP協(xié)議一概不管。所以大家常說IP協(xié)議是“不可靠的”。那“不可靠”是不是意味著IP協(xié)議很弱恰恰相反這種設(shè)計是故意的。網(wǎng)絡(luò)環(huán)境千差萬別如果在IP這一層就要保證可靠那所有中間設(shè)備都必須維護(hù)海量的狀態(tài)信息代價高到難以想象。不如讓IP層做到最簡把可靠性的問題甩給上層去解決——這就引出了TCP存在的意義。3.2 傳輸層核心TCP怎么把“不可靠”變成“可靠”TCP做的事情通俗點講就是在IP“盡力而為”的基礎(chǔ)上增加了三重保險確認(rèn)機(jī)制、重傳機(jī)制、順序控制。先說確認(rèn)機(jī)制。發(fā)送方每發(fā)出一個數(shù)據(jù)包接收方收到之后要給發(fā)送方回一個ACK確認(rèn)應(yīng)答相當(dāng)于快遞簽收回執(zhí)。發(fā)送方如果一段時間內(nèi)沒收到某個包的ACK就認(rèn)為這個包丟了于是重傳一次。這個“超時重傳”機(jī)制是TCP可靠性的基石。再說順序控制。IP層轉(zhuǎn)發(fā)數(shù)據(jù)的時候每個數(shù)據(jù)包走的路由可能不一樣先發(fā)的包未必先到。TCP在每個數(shù)據(jù)包上打上序號接收方根據(jù)序號重新排序保證交給應(yīng)用層的數(shù)據(jù)是完整有序的。這也是為什么下載大文件時即使網(wǎng)絡(luò)有抖動最終拼出來的文件還是分毫不差。還有一個大家面試經(jīng)常被問到的“三次握手”。建立連接時客戶端先發(fā)一個SYN包服務(wù)端回一個SYNACK包客戶端再回一個ACK包。為啥要三次握手簡單的回答是需要雙方都確認(rèn)“我發(fā)的你能收到你發(fā)的我也能收到”。第一次握手讓服務(wù)端確認(rèn)客戶端能發(fā)第二次握手讓客戶端確認(rèn)服務(wù)端能收也能發(fā)第三次握手讓服務(wù)端確認(rèn)客戶端能收。只握兩次的話服務(wù)端沒法確認(rèn)客戶端是否收到了自己的回應(yīng)連接狀態(tài)可能不一致。TCP還有一套復(fù)雜的流量控制和擁塞控制機(jī)制涉及滑動窗口、慢啟動、擁塞避免、快重傳這些概念。篇幅有限不全部展開但大家記住一個核心TCP本質(zhì)上是在用“犧牲一點傳輸效率”來換取“數(shù)據(jù)的可靠交付”它適合對數(shù)據(jù)完整性要求高的場景——比如網(wǎng)頁瀏覽、文件傳輸、郵件收發(fā)。3.3 傳輸層另一面UDP為什么延遲低、開銷小有TCP在前面撐著可靠性為什么還需要UDP因為不是所有場景都“非可靠不可”。UDP做的事情極其簡單把數(shù)據(jù)包從一端丟到另一端不加序號、不確認(rèn)、不重傳。它只比IP多了一個端口號的概念讓數(shù)據(jù)能送到指定的應(yīng)用程序。UDP的好處很明顯頭部開銷小固定8字節(jié)TCP頭部最少20字節(jié)、沒有連接建立的延遲、沒有確認(rèn)和重傳機(jī)制帶來的等待。這就是為什么實時音視頻通話、在線游戲、DNS查詢這些“低延遲優(yōu)先、偶爾掉一兩幀沒關(guān)系”的場景都首選UDP。比如視頻通話的時候如果中間網(wǎng)絡(luò)抖動丟了一幀畫面TCP會怎么做它會重傳這一幀結(jié)果視頻畫面等了一輪重傳才補(bǔ)上來整體反而更卡。UDP的做法是丟了就丟了下一幀馬上接著來用戶感知上反而是流暢的?！翱煽俊辈⒉挥肋h(yuǎn)是“最優(yōu)”很多時候“及時”比“完整”更重要。3.4 應(yīng)用層常見協(xié)議從HTTP到MQTT應(yīng)用層的協(xié)議是普通開發(fā)者接觸最多的一層其中HTTP/HTTPS是絕對的主角。HTTP規(guī)定了客戶端比如瀏覽器和服務(wù)端比如Web服務(wù)器之間請求-響應(yīng)的交互格式請求行、請求頭、請求體響應(yīng)行、響應(yīng)頭、響應(yīng)體。HTTPS則是在HTTP和TCP之間加了一層TLS加密讓明文數(shù)據(jù)變成密文傳輸。在實際工程項目里除了HTTP還有幾個高頻出現(xiàn)的應(yīng)用層協(xié)議值得留意DNS負(fù)責(zé)把域名比如www.example.com解析成IP地址這是打開網(wǎng)頁的第一步。MQTT專為物聯(lián)網(wǎng)設(shè)備設(shè)計的輕量級消息協(xié)議基于TCP發(fā)布/訂閱模式很適合嵌入式設(shè)備上報數(shù)據(jù)。CoAP基于UDP的物聯(lián)網(wǎng)協(xié)議比MQTT更輕面向資源受限的設(shè)備。FTP/SFTP文件傳輸專用。很多人在做項目的時候糾結(jié)“該用HTTP還是MQTT”我的判斷標(biāo)準(zhǔn)很簡單如果設(shè)備需要頻繁雙向通信、需要服務(wù)端主動推送消息MQTT更合適如果只是周期性上報數(shù)據(jù)或者需要跟Web系統(tǒng)打通HTTP更簡單直接。這個后面實操章節(jié)我還會再談。4. 從一個數(shù)據(jù)包看完整旅程抓包實測與封裝拆裝4.1 數(shù)據(jù)包的封裝從HTTP請求到鏈路層幀理論講得再多不如看一次真實的數(shù)據(jù)包流動。我來模擬一個最簡單的場景你在瀏覽器里訪問一個網(wǎng)站看看一次HTTP請求是怎么從上到下被“加工”成可以在網(wǎng)線上傳輸?shù)男盘?。第一步?yīng)用層。瀏覽器構(gòu)造一個HTTP請求報文里面包含請求行GET /index.html HTTP/1.1、請求頭Host、User-Agent之類的字段、可能還有請求體。第二步傳輸層。TCP協(xié)議把這個HTTP報文當(dāng)作自己的“數(shù)據(jù)載荷”在前面加上一個TCP頭部。TCP頭部里最關(guān)鍵的字段是源端口比如瀏覽器隨機(jī)分配一個如54321和目的端口HTTP默認(rèn)80HTTPS默認(rèn)443以及剛才提到的序號和確認(rèn)號。這時候數(shù)據(jù)塊被叫做“TCP段”Segment。第三步網(wǎng)絡(luò)層。IP協(xié)議把整個TCP段當(dāng)作載荷加上一個IP頭部。IP頭部的關(guān)鍵字段包括源IP地址你本機(jī)的地址和目的IP地址服務(wù)器地址還有總長度、協(xié)議號6代表TCP17代表UDP。這時候數(shù)據(jù)塊叫做“IP數(shù)據(jù)報”Packet。第四步網(wǎng)絡(luò)接口層。數(shù)據(jù)鏈路層再把整個IP數(shù)據(jù)報當(dāng)作載荷加上以太網(wǎng)幀頭——幀頭里包含源MAC地址和目的MAC地址。那目的MAC地址怎么確定如果目的IP跟自己不在同一網(wǎng)段數(shù)據(jù)包要先發(fā)給網(wǎng)關(guān)通常是路由器所以這里的“目的MAC地址”實際上是網(wǎng)關(guān)的MAC地址由ARP協(xié)議負(fù)責(zé)查詢。這一層生成的是“以太網(wǎng)幀”Frame。到了接收端整個流程反過來網(wǎng)卡收到以太網(wǎng)幀剝掉幀頭發(fā)現(xiàn)里面是個IP數(shù)據(jù)報IP層剝掉IP頭發(fā)現(xiàn)里面是個TCP段TCP層剝掉TCP頭確認(rèn)是給自己的數(shù)據(jù)再把HTTP報文交給瀏覽器解析。每一層只處理自己關(guān)心的頭部信息然后把剩下的載荷原封不動地往上交。這就是所謂的“分層解封裝”。4.2 用Wireshark看一次真實的HTTP請求理論描述終究不如現(xiàn)場抓包我推薦大家安裝一個Wireshark自己動手做一次抓包實驗。操作很簡單打開Wireshark選擇正在使用的網(wǎng)卡設(shè)置過濾條件http然后隨便訪問一個HTTP網(wǎng)站注意要訪問HTTP的因為HTTPS的載荷是加密的你只能看到TLS握手看不到明文HTTP內(nèi)容。如果你找不到HTTP網(wǎng)站可以本地起一個簡單的Python HTTP服務(wù)在某個目錄下執(zhí)行python3 -m http.server 8000然后用瀏覽器訪問http://localhost:8000。你會看到Wireshark里捕獲到一串?dāng)?shù)據(jù)包。點開其中一個帶HTTP GET標(biāo)識的包能看到完整的四層信息Frame層顯示物理層信息包括幀長度等。Ethernet II層顯示源MAC、目的MAC、上層協(xié)議類型0x0800表示上層是IPv4。Internet Protocol Version 4層顯示源IP、目的IP、協(xié)議號6TCP、TTL、校驗和等。Transmission Control Protocol層顯示源端口、目的端口、Seq序號、Ack確認(rèn)號、Window窗口大小等。Hypertext Transfer Protocol層顯示實際的HTTP請求行和請求頭。建議各位看的時候有個心理準(zhǔn)備一個看起來簡簡單單的網(wǎng)頁請求在Wireshark里往往對應(yīng)幾十上百個數(shù)據(jù)包。因為除了頁面本身的HTML瀏覽器還會并行發(fā)起CSS、JS、圖片等資源的請求而且每個TCP請求之前都先有三次握手之后可能還有四次揮手。這種“肉眼可見的復(fù)雜”就是真實互聯(lián)網(wǎng)的日常。4.3 為什么說抓包是學(xué)習(xí)協(xié)議棧最快的方式很多人學(xué)TCP/IP最容易犯的毛病是只看書不抓包。書上的報文格式畫得再清楚都是靜態(tài)的文字你真正在抓包工具里看到一個一個字段躺在那里、跟著一次請求從頭到尾走一遍才真正理解“誰在什么時候加什么頭、每個字段到底干什么用”。我建議一個遞進(jìn)式的學(xué)習(xí)路線先開著Wireshark逛幾個網(wǎng)頁不設(shè)置過濾只看數(shù)據(jù)包數(shù)量的暴增感受一下握手的全過程。設(shè)過濾條件tcp觀察一條TCP連接從SYN、SYNACK、ACK到后面?zhèn)鬏敂?shù)據(jù)、最后FIN結(jié)束的完整生命周期。設(shè)過濾條件dns看看瀏覽器訪問網(wǎng)站之前DNS查詢是怎么用UDP包往返的。設(shè)過濾條件http配合瀏覽器訪問一次HTTP站點把請求-響應(yīng)對應(yīng)起來看。最后嘗試自己寫一個TCP服務(wù)器和客戶端用抓包軟件觀察自己代碼發(fā)出的數(shù)據(jù)包長什么樣。走到第五步你對協(xié)議棧的理解基本就站在一個非常扎實的水平了。5. Socket編程實操用C語言手寫一個TCP通信5.1 什么是Socket它不是協(xié)議是接口很多做嵌入式或者剛?cè)腴T服務(wù)端開發(fā)的同學(xué)總把Socket和TCP/IP混為一談。我不止一次被人問“TCP和Socket有什么區(qū)別”——這個問題要回答清楚得先說結(jié)論Socket不是協(xié)議它是操作系統(tǒng)提供給我們調(diào)用TCP/IP協(xié)議棧的編程接口。TCP/IP協(xié)議棧雖然內(nèi)置于操作系統(tǒng)內(nèi)核里但你不能直接拿根針戳進(jìn)內(nèi)核去操作它。內(nèi)核對外開了一組系統(tǒng)調(diào)用讓你可以創(chuàng)建連接、發(fā)送數(shù)據(jù)、接收數(shù)據(jù)、關(guān)閉連接這一組接口就是Socket API?？梢园阉斫鉃椴蛷d的菜單后廚有一套復(fù)雜的做菜流程協(xié)議棧你不需要進(jìn)后廚你只需要按菜單點菜調(diào)用Socket API菜就能端到你面前。5.2 完整實現(xiàn)TCP服務(wù)端和客戶端我直接給出一份最精簡但五臟俱全的C語言TCP通信代碼包含了服務(wù)端和客戶端。這段代碼沒有做詳細(xì)的錯誤處理但完整的骨架都在適合對照著學(xué)習(xí)。服務(wù)端代碼#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h int main() { int server_fd, client_fd; struct sockaddr_in server_addr, client_addr; socklen_t addr_len sizeof(client_addr); char buffer[1024] {0}; char *response Hello from TCP Server; // 1. 創(chuàng)建socketAF_INET表示IPv4SOCK_STREAM表示TCP server_fd socket(AF_INET, SOCK_STREAM, 0); if (server_fd 0) { perror(socket); exit(EXIT_FAILURE); } // 2. 綁定端口和地址 server_addr.sin_family AF_INET; server_addr.sin_addr.s_addr INADDR_ANY; // 綁定所有網(wǎng)卡 server_addr.sin_port htons(8080); // 端口號轉(zhuǎn)網(wǎng)絡(luò)字節(jié)序 if (bind(server_fd, (struct sockaddr *)server_addr, sizeof(server_addr)) 0) { perror(bind); close(server_fd); exit(EXIT_FAILURE); } // 3. 監(jiān)聽最大等待隊列長度設(shè)為3 if (listen(server_fd, 3) 0) { perror(listen); close(server_fd); exit(EXIT_FAILURE); } printf(Server listening on port 8080...\n); // 4. 接受客戶端連接阻塞等待 client_fd accept(server_fd, (struct sockaddr *)client_addr, addr_len); if (client_fd 0) { perror(accept); close(server_fd); exit(EXIT_FAILURE); } printf(Client connected: %s\n, inet_ntoa(client_addr.sin_addr)); // 5. 接收數(shù)據(jù)并響應(yīng) int bytes_read read(client_fd, buffer, sizeof(buffer)); printf(Received: %s\n, buffer); send(client_fd, response, strlen(response), 0); // 6. 關(guān)閉連接 close(client_fd); close(server_fd); return 0; }客戶端代碼#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h int main() { int sock_fd; struct sockaddr_in server_addr; char buffer[1024] {0}; char *message Hello from TCP Client; // 1. 創(chuàng)建socket sock_fd socket(AF_INET, SOCK_STREAM, 0); if (sock_fd 0) { perror(socket); exit(EXIT_FAILURE); } // 2. 設(shè)置服務(wù)器地址 server_addr.sin_family AF_INET; server_addr.sin_addr.s_addr inet_addr(127.0.0.1); // 本機(jī)回環(huán)地址 server_addr.sin_port htons(8080); // 3. 連接服務(wù)器 if (connect(sock_fd, (struct sockaddr *)server_addr, sizeof(server_addr)) 0) { perror(connect); close(sock_fd); exit(EXIT_FAILURE); } printf(Connected to server.\n); // 4. 發(fā)送數(shù)據(jù) send(sock_fd, message, strlen(message), 0); // 5. 接收響應(yīng) int bytes_read read(sock_fd, buffer, sizeof(buffer)); printf(Server response: %s\n, buffer); // 6. 關(guān)閉連接 close(sock_fd); return 0; }編譯方式gcc tcp_server.c -o tcp_server gcc tcp_client.c -o tcp_client先在一個終端運(yùn)行./tcp_server再開另一個終端運(yùn)行./tcp_client就能看到數(shù)據(jù)通暢地在兩端之間流動。5.3 幾個關(guān)鍵細(xì)節(jié)搞清楚才算真會了上面代碼看著簡單但里面有幾個關(guān)鍵細(xì)節(jié)值得展開說說。第一個是htons()函數(shù)。這里用到了“網(wǎng)絡(luò)字節(jié)序”的概念。不同的CPU在內(nèi)存里存放多字節(jié)整數(shù)的方式不一樣有的用大端、有的用小端。為了保證所有設(shè)備之間數(shù)據(jù)能正確解析網(wǎng)絡(luò)傳輸統(tǒng)一使用大端字節(jié)序也叫網(wǎng)絡(luò)字節(jié)序。我們的端口號8080在本地內(nèi)存里可能是小端存儲的直接放到報文里發(fā)出去對端解析必然出錯。所以發(fā)送前必須用htons()把主機(jī)字節(jié)序轉(zhuǎn)換成網(wǎng)絡(luò)字節(jié)序接收端再通過ntohs()轉(zhuǎn)回來。別小看這個細(xì)節(jié)很多新手第一次寫網(wǎng)絡(luò)程序報錯半天找不到原因最后發(fā)現(xiàn)是字節(jié)序沒轉(zhuǎn)。第二個是accept()返回的新socket。注意服務(wù)端有兩個文件描述符一個是server_fd負(fù)責(zé)監(jiān)聽新連接另一個是client_fd負(fù)責(zé)跟已經(jīng)連接的客戶端通信。監(jiān)聽的socket只負(fù)責(zé)“接客”真正“聊天”的是accept返回的新socket。一個監(jiān)聽socket可以accept出多個連接socket這是并發(fā)服務(wù)器的底層基礎(chǔ)。第三個是客戶端connect()建立的連接。connect的過程在底層就是發(fā)送SYN、接收SYNACK、發(fā)送ACK的三次握手。你調(diào)用connect時如果網(wǎng)絡(luò)不通或者服務(wù)器沒監(jiān)聽對應(yīng)端口connect會阻塞一段時間然后報錯。這段阻塞期間底層TCP重傳機(jī)制一直在努力很多莫名其妙網(wǎng)絡(luò)“卡頓”的感知其實都是TCP在默默重試。5.4 從C代碼到真實的工程項目差距在哪上面的代碼只是個模型。真實的服務(wù)器程序不可能只處理一個客戶端連接——它需要持續(xù)監(jiān)聽、同時服務(wù)大量連接。這意味著你需要用到多線程、IO多路復(fù)用select/poll/epoll、事件驅(qū)動模型這些更進(jìn)階的技術(shù)。但這并不意味著這份入門代碼沒有價值。它最大的價值是讓你看到TCP操作的完整流程理解每個步驟在協(xié)議棧里對應(yīng)什么動作。先跑通它再去學(xué)epoll、學(xué)Reactor模型你的理解曲線會平滑得多。6. 嵌入式場景實戰(zhàn)STM32 lwIP協(xié)議棧移植要點6.1 為什么嵌入式設(shè)備需要lwIP前面聊的主要是PC和服務(wù)器的場景。這幾年我做嵌入式項目比較多發(fā)現(xiàn)越來越多的設(shè)備要求聯(lián)網(wǎng)傳感器數(shù)據(jù)要上云、設(shè)備要遠(yuǎn)程控制、固件要在線升級。這些場景里跑在STM32這類MCU上的TCP/IP協(xié)議棧最常用的就是lwIP。lwIP的全稱是Lightweight IP是一個開源的精簡TCP/IP協(xié)議棧專門為資源受限的嵌入式系統(tǒng)設(shè)計。跟PC上的協(xié)議棧相比lwIP最核心的設(shè)計目標(biāo)就是在極小的內(nèi)存占用下盡可能提供完整的TCP/IP功能。它支持TCP、UDP、ICMP、DHCP、自動網(wǎng)卡配置等常用功能還提供了一個精簡的Socket API雖然跟標(biāo)準(zhǔn)Socket API不完全兼容但概念一致。為什么很多項目選lwIP而不是直接在MCU上跑標(biāo)準(zhǔn)協(xié)議棧原因很直接標(biāo)準(zhǔn)協(xié)議棧對內(nèi)存的功耗要求太高。一個完整的TCP連接需要維護(hù)發(fā)送緩沖區(qū)、接收緩沖區(qū)、滑動窗口狀態(tài)等光靠MCU上那幾十到幾百KB級別的內(nèi)存根本吃不消。lwIP通過減少緩存區(qū)大小、簡化協(xié)議狀態(tài)、允許用戶自行配置內(nèi)存池等策略把內(nèi)存占用壓到極低水平。6.2 STM32移植lwIP的核心步驟用CubeMX做STM32的lwIP移植是目前最主流的方式流程可以概括為以下幾步第一步在CubeMX里配置好以太網(wǎng)外設(shè)。選擇目標(biāo)MCU型號打開ETH外設(shè)配置RMII接口模式、PHY芯片地址、時鐘等。如果板子上接了LAN8720之類的PHY芯片注意把PHY Address設(shè)置好比如LAN8720默認(rèn)地址是0。第二步在Middleware里勾選LwIP。此時需要設(shè)置協(xié)議棧的關(guān)鍵參數(shù)內(nèi)存堆大小MEM_SIZE、內(nèi)存池數(shù)量MEMP_NUMBER、最大TCP連接數(shù)MEMP_NUM_TCP_SEG、TCP接收窗口大小TCP_WND等。這些參數(shù)直接決定協(xié)議棧能支持多少并發(fā)連接、緩沖區(qū)多大、內(nèi)存占用多高需要根據(jù)MCU的RAM容量來調(diào)整。第三步配置網(wǎng)卡驅(qū)動和PHY驅(qū)動。CubeMX生成的模板內(nèi)置了常見PHY芯片的驅(qū)動支持但有些板子的PHY型號需要自己適配。第四步修改LAN8720相關(guān)的底層函數(shù)。這塊往往是最容易出錯的地方因為不同PHY芯片的寄存器操作方式差異很大。需要確認(rèn)PHY地址、復(fù)位引腳、中斷引腳在代碼里的配置是否正確。第五步在主循環(huán)里調(diào)用MX_LWIP_Process()這個函數(shù)負(fù)責(zé)讓協(xié)議棧周期性地處理定時器事件、ARP緩存過期、TCP重傳等問題。如果你沒用RTOS這個函數(shù)必須高頻調(diào)用比如每1-2ms一次否則TCP連接建立不起來、或者連接保持不住。6.3 我踩過的嵌入式網(wǎng)絡(luò)坑嵌入式TCP/IP開發(fā)跟PC端開發(fā)最大的區(qū)別是沒有現(xiàn)成的調(diào)試工具鏈所有問題都得靠日志和示波器一點一點摳。我在這里列幾個我實際遇到過的坑都是血淚教訓(xùn)。第一個坑是PHY地址配錯導(dǎo)致Link Up不了。這個現(xiàn)象最常見eth網(wǎng)卡初始化正常但狀態(tài)一直停在線路檢測不過去。排查方法是用示波器或者邏輯分析儀看PHY的中斷引腳有沒有拉低再對照PHY芯片手冊看寄存器狀態(tài)。有一次我把LAN8720的地址配置成1實際上芯片是0結(jié)果receive和transmit完全不通白白查了一天。第二個坑是lwIP內(nèi)存池太小導(dǎo)致TCP傳輸丟數(shù)據(jù)。表現(xiàn)是小包傳輸正常大文件傳輸?shù)揭话脒B接斷開或者數(shù)據(jù)錯亂。原因多半是MEM_SIZE配得太小導(dǎo)致協(xié)議棧沒有足夠的緩沖區(qū)接收大尺寸TCP段。這個問題的排查思路是打開lwIP的調(diào)試輸出功能跟蹤內(nèi)存申請失敗的錯誤日志同時把抓包工具接進(jìn)來看TCP窗口是不是頻繁收縮到0。第三個坑是MAC地址沒有唯一性。這個問題在局域網(wǎng)測試時不容易發(fā)現(xiàn)因為網(wǎng)絡(luò)規(guī)模小MAC沖突概率低。但一旦設(shè)備部署到企業(yè)或者公網(wǎng)的真實環(huán)境中MAC地址沖突會導(dǎo)致嚴(yán)重的通信故障而且極難排查。做量產(chǎn)設(shè)備時每個設(shè)備必須燒錄獨(dú)立的MAC地址這一點務(wù)必提前設(shè)計進(jìn)生產(chǎn)線流程里。7. 經(jīng)典問題排查實錄從三次握手到粘包處理7.1 排查思路先分層再逐段驗證講了這么多理論最后落到實際操作最關(guān)鍵的環(huán)節(jié)當(dāng)你的程序跑不通到底怎么排查問題我一直強(qiáng)調(diào)一個原則永遠(yuǎn)先確定問題出在哪個層再動手排查。我給你一個我自己常用的排查順序先ping目的IP地址。能通說明網(wǎng)絡(luò)層以下沒問題不通檢查本機(jī)IP配置、網(wǎng)關(guān)設(shè)置、物理連接。再測端口連通性。用telnet 目的IP 端口或者nc -zv 目的IP 端口能連上說明TCP層沒問題連不上檢查服務(wù)端是否啟動、防火墻是否擋了端口。再測應(yīng)用層。通過curl或者自己寫的客戶端程序訪問如果請求通了返回內(nèi)容說明應(yīng)用層也正常如果返回錯誤碼針對錯誤碼去查應(yīng)用層邏輯。如果ping通過但TCP連不上大概率問題出在防火墻或監(jiān)聽進(jìn)程如果TCP能連上但數(shù)據(jù)收發(fā)異常重點看應(yīng)用層協(xié)議格式。7.2 TIME_WAIT堆積高并發(fā)場景的隱形殺手TCP四次揮手之后主動關(guān)閉方會進(jìn)入一個叫做TIME_WAIT的狀態(tài)并且默認(rèn)要等2MSL最大報文段生存時間的兩倍通常是2分鐘才徹底釋放連接。很多做高并發(fā)服務(wù)端開發(fā)的同事都被TIME_WAIT坑過。具體場景是這樣的你跑一個壓力測試發(fā)現(xiàn)系統(tǒng)性能上不去大量連接報錯“Cannot assign requested address”。你查看系統(tǒng)狀態(tài)發(fā)現(xiàn)幾萬個連接卡在TIME_WAIT狀態(tài)。原因在于短連接建連、傳輸、斷開場景下主動關(guān)閉方如果承擔(dān)了大量連接關(guān)閉操作每個連接都要排隊等2分鐘才能釋放端口資源端口很快就被占滿了。我提供幾個實際有效的優(yōu)化手段調(diào)低net.ipv4.tcp_fin_timeout讓TIME_WAIT更快回收。開啟net.ipv4.tcp_tw_reuse允許內(nèi)核在安全條件下復(fù)用TIME_WAIT狀態(tài)的連接。如果服務(wù)端程序壓力特別大可以考慮讓客戶端主動關(guān)閉連接盡量把主動關(guān)閉一側(cè)放在連接數(shù)更少的那一端。更徹底的方案是用連接池代替反復(fù)創(chuàng)建短連接從源頭上減少TIME_WAIT的產(chǎn)生。但也要提醒一句tcp_tw_reuse這些參數(shù)需要確認(rèn)內(nèi)核版本與場景是否匹配不是所有環(huán)境都適合照搬。生產(chǎn)環(huán)境改動網(wǎng)絡(luò)內(nèi)核參數(shù)之前務(wù)必先在測試環(huán)境壓測驗證。7.3 TCP粘包與拆包應(yīng)用層協(xié)議設(shè)計的必修課“TCP粘包”是一個在面試和實際開發(fā)里都高頻出現(xiàn)的話題。很多初學(xué)者一聽到粘包就以為TCP協(xié)議本身有毛病會合并數(shù)據(jù)包。實際上TCP面向的是字節(jié)流它在傳輸層并不關(guān)心你一次寫了多少字節(jié)也不會自動幫你劃分消息邊界。如果你連續(xù)發(fā)送了兩次send()數(shù)據(jù)接收方客戶端可能一次性讀到了兩份數(shù)據(jù)合在一起如果一次send()的數(shù)據(jù)太大接收方也可能分成兩次recv()才能讀完。解決粘包問題的核心是在應(yīng)用層自己定義消息邊界。常見方案有三種第一種固定長度。每條消息的字節(jié)數(shù)都相同接收方按固定長度切割。實現(xiàn)最簡單但如果消息內(nèi)容長度參差不齊會浪費(fèi)很多帶寬。第二種分隔符。每條消息末尾加特定分隔符比如\n或者\(yùn)r\n接收方讀到分隔符就認(rèn)為一條消息結(jié)束。HTTP協(xié)議早期就是用空行來分隔頭部和身體。第三種長度字段。消息頭里定義一個固定長度的字段存儲這條消息總的字節(jié)數(shù)接收方先讀取頭再根據(jù)長度讀滿整個消息判定一條消息完整了。這也是工業(yè)界最常用的做法像是很多通信協(xié)議、MQTT的固定頭都用了類似思路。拿嵌入式場景舉例我寫過一套Modbus TCP的采集程序就是采用“4字節(jié)消息頭包含長度消息體”的方案。解析流程是先用recv()讀4字節(jié)消息頭解析出消息體的長度然后循環(huán)調(diào)用recv()直到讀夠長度為止如果一次recv()讀多了把多余的部分緩存起來跟下一輪頭部數(shù)據(jù)拼接后再解析。這樣一個邏輯嚴(yán)密的消息邊界處理流程才算真正把粘包拆包的問題解決了。7.4 一對多通信從modbus到CAN協(xié)議棧的選擇做設(shè)備聯(lián)網(wǎng)的時候經(jīng)常還需要處理現(xiàn)場總線的通信問題比如Modbus TCP和CAN協(xié)議的互聯(lián)。熱詞里提到了CAN協(xié)議棧和CANopen協(xié)議棧這里多聊幾句因為它們跟TCP/IP協(xié)議棧經(jīng)常出現(xiàn)在同一個網(wǎng)關(guān)設(shè)備里。CAN是一個底層總線協(xié)議工作在OSI模型的數(shù)據(jù)鏈路層跟TCP/IP不是一個層級的協(xié)議。你可以用CAN總線來采集現(xiàn)場的傳感器數(shù)據(jù)、控制設(shè)備動作但CAN本身沒有TCP/IP那樣的路由和傳輸層能力通常局限在一個總線網(wǎng)絡(luò)上。如果你的設(shè)備需要把CAN總線的數(shù)據(jù)上報到云端服務(wù)器或者讓兩個CAN網(wǎng)絡(luò)之間跨路由通信就必須在一臺嵌入式網(wǎng)關(guān)設(shè)備上同時管理CAN協(xié)議棧和TCP/IP協(xié)議棧。網(wǎng)關(guān)一邊通過CAN接口采集現(xiàn)場數(shù)據(jù)另一邊用lwIP協(xié)議棧把數(shù)據(jù)通過以太網(wǎng)或者Wi-Fi上傳。那需要移植CANopen協(xié)議棧嗎我的建議是如果項目需要對接標(biāo)準(zhǔn)化的CANopen設(shè)備比如伺服驅(qū)動器、IO模塊、傳感器并且設(shè)備間需要標(biāo)準(zhǔn)化的PDO/SDO通信那就必須移植一套成熟的CANopen協(xié)議棧。常見的開源方案有CANopenNode等。如果只是自己定義簡單的CAN報文格式、自己板子之間互傳數(shù)據(jù)直接用裸CAN收發(fā)即可不需要引入CANopen的復(fù)雜度。最大的誤區(qū)是以為CAN和TCP/IP可以“直接轉(zhuǎn)換”——實際不是。CAN的報文是8字節(jié)的短幀TCP/IP是一次性傳輸大段的數(shù)據(jù)流網(wǎng)關(guān)在做協(xié)議轉(zhuǎn)換時必須自己設(shè)計數(shù)據(jù)映射規(guī)則把哪幾個CAN報文組合成一包TCP消息、按什么周期上報、錯誤怎么處理。這些規(guī)則的合理性直接決定整個系統(tǒng)的實時性和可靠性。8. 寫在最后我的一些實戰(zhàn)體會文章寫到這里TCP/IP協(xié)議棧從設(shè)計思路到分層細(xì)節(jié)、從Socket編程到嵌入式移植、從抓包觀察到問題排查基本都覆蓋到了。最后分享幾點我這些年做網(wǎng)絡(luò)項目總結(jié)出來的體會算是一些題外話第一學(xué)協(xié)議棧千萬不要死記硬背報文格式。我最開始學(xué)的時候把所有TCP頭部的字段背得滾瓜爛熟結(jié)果真到了抓包分析的時候反而對著一個不常見的數(shù)據(jù)包發(fā)懵。報文格式這種東西用的時候打開參考資料看就可以了真正應(yīng)該爛熟于心的是“數(shù)據(jù)是怎么流動的、每一層在做什么判斷”。第二抓包工具一定要常備。Wireshark不光是排查問題的時候才用。平時寫完一段網(wǎng)絡(luò)通信代碼主動抓包看看自己代碼發(fā)出去的數(shù)據(jù)長什么樣和協(xié)議文檔對一下能幫你發(fā)現(xiàn)很多自己不以為意但不能忽略的細(xì)節(jié)問題。我的習(xí)慣是凡是涉及網(wǎng)絡(luò)通信的模塊開發(fā)階段必須至少抓包驗證一次。第三嵌入式做網(wǎng)絡(luò)開發(fā)要把底層環(huán)境的極限參數(shù)摸清楚。在MCU上跑協(xié)議棧和PC上不一樣內(nèi)存不夠你隨時可以加MCU是焊死在板子上的一旦內(nèi)存估錯了整個方案可能就要重做。拿lwIP來說打開哪些功能、關(guān)閉哪些功能、每個緩沖池配多大都要對著RAM的剩余空間精打細(xì)算。第四協(xié)議棧是工具不是目的。很多工程師容易陷入“我要把TCP/IP吃透”的技術(shù)執(zhí)念里反而忘記了自己做項目的真正目標(biāo)是解決業(yè)務(wù)問題。協(xié)議棧的各個協(xié)議就是工具箱里的扳手和螺絲刀今天需要用HTTP就調(diào)HTTP需要MQTT就上MQTT不要為了炫技而使用復(fù)雜方案。不知道你們最近在做什么網(wǎng)絡(luò)相關(guān)的項目遇到過的比較頭疼的問題是什么可以在評論區(qū)聊聊我看到了會盡量回復(fù)。