Simplified TCP/IP協(xié)議棧的特點及應(yīng)用研究

1引言

嵌入式Internet是近幾年隨著嵌入式系統(tǒng)的廣泛應(yīng)用和計算機(jī)網(wǎng)絡(luò)技術(shù)的發(fā)展而興起的一項新興概念和技術(shù)。單片機(jī)或微控制器（MCU，Micro ControllerUnit）被廣泛應(yīng)用在家庭和工業(yè)的各個領(lǐng)域，通稱嵌入式系統(tǒng)。嵌入式系統(tǒng)具有以應(yīng)用為中心、以計算機(jī)技術(shù)為基礎(chǔ)、軟件硬件可裁剪等特點，贏得了巨大的市場，在應(yīng)用數(shù)量上遠(yuǎn)遠(yuǎn)超過了各種通用計算機(jī)。隨著Internet/Intranet的發(fā)展，各種家用電器，從空調(diào)到微波爐，都產(chǎn)生了連入互聯(lián)網(wǎng)的要求。

如何通過Internet共享嵌入式設(shè)備的信息，實現(xiàn)設(shè)備的遠(yuǎn)程訪問、控制和管理，對接入到網(wǎng)絡(luò)上各個節(jié)點的設(shè)備實時監(jiān)控，這就是設(shè)備接入互聯(lián)網(wǎng)需要解決的問題。TCP/IP協(xié)議是標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議，如果能把TCP/IP協(xié)議嵌入到設(shè)備的MCU中，就可以通過它在設(shè)備和Internet之間建立通信鏈路，這樣就解決了設(shè)備與網(wǎng)絡(luò)互聯(lián)的關(guān)鍵技術(shù)。

2Simplified TCP/IP協(xié)議棧的特點

和嵌入式系統(tǒng)面向特定的應(yīng)用一樣，分析嵌入式TCP/IP協(xié)議棧的特點和對傳統(tǒng)的TCP/IP協(xié)議棧進(jìn)行簡化也要針對特定的系統(tǒng)環(huán)境和應(yīng)用

背景。離開了特定的系統(tǒng)環(huán)境和應(yīng)用背景來討論嵌入式TCP/IP協(xié)議棧的特點和對TCP/IP協(xié)議棧進(jìn)行簡化是沒有意義的。這里所討論的嵌入式TCP/IP協(xié)議棧是針對那些低檔的8位/16位嵌入式系統(tǒng)能支持嵌入式Internet直連體系結(jié)構(gòu)而提出的。

嵌入式系統(tǒng)有限的處理能力以及存儲資源相對缺乏，因此在嵌入式Internet環(huán)境里使用標(biāo)準(zhǔn)TCP/IP協(xié)議棧是不合適的。把TCP/IP協(xié)議棧從普通的PC機(jī)移植到MCU，內(nèi)存和內(nèi)存管理成了瓶頸。為了既實現(xiàn)相應(yīng)的網(wǎng)絡(luò)功能又節(jié)省系統(tǒng)資源，需要對協(xié)議棧進(jìn)行有針對的模塊化裁減。針對家電系統(tǒng)中的8位/16位MCU結(jié)構(gòu)設(shè)計了一個TCP/IP協(xié)議簇的子集，稱之為Simplified TCP/IP協(xié)議棧。其中包括IP、UDP、ARP和ICMP等協(xié)議的全部或部分功能，對協(xié)議進(jìn)行了有選擇的實現(xiàn)，盡最大可能保持協(xié)議功能和機(jī)制上的完整。

Simplified TCP/IP協(xié)議棧按照網(wǎng)絡(luò)體系分層思想設(shè)計，如圖1所示。其中每一層都被設(shè)計成一個功能相對獨立的模塊，負(fù)責(zé)處理各自的數(shù)據(jù)，通過函數(shù)調(diào)用把控制權(quán)交給上層或下層的模塊。

低檔嵌入式系統(tǒng)中一般沒有實時多任務(wù)操作系統(tǒng)支持，所以Simplified TCP/IP協(xié)議棧直接面對硬件。MCU中的程序結(jié)構(gòu)一般是順序執(zhí)行和硬件中斷相配合的方式。嵌入式處理器的時鐘頻率低，地址、數(shù)據(jù)總線窄，所以一個IP包的處理要花很多的時間。如果采用中斷處理方式，勢必影響其他中斷和任務(wù)的執(zhí)行。當(dāng)系統(tǒng)中有實時數(shù)據(jù)采集、串口通信中斷、鍵盤中斷等實時任務(wù)時，則會造成沖突。設(shè)計時需要合理劃分中斷處理程序，將無實時要求和費時的SimplifiedTCP/IP協(xié)議棧處理放在主程序順序循環(huán)中。對網(wǎng)絡(luò)接口控制芯片采用查詢式，即在其他中斷任務(wù)的執(zhí)行間隙處理Simplified TCP/IP協(xié)議棧，以犧牲響應(yīng)速度換取系統(tǒng)可靠性，如圖2所示。

3TCP/IP協(xié)議棧的裁減

普通操作系統(tǒng)可支持完整的TCP/IP協(xié)議族，但嵌入式系統(tǒng)中大多很難做到，也不需做到。嵌入式系統(tǒng)中實現(xiàn)的協(xié)議要根據(jù)各個系統(tǒng)的特點及功能來進(jìn)行設(shè)計。TCP/IP協(xié)議族中，只實現(xiàn)與實際需要有關(guān)的部分，而不使用的協(xié)議則一概不支持。Simplified TCP/IP協(xié)議棧中支持的協(xié)議。

3. 1地址轉(zhuǎn)換協(xié)議—ARP協(xié)議

ARP協(xié)議是某些網(wǎng)絡(luò)接口（如以太網(wǎng)和令牌環(huán)網(wǎng)）使用的特殊協(xié)議，ARP的地址解析功能是為IP地址和數(shù)據(jù)鏈路層使用的硬件地址提供動態(tài)地址映射。通用計算機(jī)系統(tǒng)中，ARP高速緩存一般設(shè)計成雙向數(shù)據(jù)鏈的形式，這樣整個緩存可以方便地動態(tài)增減。但是這種非線性存儲的鏈表式緩存結(jié)構(gòu)，在進(jìn)行表項匹配查找時比較費時，不適用于嵌入式系統(tǒng)。因此ARP的地址緩存采用了線性數(shù)組形式的結(jié)構(gòu)。它在內(nèi)存中是連續(xù)線性存儲的，查找速度快。嵌入式應(yīng)用中節(jié)點不是很多，即ARP緩存容量不需要很大，因此將ARP高速緩存設(shè)計成固定大小。被動的嵌入式服務(wù)器主要是接收來自客戶的服務(wù)請求，為客戶提供服務(wù)，即嵌入式服務(wù)器不會主動向某一主機(jī)發(fā)數(shù)據(jù)幀。既然如此始終處于被動狀態(tài)的服務(wù)器完全不需要向任何主機(jī)發(fā)送ARP請求，設(shè)備只要能處理ARP請求并返回ARP應(yīng)答即可。鑒于這種情況，ARP協(xié)議中選擇對ARP應(yīng)答部分進(jìn)行實現(xiàn)。

3. 2網(wǎng)際協(xié)議—IP協(xié)議

IP協(xié)議是TCP/IP協(xié)議簇中最為核心的協(xié)議，提供不可靠的無連接的數(shù)據(jù)報傳送服務(wù)。所有的TCP、UDP和ICMP數(shù)據(jù)都以IP數(shù)據(jù)報的格式傳輸。IP協(xié)議非常重要，實現(xiàn)比較復(fù)雜。從實現(xiàn)Simplified TCP/IP協(xié)議棧的要求出發(fā)，約簡IP協(xié)議需要把握兩個原則：①對接收到的IP數(shù)據(jù)報進(jìn)行處理，向上層協(xié)議進(jìn)行提交;②負(fù)責(zé)對UDP報文進(jìn)行封裝，交給數(shù)據(jù)鏈路層進(jìn)行裝幀。當(dāng)設(shè)備收到發(fā)給自己的數(shù)據(jù)報時，首先判斷是否是自己的數(shù)據(jù)報，若不一致則丟棄該數(shù)據(jù)報;否則進(jìn)行IP校驗和的驗證，當(dāng)數(shù)據(jù)報無誤后，去掉IP頭部，將IP數(shù)據(jù)提交上層處理。

一般情況下，數(shù)據(jù)包要經(jīng)過不同的物理網(wǎng)絡(luò)，則IP層必須支持?jǐn)?shù)據(jù)包的分片和重裝。但I(xiàn)P的分片和重組所需的開銷比較大，而現(xiàn)有的網(wǎng)絡(luò)一般都支持以太網(wǎng)，并且在此次應(yīng)用的8/16位嵌入式系統(tǒng)中，傳輸?shù)臄?shù)據(jù)都是一些數(shù)據(jù)量比較小的狀態(tài)信息或者控制信息。因此數(shù)據(jù)報都不會超過協(xié)議所限制的1500字節(jié)。如果極少數(shù)數(shù)據(jù)實在比較大，可以在程序中進(jìn)行處理，分批次進(jìn)行傳輸。因此可以裁減掉IP的分片和重組功能。而IP數(shù)據(jù)包的路由功能則交給默認(rèn)網(wǎng)關(guān)執(zhí)行。

3. 3網(wǎng)際控制報文協(xié)議———ICMP協(xié)議

ICMP協(xié)議是IP網(wǎng)絡(luò)內(nèi)為控制、測試、管理功能而設(shè)計的協(xié)議。ICMP的報文類型很多，不同類型的報文由類型和代碼字段共同決定。為了了解設(shè)備是否可達(dá)， Simplified TCP/IP協(xié)議棧中主要實現(xiàn)了回顯請求和應(yīng)答報文的功能。該程序發(fā)送ICMP回顯請求報文給目的主機(jī)，并等待ICMP回顯應(yīng)答。對于處于被動狀態(tài)設(shè)備而言，不需要主動發(fā)送回顯請求，只要能夠識別來自其他客戶的回顯請求并發(fā)送回顯應(yīng)答就可以了。為了能夠使用戶了解設(shè)備是否可達(dá)，應(yīng)當(dāng)能夠?qū)?a href="http://www.ttokpm.com/tags/pi/" target="_blank">Ping的回顯請求給予應(yīng)答。

3. 4用戶數(shù)據(jù)報協(xié)議—UDP協(xié)議

Simplified TCP/IP協(xié)議棧中的傳輸層中，選用UDP作為傳輸層協(xié)議。從理論上看，TCP的可靠性是以許多復(fù)雜措施及由此而增加的開銷為代價換來的。TCP提供面向鏈接的、可靠的服務(wù)，而UDP是無面向鏈接的。由于UDP沒有可靠性的保證機(jī)制，因此能全速地進(jìn)行數(shù)據(jù)通信（即充分發(fā)揮物理通信設(shè)備的速度）;又因為UDP沒有點對點接入的要求，可以實現(xiàn)“一對多點”，“多對多點”的廣播和多點播發(fā)信息。UDP的不可靠傳輸?shù)娜毕?，可以在使用UDP時，在應(yīng)用層增加提高UDP可靠性的代碼來彌補(bǔ)。譬如給數(shù)據(jù)添加順序標(biāo)記，因而能在應(yīng)用層發(fā)現(xiàn)數(shù)據(jù)的丟失和亂序，從而加以更正;采用應(yīng)答確認(rèn)機(jī)制，確保數(shù)據(jù)安全到達(dá)接收者等。

由于嵌入式系統(tǒng)的CPU速度有限、代碼不能太長、傳輸率是關(guān)鍵等特殊要求，一般來講，在嵌入式設(shè)備接口時，快速、簡單地與嵌入式設(shè)備進(jìn)行雙向數(shù)據(jù)傳輸是首為重要的。所以減少和嵌入式設(shè)備之間的往返信息，使網(wǎng)絡(luò)成為一種更為高效的通信媒介將是嵌入式網(wǎng)絡(luò)協(xié)議設(shè)計的必由之路。而UDP協(xié)議的開銷很小，傳輸率比TCP高出很多，實時性更強(qiáng)。所以嵌入式TCP/IP協(xié)議中采用UDP協(xié)議作為運輸層協(xié)議，不失為明智之舉。嵌入式系統(tǒng)中也可能存在對數(shù)據(jù)傳輸可靠性要求很高的情況。由于UDP協(xié)議沒有計時機(jī)制、流量控制或擁塞管理機(jī)制、應(yīng)答、緊急數(shù)據(jù)的加速傳送等功能，因此在應(yīng)用層協(xié)議中加入相應(yīng)的措施，如給數(shù)據(jù)報加上順序標(biāo)識、定時等待、采用重傳機(jī)制等輔助性的操作來彌補(bǔ)它的缺陷。從應(yīng)用的角度看， Simplified TCP/IP協(xié)議棧主要是應(yīng)用于家用電器上網(wǎng)。對于溫度、煙霧和濕度傳感器等的每秒一次地集中監(jiān)控來說，發(fā)送頻繁，包較小，只需前端設(shè)備向網(wǎng)絡(luò)中廣播實時狀態(tài)等數(shù)據(jù)即可，因此選用UDP較為合適。

4Simplified TCP/IP協(xié)議棧處理流程

Simplified TCP/IP協(xié)議棧接收數(shù)據(jù)包的過程就是解析數(shù)據(jù)包的過程。首先當(dāng)一個數(shù)據(jù)幀到達(dá)時，網(wǎng)絡(luò)接口控制程序?qū)⑵渥x入緩沖區(qū)，檢查協(xié)議類型字段，如值依次為0x0800，表示數(shù)據(jù)域內(nèi)為IP包;值依次為0x0806，表示數(shù)據(jù)域內(nèi)為ARP包。由此以確定使用那種協(xié)議模塊來處理此分組。去掉以太網(wǎng)幀首部的數(shù)據(jù)包將被分配到IP緩存或者ARP緩存。接著，由IP協(xié)議處理模塊或ARP協(xié)議處理模塊繼續(xù)解析。ARP根據(jù)包的類型，或者更新ARP地址映射表或者發(fā)送ARP應(yīng)答。IP協(xié)議處理模塊對數(shù)據(jù)包解析后，將數(shù)據(jù)交給UDP協(xié)議處理模塊或ICMP協(xié)議處理模塊。ICMP協(xié)議模塊會發(fā)回一個ICMP回顯應(yīng)答包。Simplified TCP/IP協(xié)議棧發(fā)送數(shù)據(jù)包的過程是封裝數(shù)據(jù)包的過程，數(shù)據(jù)經(jīng)過某層協(xié)議的處理，就會在數(shù)據(jù)包首部增加某種格式的頭部。在IP協(xié)議模塊處理數(shù)據(jù)包的過程，它要通過調(diào)用ARP協(xié)議獲得對方主機(jī)的物理地址。

Simplified TCP/IP協(xié)議棧處理流程如圖3所示。

圖3Simplified TCP/IP協(xié)議棧處理流程圖

5總結(jié)與展望

為了驗證方案的可行性，實驗中以簡單圖像的傳輸為研究對象，檢驗Simplified TCP/IP協(xié)議棧的運行效果。從測試結(jié)果可看出，大流量的圖像傳輸系統(tǒng)中發(fā)生數(shù)據(jù)報的幾率還是比較大的。當(dāng)然，如果是應(yīng)用在數(shù)據(jù)流量不是很大，僅有一些少量數(shù)據(jù)和簡單的控制指令或反饋信息的應(yīng)用系統(tǒng)中，運行的情況會更好一些。

目前Simplified TCP/IP協(xié)議棧技術(shù)還有一些不完善的地方。比如在數(shù)據(jù)量大的網(wǎng)絡(luò)中減小數(shù)據(jù)報的丟失率，更有效的進(jìn)行擁塞控制等，這些都是今后的努力方向。另外，還需要進(jìn)一步優(yōu)化代碼，提高SimplifiedTCP/IP協(xié)議棧的性能。

責(zé)任編輯：gt