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

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

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

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

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

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

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

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

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

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

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

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