摘??要: 對嵌入式TCP/IP協(xié)議棧發(fā)展現(xiàn)狀進行了分析,并詳細剖析了嵌入式TCP/IP協(xié)議棧的實現(xiàn)細節(jié)及基于8位微處理器實現(xiàn)的技術思路。

　　關鍵詞: 微處理器? 嵌入式? TCP/IP? 協(xié)議棧

?

1 基于8位微處理器的嵌入式TCP/IP協(xié)議棧的意義

　　隨著Internet的爆炸式增長,TCP/IP已經(jīng)成為通信領域事實上的國際標準。對于嵌入式系統(tǒng)而言,能夠通過自身的嵌入式TCP/IP協(xié)議棧連接Intranet,甚至Internet,將使其具有更好的實用性,且可帶來巨大的經(jīng)濟效益。目前出現(xiàn)了很多依靠通信技術開發(fā)出的十分有用的嵌入式系統(tǒng)應用實例。例如嵌入式系統(tǒng)可以通過低帶寬的無線鏈路傳輸電度表讀數(shù)。采用全球定位系統(tǒng)GPS技術和無線鏈路的嵌入式系統(tǒng)可以用于確定在國內(nèi)任何地方行駛的車輛的準確位置、速度、油壓和其他參數(shù)。

　　傳統(tǒng)TCP/IP協(xié)議棧(包括桌面PC和服務器中的TCP/IP協(xié)議棧以及一般的基于32位的嵌入式TCP/IP協(xié)議棧等)的實現(xiàn)需要大量的存儲器資源。這是由于這些實現(xiàn)的代碼量偏大,且運行時也要耗用大量內(nèi)存。因此,存儲資源有限的8位系統(tǒng)無法滿足這種需求。現(xiàn)場智能化儀表多采用8位微處理器,如果能夠在低端8位微處理器上實現(xiàn)連網(wǎng)的功能,其經(jīng)濟效益將非?？捎^,應用前景極其廣闊。

2 嵌入式TCP/IP協(xié)議棧發(fā)展現(xiàn)狀

　　目前已存在的TCP/IP協(xié)議棧大致分為2類:(1)沿用了BSD TCP/IP協(xié)議棧的實現(xiàn)思路。(2)完全與BSD TCP/IP協(xié)議棧無關的實現(xiàn)。

　　由于BSD協(xié)議棧最初是針對工作站設計的,而并非是針對嵌入式設備設計的,因此,沿用BSD TCP/IP協(xié)議棧實現(xiàn)思路的嵌入式TCP/IP協(xié)議棧(如InterNiche NicheStack)通常都比較復雜,且代碼較多,所以一般都在32位微處理器上實現(xiàn)。

　　另一類完全與BSD TCP/IP協(xié)議棧無關的實現(xiàn)通常都對通信環(huán)境做了某些假設,從而可以使用簡化的模型來實現(xiàn)TCP/IP協(xié)議棧,如PIC micro stack。通常假設嵌入式TCP/IP協(xié)議棧只與那些具有完整標準的TCP/IP協(xié)議棧的系統(tǒng)進行通信,即簡化的TCP/IP模型可以通過遠端完整的標準TCP/IP協(xié)議棧進行通信。但是,如果遠端也是一個簡化的嵌入式TCP/IP協(xié)議棧,通信就有可能失敗。這類TCP/IP協(xié)議棧一般都定位在16位甚至8位微處理器上實現(xiàn)。

　　TCP/IP模型通?？梢葬槍δ硞€具體的應用進行簡化。以Web服務器應用為例,由于Web服務器不使用TCP/IP協(xié)議棧的緊急數(shù)據(jù)功能,也不需要維持活動連接(在HTTP協(xié)議中定義的),因此針對Web服務器應用開發(fā)嵌入式TCP/IP協(xié)議棧時,前述功能不需要實現(xiàn)。

3?嵌入式TCP/IP協(xié)議棧的技術剖析

　　嵌入式TCP/IP協(xié)議棧通常都包括IP、ICMP、TCP和UDP等幾個協(xié)議。下面分別針對這幾個協(xié)議進行相關技術剖析并探討其基于8位微處理器實現(xiàn)的技術思路。

3.1 IP協(xié)議

　　從網(wǎng)絡接口層進來的數(shù)據(jù)包,首先將被網(wǎng)絡層的IP協(xié)議處理。IP協(xié)議對數(shù)據(jù)包進行一些簡單的檢查,如數(shù)據(jù)包的目的IP地址是不是本地IP地址,同時校驗數(shù)據(jù)包。由于8位嵌入式TCP/IP協(xié)議棧幾乎不需要使用IP選項,因此對于接收到的數(shù)據(jù)包中的IP選項,可以忽略不處理。

　　對于IP協(xié)議中的分段重組功能,可以使用單獨的緩沖區(qū)來實現(xiàn)。當一個分段被接收后,將被拷貝到緩沖區(qū)中的相應位置,同時使用位圖來跟蹤指示哪些分段已成功接收。根據(jù)IP協(xié)議可知,一個分段的第一個字節(jié)在緩沖區(qū)的位置必然是8的倍數(shù),也就是按8字節(jié)進行對齊,因此,位圖只占用很少的內(nèi)存。當所有分段被正確接收后,重組好的分組將被傳送給TCP協(xié)議層進行處理。通常8位嵌入式TCP/IP協(xié)議棧傳輸?shù)膯蝹€分段的數(shù)據(jù)量都比較小。如果在某些具體應用或者某些具體環(huán)境中能確保8位嵌入式TCP/IP協(xié)議棧接收到的分組不存在分片的分段,則可以忽略實現(xiàn)IP協(xié)議的分段重組功能。

　　IP協(xié)議有組播和廣播的功能,因此IP分組的目的地址可以是組播地址或者廣播地址。IP廣播在許多基于UDP協(xié)議的應用中經(jīng)常被使用,如Microsoft Windows File-Sharing SMB協(xié)議。IP組播多用于多媒體的發(fā)布,如RTP。如果要使協(xié)議棧支持基于UDP協(xié)議的應用,則除了要實現(xiàn)UDP協(xié)議外,通常還應該實現(xiàn)IP廣播和組播功能。

3.2 ICMP協(xié)議

　　ICMP主要用來進行網(wǎng)絡故障診斷,如常用的Ping程序就是利用ICMP協(xié)議的回應機制(Echo)來測試網(wǎng)絡的連通性。在8位嵌入式協(xié)議棧中,一般應該實現(xiàn)ICMP協(xié)議的回應機制,而其他功能則可以忽略。

　　ICMP的回應機制就是對接收到的回應請求消息(Echo Request)返回一個回應應答消息(Echo Reply)。因此實現(xiàn)起來很簡單,只需要將接收到的回應請求消息中分組的源端IP和目的端IP交換一下,然后將該分組的ICMP頭部設置為ICMP回應應答消息類型,最后按標準方法計算ICMP校驗和即可。

3.3 TCP協(xié)議

　　由于TCP協(xié)議包含超時重發(fā)機制,因此其實現(xiàn)需要一個定時器。接收到的分組經(jīng)過IP協(xié)議層處理后,就可交給TCP協(xié)議層處理,具體來說就是調(diào)用TCP協(xié)議實現(xiàn)的接口函數(shù)。如果分組中除了TCP頭部外,還包含應用數(shù)據(jù),則TCP協(xié)議將把該數(shù)據(jù)傳給某個具體的應用層協(xié)議做進一步處理;如果分組只是確認前一次數(shù)據(jù)的成功發(fā)送,則更新連接狀態(tài)信息(Connection State),并且通知某個具體的應用層協(xié)議可以發(fā)送新數(shù)據(jù)。

　　TCP允許半打開的連接(Half-Open Connection),即該半打開的連接正對連接請求進行監(jiān)聽。在實現(xiàn)中,可以使用鏈表來組織所有正監(jiān)聽的連接,且可以使用16位的端口號來惟一標識每個正監(jiān)聽的連接。當一個連接請求到來時,根據(jù)連接請求指定的端口號,查找該鏈表。同時該鏈表隨著應用層程序的運行,可以動態(tài)調(diào)整。

????當發(fā)送數(shù)據(jù)時,應用層程序必須檢查TCP協(xié)議的發(fā)送窗口的大小,并根據(jù)其大小來調(diào)整本次發(fā)送的字節(jié)數(shù)。發(fā)送窗口大小取決于可用內(nèi)存的大小和數(shù)據(jù)接收者聲明的窗口大小。在發(fā)送數(shù)據(jù)時,先要用緩沖空間來緩沖需要發(fā)送的數(shù)據(jù)。如果緩沖空間不可使用,則必須等待直到緩沖空間可用為止。當從接收者接收到確認信息后,緩沖空間變?yōu)榭捎?。當緩沖空間可用時,將通知應用程序可以發(fā)送數(shù)據(jù)了。

　　大多數(shù)TCP協(xié)議的實現(xiàn)中都使用滑動窗口機制來發(fā)送數(shù)據(jù)。通過滑動窗口機制,多個數(shù)據(jù)段可以連續(xù)同時發(fā)送。如果不使用滑動窗口機制,則需要在每次發(fā)送完一個數(shù)據(jù)段后等待確認信息,當接收到確認后才能發(fā)送下一個數(shù)據(jù)段。在基于8位微處理器的協(xié)議棧中,不推薦使用滑動窗口機制。這是由于滑動窗口算法需要使用許多32位操作數(shù),而在許多8位微處理器上32位的操作效率非常低下。而且滑動窗口機制需要較多的緩沖空間來緩沖多個要發(fā)送的數(shù)據(jù)段,這對內(nèi)存資源有限的8位微處理器來說比較浪費。此外,滑動窗口機制并不是TCP協(xié)議必需的,沒有滑動窗口機制,完全不會影響網(wǎng)絡的互聯(lián),只是發(fā)送效率比較低而已。

　　為了得到合理的重發(fā)時延,TCP需要持續(xù)對該活動連接進行回旋時間(Round-Trip Time,RTT)的評估。在TCP協(xié)議中,可以通過定時器來評估RTT。具體方法是:每個活動連接維護一個計數(shù)器;每當定時器觸發(fā)時,對每個剛發(fā)送了數(shù)據(jù),且當前還沒有接收到確認信息的活動連接計數(shù)器加1;當收到確認信息后,該連接計數(shù)器的當前值就作為RTT樣例值,結合標準的RTT評估函數(shù)就可以得到RTT的評估值,最后將該連接的計數(shù)器清零。

　　TCP重發(fā)機制的實現(xiàn)依賴于定時器。每個活動連接維護一個重發(fā)時延值,該值取決于RTT。當定時器觸發(fā)時,每個剛發(fā)送了數(shù)據(jù)且當前還沒有接收到確認信息的活動連接的重發(fā)時延值減1,當重發(fā)時延值減為0時,該連接重發(fā)前一次發(fā)送的數(shù)據(jù)。數(shù)據(jù)重新發(fā)送完后,重發(fā)時延值設為初始值。重發(fā)數(shù)據(jù)的來源有2種方式:(1)緩沖區(qū),即當數(shù)據(jù)發(fā)送完后,先放到緩沖區(qū)中,直到收到確認信息后才將該數(shù)據(jù)從緩沖區(qū)中刪除。(2)不對發(fā)送的數(shù)據(jù)進行緩沖,當重發(fā)時,通知應用程序重新獲得前一次發(fā)送的數(shù)據(jù)。

　　TCP流量控制機制的目的在于使性能和內(nèi)存大小具有較大差異的主機間能夠進行通信。每一個TCP數(shù)據(jù)段中指定了發(fā)送者可用的緩沖空間的大小。發(fā)送者發(fā)送的數(shù)據(jù)不應該大于接收者指定的緩沖空間大小。如果接收者已不能接收數(shù)據(jù),則指定可用的緩沖空間大小為0。

　　TCP擁塞控制機制限制了網(wǎng)絡中并發(fā)的TCP數(shù)據(jù)段的數(shù)目。擁塞控制算法非常容易實現(xiàn),只需少量的代碼。如果協(xié)議棧沒有實現(xiàn)滑動窗口機制,則每個活動連接只能一次發(fā)送一個TCP數(shù)據(jù)段。這樣,網(wǎng)絡中并發(fā)的TCP數(shù)據(jù)段就得到了控制,從而可以忽略擁塞控制機制的實現(xiàn)。

　　TCP緊急數(shù)據(jù)機制提供了應用到應用的通知機制。應用程序可以使用該機制使某些數(shù)據(jù)流比正常的數(shù)據(jù)流更快地發(fā)送出去。緊急數(shù)據(jù)的含義由接收應用程序負責解釋。如果要實現(xiàn)緊急數(shù)據(jù)機制,則會大大增加協(xié)議棧的復雜度。因此在基于8位微處理器的嵌入式協(xié)議棧中,一般都忽略該機制。

　　每個TCP連接都需要一定的狀態(tài)信息。由于這些狀態(tài)信息必然要占用內(nèi)存,因此在實現(xiàn)時應該最小化TCP連接所需要的狀態(tài)信息。如果實現(xiàn)TCP滑動窗口機制,則會大大增加TCP連接所需要的狀態(tài)信息?；瑒哟翱跈C制需要每個TCP連接都必須保存一些32位序號信息,而且如果要支持宿主機(一個主機有多個IP地址),則每個連接還要保存更多的信息。因此,對于基于8位微處理器的嵌入式協(xié)議棧而言,必須忽略一些機制。

3.4 UDP協(xié)議

　　與TCP協(xié)議相比,UDP協(xié)議非常簡單。UDP主要應用于不同的進程之間鏈路的多路復用。它沒有復雜的機制,只需要按照協(xié)議標準實現(xiàn)。

4? 結束語

　　一個實用的基于8位微處理器的嵌入式協(xié)議棧首先要保證能和其他協(xié)議棧正確通信,這既包含完整的協(xié)議棧,也包括同樣是基于8位微處理器的嵌入式協(xié)議棧。其次要合理、高效地使用資源,尤其是存儲資源。此外,還要求代碼簡潔高效。

?

參考文獻

1 Tanenbaum A S著,熊桂喜,王小虎譯.計算機網(wǎng)絡.北京:清華大學出版社,1998

2 Comer D E,Stevens D L著,趙剛,林瑤,蔣慧譯.用TCP/IP進行網(wǎng)際互連(第2版).北京:電子工業(yè)出版社,1998

3?劉磅.TCP/IP Ethernet—自控設備的新選擇.http://www.gongkong.com,2003

4 劉磅.現(xiàn)場級TCP/IP控制器及其實踐.http://www.gongkong.com,2003