周磊

【摘要】本文提出了一種嵌入式協(xié)議棧的設計及實現(xiàn)。功能上簡化到能滿足網絡功能單一的嵌入式應用的基本需要，沒有操作系統(tǒng)平臺也能完成基本功能；對于傳統(tǒng)的TCP協(xié)議，本文也從TCP狀態(tài)機和TCP超時定時兩個方面同時進行了改進設計。本文根據以上提出的的優(yōu)化策略，分別設計了實現(xiàn)算法及其相關數據結構。

【關鍵詞】嵌入式系統(tǒng)，網絡協(xié)議，TCP/IP，狀態(tài)機

1.研究背景及意義

隨著經濟全球化的不斷發(fā)展以及信息社會對數字化要求的不斷提高，國務院確定三網融合政策啟動，互聯(lián)互通的需求使嵌入式應用和其它計算機系統(tǒng)進行信息交互的需求也日益迫切。

要實現(xiàn)嵌入式系統(tǒng)的網絡功能，肯定需要在嵌入式軟件中加入相關的通訊協(xié)議棧組件。但是，這一方案的實現(xiàn)在嵌入式系統(tǒng)中存在著技術難點，其原因有：①需要加入的TCP/IP協(xié)議棧軟件是一個比較復雜的軟件系統(tǒng)，對于系統(tǒng)資源的消耗較大；②PC系統(tǒng)的TCP/IP協(xié)議棧在實時性能和精簡程度等方面通常也不適應于嵌入式系統(tǒng)應用的實際要求。這兩個問題的解決就需要針對特定應用實現(xiàn)一個簡潔﹑高效的協(xié)議棧。

2.嵌入式系統(tǒng)協(xié)議棧中TCP/IP的設計和實現(xiàn)

嵌入式系統(tǒng)的網絡協(xié)議棧研究是利用現(xiàn)有的TCP/IP協(xié)議棧進行系統(tǒng)的分析和研究，把相關子協(xié)議進行優(yōu)化和簡化，最終實現(xiàn)了一種全新的嵌入式TCP/IP協(xié)議棧MinIP。這個協(xié)議棧的設計目的是為瘦客戶端嵌入式網絡應用提供所需要的協(xié)議棧組件，在此對TCP/IP協(xié)議的設計過程進行論述。

2.1 TCP協(xié)議設計

2.1.1 取消滑動窗口

TCP在進行流量控制時，通常采用的是窗口機制來實現(xiàn)的，在MinIP的TCP設計里，拋棄窗口機制，沒有對流量進行控制?？紤]到MinIP主要運用在局域網絡里，網絡流量通常并不是很高，所以可以暫時不考慮其對流量與網絡擁塞進行的控制，在實現(xiàn)過程中可對其進一步的精簡。

2.1.2 簡化處理的TCP狀態(tài)機

簡化后的有限狀態(tài)機的流程是：前端采集數據填充發(fā)送緩沖后，會通過送含有標志字段SYN的數據包至目的主機，主動要求建立TCP連接，等待目的主機的SYN回復與ACK信息，當收到該數據包后然后發(fā)送ACK向目的主機進行確認，最后，MinIP和目的主機的“三次握手”也就完成了，而后雙方開始相互交換實際數據。當完成數據發(fā)送的時候，MinIP的TCP發(fā)送含有標志字段FIN的信息至目的主機并要求關閉TCP，同時從ESTABLISHED狀態(tài)變化為FIN_WAIT_1狀態(tài)，而后等待目的主機反饋的信息ACK，在收到ACK數據包后，F(xiàn)IN_WAIT_1狀態(tài)變化為FIN_WAIT_2狀態(tài)，MinIP繼續(xù)等待由目的主機發(fā)出的帶FIN標志字段的數據包，在收到數據包后，進入TIME_WAIT狀態(tài)，為了能夠使最后發(fā)給目的主機的ACK數據包能夠成功的到達，MinIP在發(fā)送完ACK后則會繼續(xù)處于TIME_WAIT狀態(tài)，繼續(xù)等待2MSL。最后，一個完整的TCP通訊過程也就結束了。

2.1.3 改進的TCP定時機制

嵌入式設備的另一個特點就是需要考慮設備的功耗，多數便攜式嵌入式設備一般使用電池來供電，這是和計算機平臺不同的特點，所以節(jié)能就必須加以考慮。

TCP協(xié)議的連接及通信過程在任何的網絡拓樸環(huán)境下，由于設計時的考慮，TCP都會存在一定的超時重傳機制，而有些重傳實際上是沒有必要的，只是TCP為保證數據的可靠性及完整性而設計的，因此，可以考慮針對傳統(tǒng)的TCP重傳機制進行適當的優(yōu)化，使重傳時產生的時間延遲盡量減少，這樣就可以減少無用數據的重傳，進而節(jié)省了功耗。

把設備閑置時的系統(tǒng)能耗這里設為：Pi，設備處于TCP環(huán)境下通訊狀態(tài)時，該設備數據發(fā)送產生的能耗和所需時間分別為：Plx、Tlx，接收數據時所需能耗和時間分別為：Pmx、Tmx，那么整個設備在T時間內的能耗El可以按下式計算：

El=Pi×（Tl-Tlx-Tlx）+Plx×Tlx+Pmx×Tmx

=Pi×Ti+Elx+Emx

=Pi×Ti+Ea

在上式中，Pi為設備閑置時的待機能耗，Ti為待機時間，Ea為通訊過程中的總能耗。從另外一個角度看，設備進行通訊時，發(fā)送數據或接收數據產生的能耗也可以等價為設備空閑時的能耗加上發(fā)送時的附加功耗Pt或接收數據時產生的功耗Pm，故有下式：

Plx=Pt+Pi

Pmx=Pm+Pi

所以經過前式和上式的結合，可以推導出：El=Pi×Tl+Ed?？傻茫?/p>

Pi×Tl+Ea=Pi×Ti+Ed.

而一般嵌入式（如：S3C44b0X）是含有節(jié)能處理模式的，所以，空閑情況下可以認為Pi<

經過推導，從得出的式子可以看出數據收發(fā)過程中設備所需的的能耗決定了總能耗高低，所以對數據包超時重發(fā)機制的改進，是可以減小發(fā)送數據時設備產生的能耗，從而可以從一定角度實現(xiàn)對設備的有效節(jié)能。

2.2 IP協(xié)議的設計

考慮到送時數據包大小已經約定，不會出現(xiàn)數據包過長的情況，MinIP中的IP協(xié)議刪減了數據包的分解和合并相關操作，在針對嵌入式應用做了適當精簡，但是對復雜的路由機制并沒有實現(xiàn)，主要實現(xiàn)2類主要功能：（1）驗證收到的數據包的頭是否有錯誤，如無錯誤就進行解析該數據包，以確定該數據包是哪種層協(xié)議接收。（2）在發(fā)送的數據頭封裝相應的IP信息。

從網絡設備發(fā)送端進入到數據緩沖區(qū)后，會先經過一個包類型判斷，主要是判斷出數據是IP數據還是arp數據包。如果是IP數據包，會調用IpRcv（）來處理，然后對該數據進行校驗，根據IP數據包的協(xié)議字段判斷包中保存的是哪種類型的數據。

3.展望

本文雖然實現(xiàn)一個具備了基本功能并且結構完整的嵌入式協(xié)議棧MinIP，但離成熟的協(xié)議棧組件還有很大的一段距離，存在了一些問題，需要繼續(xù)的研究與完善。

（1）安全性問題：MinIP基本沒有過多的考慮到安全這一系列的問題，僅對數據包的格式做了一些基本校驗，需要在MinIP中增加一些切實可行的網絡安全機制，如在傳輸控制協(xié)議的基礎上來實現(xiàn)安全套接字協(xié)議安全套接等進行彌補。

（2）網絡傳輸效率的問題：“固定雙緩沖”機制是MinIP的特點，但是同時也會導致MinIP在進行數據發(fā)送過程中顯得過于慢。

（3）功能的完整性：MinIP只時包括一個連網應用的基本子協(xié)議，在對于要求復雜的網絡應用中沒有考慮。

參考文獻：

[1]MartinD.Semantic markup for web services[EB/OL].http：www.w3.orSubmission，2009.

[2]ChristianBenvenuti.UnderstandingLinuxNetworkInternals[M].O'Reilly，2005.

[3]Sergio Scaglia著，潘琢金，徐蕾等譯.嵌入式Intemet TCP/IP基礎、實現(xiàn)及應用[M].北京：北京航空航天大學出版社，2008.

[4]Alan B.Johnston .SIP Understanding：The.Session.Initiation.Protocol-2nd[M].ArtechHouse ，2004.