基于嵌入式網(wǎng)絡(luò)接口的精簡TCPIP協(xié)議棧的設(shè)計及實現(xiàn)

1、基于嵌入式網(wǎng)絡(luò)接口的TCPIP協(xié)議棧的設(shè)計及實現(xiàn)摘要：根據(jù)嵌入式系統(tǒng)及其接入網(wǎng)絡(luò)的特點，對標(biāo)準(zhǔn)TCPIP協(xié)議棧進(jìn)行裁減，設(shè)計了一種適用于8位微控制系統(tǒng)的嵌入式TCPIP協(xié)議棧。將其移植到UCOSII上并與現(xiàn)有協(xié)議棧uIP進(jìn)行對比測試。證明了其實用性。關(guān)鍵詞：TCP/IP協(xié)議棧 嵌入式網(wǎng)絡(luò)接口 UCOSII uIP引言網(wǎng)絡(luò)化是現(xiàn)代電子設(shè)備普遍的特點，嵌入式系統(tǒng)也不例外。使嵌入式設(shè)備接入網(wǎng)絡(luò)，擴(kuò)寬了設(shè)備的通信范圍，也使操作者更加便于操控設(shè)備。但是，嵌入式系統(tǒng)具有處理能力有限、存儲資源少、應(yīng)用場合單一等特點，標(biāo)準(zhǔn)的TCP/IP協(xié)議棧顯然不能直接運用于8位的微控制系統(tǒng)中。本文量體裁衣，設(shè)計一種精簡的T

2、CP/IP協(xié)議棧，主要包括ARP、ICMP、IP、UDP等協(xié)議。本協(xié)議棧的測試平臺配置如下：STC12C5A60S2單片機(jī)、62256外部RAM存儲器、RTL8019AS網(wǎng)絡(luò)芯片、12M晶振。此協(xié)議?？煞奖愕匾浦驳角度胧綄崟r操作系統(tǒng)UCOSII上，作為其一個任務(wù)，控制網(wǎng)絡(luò)數(shù)據(jù)的收發(fā)。1 TCP/IP協(xié)議的設(shè)計圖1 TCP/IP分層模型一些常用協(xié)議在TCPIP分層模型中所處的位置如圖1所示。根據(jù)TCPIP協(xié)議分層的特點，在編寫代碼的過程中，可以圍繞三個特點來設(shè)計：第一，由于協(xié)議棧每層都由頭部和數(shù)據(jù)部分組成，而頭部又由多個項組成，所以應(yīng)將各層頭部封裝成為結(jié)構(gòu)體形式。第二，當(dāng)網(wǎng)絡(luò)接口收到數(shù)據(jù)時，需要

3、向上層傳遞或者在本層處理，這就需要判斷數(shù)據(jù)包的類型。比如，當(dāng)硬件接口收到數(shù)據(jù)時，需要對數(shù)據(jù)包類型進(jìn)行判斷，如果是IP包，則向上傳遞給IP層，如果是ARP包則調(diào)用處理ARP包的函數(shù)。第三，當(dāng)網(wǎng)絡(luò)接口發(fā)送數(shù)據(jù)時，數(shù)據(jù)從協(xié)議棧上層到下層，層層封裝，最后由硬件接口發(fā)送。這就需要有對每層進(jìn)行封裝的函數(shù)。最后剩下的是數(shù)據(jù)的解封裝和網(wǎng)絡(luò)芯片驅(qū)動程序，數(shù)據(jù)的解封裝相對簡單，可在一個統(tǒng)一的函數(shù)中完成，而網(wǎng)絡(luò)芯片驅(qū)動程序根據(jù)使用的芯片類型設(shè)計初始化、發(fā)送、接收數(shù)據(jù)三個函數(shù)即可。1.1 ARP協(xié)議在以太網(wǎng)中，一個主機(jī)要和另一個主機(jī)進(jìn)行直接通信，除了要知道對方的IP地址外，還必須要知道目標(biāo)主機(jī)的MAC地址。它就是通過

4、地址解析協(xié)議獲得的1。在通用計算機(jī)系統(tǒng)中，ARP高速緩存一般設(shè)計成雙向數(shù)據(jù)鏈的形式，這樣整個緩存便可動態(tài)增減。但是在這種非線性的鏈表進(jìn)行表項匹配查找時比較費時，所以這種形式并不適用于嵌入式系統(tǒng)。因此 ARP的地址緩存采用了線性數(shù)組的形式，它在內(nèi)存中是連續(xù)線性存儲的，查找速度快。由于嵌入式網(wǎng)絡(luò)接口的通信節(jié)點一般不多，其ARP高速緩存容量不需要很大，因此可將其高速緩存設(shè)計成固定大小。ARP協(xié)議主要實現(xiàn)的結(jié)構(gòu)體和函數(shù)為：ARP頭部結(jié)構(gòu)體ARPHDR、判斷是否為ARP包的函數(shù)is_arp()、對ARP數(shù)據(jù)進(jìn)行封裝的函數(shù)make_arp()。1.2 IP協(xié)議IP協(xié)議是TCP/IP協(xié)議簇中最為核心的協(xié)議，

5、提供不可靠的無連接的數(shù)據(jù)報傳送服務(wù)。TCP、UDP、ICMP等上層協(xié)議的數(shù)據(jù)包都要以IP數(shù)據(jù)報的格式傳輸。標(biāo)準(zhǔn)的IP協(xié)議包括分段和重組等功能，實現(xiàn)起來比較復(fù)雜。在嵌入式控制系統(tǒng)中，數(shù)據(jù)大都是少量而獨立的，所以實現(xiàn)分段和重組不是必須的。本協(xié)議棧從兩個方面對IP協(xié)議進(jìn)行簡化：第一，對接收到的IP數(shù)據(jù)報首先判斷是否是自己的數(shù)據(jù)報，若不一致則丟棄該數(shù)據(jù)報；否則進(jìn)行IP校驗和的驗證，當(dāng)數(shù)據(jù)報無誤后，去掉頭部，將IP數(shù)據(jù)提交上層處理。第二，負(fù)責(zé)對UDP、ICMP等報文進(jìn)行封裝，交給數(shù)據(jù)鏈路層進(jìn)行裝幀。IP協(xié)議主要實現(xiàn)的結(jié)構(gòu)體和函數(shù)為：IP頭部結(jié)構(gòu)體IPHDR、判斷是否為IP數(shù)據(jù)報的函數(shù)is_ip()、對上

6、層數(shù)據(jù)進(jìn)行IP數(shù)據(jù)報封裝的函數(shù)make_ip()。1.3 ICMP協(xié)議ICMP協(xié)議是IP網(wǎng)絡(luò)內(nèi)為控制、測試、管理功能而設(shè)計的協(xié)議。ICMP的報文類型很多， 不同類型的報文由類型和代碼字段共同決定。在嵌入式系統(tǒng)中，控制管理等功能并不是必須的，為了能夠使用戶了解設(shè)備是否可達(dá)，只要能夠識別來自其他客戶的回顯請求并發(fā)送回顯應(yīng)答就可以了。ICMP協(xié)議主要實現(xiàn)的結(jié)構(gòu)體和函數(shù)為：ICMP頭部結(jié)構(gòu)體ICMPHDR、判斷是否為ICMP數(shù)據(jù)報的函數(shù)is_icmp()、對ICMP數(shù)據(jù)進(jìn)行封裝的函數(shù)make_icmp()。1.4 UDP協(xié)議本協(xié)議棧采用UDP作為傳輸層協(xié)議。從理論上看，TCP的可靠性是以許多復(fù)雜措施及

7、由此而增加的開銷為代價換來的。TCP提供面向鏈接的、可靠的服務(wù)，而UDP是面向無連接的。由于UDP沒有可靠性的保證機(jī)制，因此能夠充分發(fā)揮物理通信設(shè)備的速度，全速地進(jìn)行數(shù)據(jù)通信。又因為UDP沒有點對點接入的要求，可以實現(xiàn)“一對多”、“多對多”的數(shù)據(jù)傳輸。UDP協(xié)議的開銷很小，傳輸率比TCP高，實時性強(qiáng)。所以嵌入式TCP/IP協(xié)議中采用UDP協(xié)議作為運輸層協(xié)議不失為明智之舉。嵌入式系統(tǒng)中也可能存在對數(shù)據(jù)傳輸可靠性要求很高的情況。由于UDP協(xié)議沒有超時重傳、流量控制、應(yīng)答確認(rèn)、緊急數(shù)據(jù)加速等機(jī)制， 因此為了彌補它的缺陷，在應(yīng)用層協(xié)議中加入相應(yīng)的措施， 如給數(shù)據(jù)報加上順序標(biāo)識、定時等待、超時重傳機(jī)制、

8、應(yīng)答確認(rèn)機(jī)制等輔助性的措施，確保數(shù)據(jù)能夠正確安全地傳輸。從應(yīng)用的角度看，本協(xié)議棧主要是應(yīng)用于家用電器上網(wǎng)。對于溫度、煙霧和濕度傳感器 等的每秒一次地集中監(jiān)控來說，發(fā)送頻繁，包較小，只需前端設(shè)備向網(wǎng)絡(luò)中廣播實時狀態(tài)等數(shù)據(jù)即可，因此選用UDP較為合適。UDP協(xié)議主要實現(xiàn)的結(jié)構(gòu)體和函數(shù)為：UDP頭部結(jié)構(gòu)體UDPHDR、判斷是否為UDP數(shù)據(jù)包的函數(shù)is_udp()、將數(shù)據(jù)封裝成UDP包的函數(shù)make_udp()。2 協(xié)議棧處理流程協(xié)議棧接收數(shù)據(jù)包的過程就是解析數(shù)據(jù)包的過程，處理流程如圖2所示。首先當(dāng)一個數(shù)據(jù)幀到達(dá)時，網(wǎng)絡(luò)接口控制程序?qū)⑵渥x入緩沖區(qū)，并返回其長度。其次，主程序判斷接收數(shù)據(jù)包的類型（IP或

9、ARP包）調(diào)用響應(yīng)的解包代碼進(jìn)行處理。如果是ARP包，則解析ARP包，做更新ARP緩存或回應(yīng)ARP請求等事宜。 若為IP包，則進(jìn)一步判斷數(shù)據(jù)包類型（ICMP或UDP包）調(diào)用相應(yīng)的解包代碼處理。若為ICMP包，判斷是否為ICMP回顯請求，如果是制作回顯包并發(fā)送。如果是UDP包，解析出數(shù)據(jù)交由應(yīng)用層處理。圖2 協(xié)議棧處理流程3 協(xié)議棧的測試及應(yīng)用本協(xié)議?？煞奖愕匾浦驳礁鞣N嵌入式操作系統(tǒng)上，如UCOSII、RT-Thread，作為其一個任務(wù)或者線程，管理網(wǎng)絡(luò)接口數(shù)據(jù)的收發(fā)。下面分兩方面對本協(xié)議進(jìn)行測試并與uIP協(xié)議進(jìn)行對比，測試主機(jī)為連接在局域網(wǎng)上的PC機(jī)。3.1 數(shù)據(jù)發(fā)送接收測試3首先使用ping

10、命令對簡化協(xié)議棧鏈接情況測試，測試情況見圖3所示，其中(a)是不帶系統(tǒng)的協(xié)議棧測試結(jié)果，(b)是協(xié)議棧作為UCOSII一個任務(wù)的測試結(jié)果2，(c)是uIP1.0協(xié)議棧的測試結(jié)果。這3副圖表明本協(xié)議的速度與uIP協(xié)議相差無幾。圖4是進(jìn)行數(shù)據(jù)的發(fā)送接收測試，上方是網(wǎng)絡(luò)嗅探軟件MiniSniffer，左下方是串口調(diào)試助手，右下方是網(wǎng)絡(luò)調(diào)試助手。測試過程如下：串口調(diào)試助手首先發(fā)送0-9的數(shù)字給目的主機(jī)，并將發(fā)送的數(shù)據(jù)顯示在自己的接收發(fā)送緩沖區(qū)域。此時網(wǎng)絡(luò)調(diào)試助手收到0-9的數(shù)據(jù)，并顯示在接收區(qū)域。然后，網(wǎng)絡(luò)調(diào)試助手發(fā)送“hello”到開發(fā)板，經(jīng)過協(xié)議棧處理后，通過串口發(fā)送給PC機(jī)，并顯示在串口調(diào)試助手

11、的發(fā)送接收緩沖區(qū)域。而這兩次網(wǎng)絡(luò)數(shù)據(jù)的發(fā)送接收均被網(wǎng)絡(luò)嗅探軟件記錄，并將數(shù)據(jù)的內(nèi)容顯示出來。這表明本協(xié)議棧能夠正常工作。(a)(b)(c)圖3 簡化協(xié)議棧鏈接情況測試圖4 數(shù)據(jù)接收測試3.2 丟包率測試4接下來，測試協(xié)議棧的可靠性。測試方法如下：每隔1秒、0.1秒和全速發(fā)送一個100字節(jié)的UDP數(shù)據(jù)包，共發(fā)送1000包，測試十次，計算平均丟包率。測試情況如表1所示。由表可知，當(dāng)數(shù)據(jù)發(fā)送速率較低的情況下，幾乎不丟包。但是隨著數(shù)據(jù)發(fā)送速率的增加，丟包的現(xiàn)象越來越嚴(yán)重。然而在嵌入式控制系統(tǒng)中，數(shù)據(jù)隨頻繁發(fā)送但不需要高的速率和大的數(shù)據(jù)量。此外，如果加入上層確認(rèn)機(jī)制或超時重傳等機(jī)制，即使有丟包的情況，數(shù)據(jù)也能夠被安全的被送達(dá)。在全速傳送100字節(jié)UDP數(shù)據(jù)包情況下，數(shù)據(jù)速率可達(dá)14.7K/S。本設(shè)計已實際應(yīng)用于以太網(wǎng)轉(zhuǎn)串口的項目中。結(jié)束語由于本協(xié)議棧設(shè)計思路清晰，代碼簡短(1.7K RAM，7K ROM)，所以很容易修改及移植。本協(xié)議棧探索了如何在嵌入式系統(tǒng)中編寫一個精簡的TCP/IP協(xié)議棧，未深究協(xié)議棧內(nèi)存管理以及操作系統(tǒng)中對協(xié)議棧的影響，仍有需要改進(jìn)和完善的地方。參