1引言

隨著嵌入式系統(tǒng)與網(wǎng)絡的日益結合，在嵌入式系統(tǒng)中引入TCP/IP協(xié)議棧，以支持嵌入式設備接入網(wǎng)絡，成為嵌入式領域重要的研究方向。并且隨著 Internet技術的迅猛發(fā)展和規(guī)模的不斷擴大，現(xiàn)行的Internet協(xié)議IPv4在地址空間、端到端的IP連接、服務質量和網(wǎng)絡安全等方面暴露出了不足，極大地限制了IP網(wǎng)絡的進一步發(fā)展。而IPv6所提供的巨大地址空間和網(wǎng)絡安全等因素已經(jīng)使其成為下一代因特網(wǎng)IP協(xié)議，為了能夠支持IPv6的應用，并且考慮到從IPv4到IPv6仍然需要一個過渡期，本文實現(xiàn)了一種基于實時操作系統(tǒng)的IPv4/IPv6雙協(xié)議棧結構。

2協(xié)議棧的設計要點

2.1平臺無關性

本文所設計的TCP/IP雙協(xié)議棧，要求不能局限于特定的硬件環(huán)境和軟件系統(tǒng)。因此，本協(xié)議棧的實現(xiàn)采用將所有的TCP/IP協(xié)議都駐留在一個進程當中，協(xié)議棧模塊與操作系統(tǒng)內核分開。通過定義一個操作系統(tǒng)模擬層實現(xiàn)平臺無關性。操作系統(tǒng)模擬層屏蔽硬件上的差異和獲取操作系統(tǒng)提供統(tǒng)一的接口，如時鐘、過程同步以及信息傳遞機制等。對于特定的嵌入式操作系統(tǒng)，直接對操作系統(tǒng)模擬層相應部分進行修改，以符合具體的要求。操作系統(tǒng)模擬層主要包括下面兩個部分：

⑴與處理器和編譯器有關

對不同微處理器的BYTE_ORDER存儲系統(tǒng)定義;對不同編譯器的數(shù)據(jù)類型長度的定義;與CPU或編譯器相關的內容的定義。

⑵與操作系統(tǒng)相關

協(xié)議棧進程與應用程序進程之間的同步與通訊，需要對信號量sys_sem_t、消息隊列sys_mbox_t和時鐘函數(shù)進行定義和操作。

2.2協(xié)議棧的裁減

標準的TCP/IP協(xié)議棧功能復雜，代碼量大，且需大量的存儲器資源。為了滿足嵌入式應用，必須對RFC定義的協(xié)議棧進行裁減[1]。本協(xié)議棧的實現(xiàn)作了如下裁減：

⑴IP模塊：不支持數(shù)據(jù)分片，不支持數(shù)據(jù)包轉發(fā)，不支持IPv6移動功能，不支持部分IPv6的擴展報頭。

⑵ICMPv6模塊：支持信息報文中的請求和應答報文，支持錯誤報文中的目的不可達和超時報文。

⑶鄰居發(fā)現(xiàn)模塊：支持地址解析、重復性探測，省略了路由功能。

⑷TCP模塊：支持多個連接，簡化滑動窗口，實現(xiàn)快速重傳、慢啟動與擁塞避免算法的TCP可靠性機制;約減掉半關閉，緊急指針，大部分TCP選項等。

協(xié)議棧的層次結構如圖1所示。采用獨立于網(wǎng)絡層的方式，IPv4協(xié)議和IPv6協(xié)議分開實現(xiàn)，條理清楚，易于裁減，同時不會增加太多代碼空間。

上層應用(HTTP)

TCP

ICMPv4ICMPv6

ARPIPv4IPv6

網(wǎng)絡驅動

3協(xié)議棧的實現(xiàn)

3.1內存管理

內存管理主要是針對協(xié)議棧內部緩沖區(qū)的管理。為了勝任任意大小報文的處理，并且能夠達到比較高的處理效率，在這里定義了兩種緩沖區(qū)實現(xiàn)機制：固定長度緩沖區(qū)(pbuf_pool)和變長度緩沖區(qū)(pbuf_ram)。pbuf_pool主要適合于網(wǎng)絡設備驅動，存放從網(wǎng)卡接收的數(shù)據(jù)。 pbuf_ram根據(jù)數(shù)據(jù)的大小動態(tài)的分配緩沖區(qū)，如協(xié)議的報頭空間。

在這里對存儲空間的申請做了一定改進。由于發(fā)送數(shù)據(jù)時很難確定各層協(xié)議頭部需要多大的內存空間，特別是IPv6報文可以包含若干個擴展頭，所以只申請基本頭部的內存空間，在使用中動態(tài)調整的可能性就會很大，使得系統(tǒng)的效率降低。在這里提出了一種優(yōu)化方法，根據(jù)局部性原理，通常情況下一個連接在局部時間范圍內需要網(wǎng)絡層提供相同功能的概率非常大，所以在該連接的TCP_PCB控制塊中增加一個變量num，用于記錄上次通信時IPv6協(xié)議頭所使用的字節(jié)數(shù)，并且此變量可以被網(wǎng)絡層的函數(shù)進行修改。當傳輸層下次申請pbuf時，就參考這個值。如果所需的存儲空間比此值大，就需重新申請能滿足要求的存儲空間，同時修改num的值，并作為下一次申請的參考。

3.2網(wǎng)絡接口的實現(xiàn)

網(wǎng)絡接口層在設計上主要考慮下面幾個目標：⑴向協(xié)議層提供一個統(tǒng)一的網(wǎng)絡通信接口，能夠將上層協(xié)議模塊與具體的網(wǎng)絡接口硬件隔離開來，以利于向不同操作系統(tǒng)的移植;⑵支持一個網(wǎng)絡接口配置多個IP地址的功能，因為IPv6一個接口的IP地址包括本地鏈路、本地站點和全局三類地址;⑶支持多播報文的收發(fā)，提供動態(tài)的多播IP與多播MAC地址的映射服務;⑷提供較好的通信性能等。

針對上述目標，設計了如下的網(wǎng)絡接口控制結構：

struct netif {

struct netif *next; /*指向下一個netif結構的指針*/

netif_ipaddr *iplist; /*指向接口的ip地址鏈的首指針*/

char name[2]; /*接口名稱*/

err_t (* input)(struct pbuf *p, struct netif *); /*接口輸入函數(shù)指針*/

err_t (* output)(struct netif *, struct pbuf *p,netif_addr *); /*接口輸出函數(shù)指針*/

err_t (* linkoutput)(struct netif *, struct pbuf *p); /*鏈路層輸出函數(shù)指針*/

void *state; /*指向接口的狀態(tài)信息*/

mac_addr netifmacaddr; /*接口的MAC地址*/

netif_multi *multilist; /*本接口的MAC多播地址鏈首指針*/

┊ /*省略了部分信息 */

};

網(wǎng)絡接口層是協(xié)議棧與下層網(wǎng)絡設備驅動程序之間的接口，同時支持IPv4報文和IPv6報文，通過判斷幀的類型字段，把接收到的不同類型的報文交給不同的協(xié)議模塊進行處理。

3.3 IPv6模塊

IPv6[2]模塊主要包括兩部分的功能，一是負責從網(wǎng)絡接口層接收IPv6數(shù)據(jù)包，對數(shù)據(jù)包進行一定的處理后發(fā)送給上層處理模塊(TCP或ICMPv6)。二是從上層接收數(shù)據(jù)，進行報文的選路，封裝IPv6報頭后將數(shù)據(jù)報發(fā)送給網(wǎng)絡接口層。

3.3.1 ICMPv6[3]的簡化分析

⑴ICMPv6信息報文

嵌入式設備只需作為Ping的接收端，所以不需要發(fā)送回顯請求報文和處理回顯應答報文。為了讓客戶端可以測試網(wǎng)絡狀態(tài)以及測試使用，必須支持接收請求報文和發(fā)送相應的應答報文。

⑵ICMPv6錯誤報文

由于嵌入式設備不會作為路由轉發(fā)設備，所以需要實現(xiàn)發(fā)送端口不可達報文，同時要支持超時報文通告對端超時錯誤。在BSD中，IP層沒有發(fā)送參數(shù)問題報文， ICMPv6無需支持處理參數(shù)問題報文。

3.3.2鄰居發(fā)現(xiàn)協(xié)議(NDP)的簡化分析

NDP[4]是IPv6協(xié)議的一個基本組成部分，它用于地址解析、鄰居發(fā)現(xiàn)以及路由器及網(wǎng)絡參數(shù)發(fā)現(xiàn)。本協(xié)議棧不支持路由功能，所以無需實現(xiàn)發(fā)送路由器通告報文，但必須接受路由器通告報文，以完成路由發(fā)現(xiàn)功能。同時支持鄰居通告和鄰居請求報文的接收和發(fā)送，以實現(xiàn)地址解析和重復探測。

3.4 TCP模塊

在TCP之上實現(xiàn)有限的WEB服務，可以對該協(xié)議的實現(xiàn)機制作相應的簡化及優(yōu)化。

3.4.1 TCP模塊的擴展

TCP對IPv4和IPv6報文的處理過程沒有任何的不同，但是由于IPv4和IPv6地址結構不同，需要對使用IP地址的部分進行擴展。

⑴數(shù)據(jù)結構擴展

PCB是用來記錄每個TCP連接狀態(tài)的，包括本地IP地址和遠程IP地址，擴展時使用union結構添加IPv6地址，同時添加標識位區(qū)別連接。

⑵操作擴展

在TCP處理過程中包括輸入時對IP地址和端口號的匹配，輸出時校驗和的計算和路由的查找。由于對IPv4和IPv6報文調用相同的處理函數(shù)，需要在實現(xiàn)時在這幾個函數(shù)的處理過程中加入對相應PCB中標識位的判斷。

3.4.2 簡化TCP狀態(tài)機

TCP的面向連接和可靠性傳輸?shù)忍匦詻Q定了每一個標準的TCP狀態(tài)機龐大而且復雜，對于嵌入式應用，可以根據(jù)需要進行簡化。

建立連接分為主動打開和被動打開，本協(xié)議棧設計作為監(jiān)聽狀態(tài)的服務器端，僅實現(xiàn)被動打開。在設計中去掉了CLOSED狀態(tài)，讓它一開始就處于LISTEN狀態(tài)，等待對方發(fā)起連接。

斷開連接分為主動斷開和被動斷開，從安全性的角度考慮，本設計僅實現(xiàn)主動斷開連接。當服務器發(fā)送完數(shù)據(jù)時，向客戶機發(fā)送關閉連接請求。

通過以上分析，根據(jù)特定的應用不失一般性的裁減掉復雜和冗余的機制，除去標準狀態(tài)機中的客戶端部分，簡化連接的建立和關閉過程，就得到如圖2所示的簡化的TCP狀態(tài)機模型。

圖2 簡化TCP有限狀態(tài)機

圖3 滑動窗口示意圖

3.4.3 簡化的窗口機制

標準的TCP協(xié)議使用慢啟動的滑動窗口機制[5]，它允許發(fā)送方在等待一個確認之前發(fā)送多個窗口。其確認是一種批量的確認，處理器要對多個數(shù)據(jù)報連續(xù)傳輸進行維護和處理，困難較大。

而滑動窗口的一個極限情況，是只使用單個窗口，這就變成了一種簡單確認的處理方法。只是對于單個數(shù)據(jù)報的發(fā)送和確認，雖然節(jié)約了系統(tǒng)的資源，也使維護更加方便，但是卻降低了效率。

系統(tǒng)采用了一個折中的辦法，適當調整窗口的大小，限制連續(xù)發(fā)送報文段的個數(shù)來實現(xiàn)了一個簡化的窗口機制，如圖3所示。在這里，設置窗口大小(snd_wnd)為4個最大報文段長度(MSS)，可以適當提高數(shù)據(jù)傳輸效率。

4 協(xié)議棧的移植和測試

在完成雙協(xié)議棧的設計調試后，將此協(xié)議棧移植到基于ARM7TDMI核的AT91M40800開發(fā)板上，使用其中內嵌的10Mbps以太網(wǎng)控制器 RTL8019AS作為網(wǎng)絡接口。在該平臺上實現(xiàn)了一個簡單的Web Server。通過構建提供IPv4地址和IPv6地址訪問的網(wǎng)絡拓撲結構進行測試，該雙協(xié)議棧運行穩(wěn)定、正常。

同時，在相同環(huán)境下將此協(xié)議棧與開源的協(xié)議棧LwIP作了吞吐率性能方面的比較，如圖4所示。可知，本協(xié)議棧有較好的吞吐率，在連接數(shù)達到3條以后，平均吞吐率達到了460kB/s。

圖4 協(xié)議棧吞吐率比較

5 結語

本文主要介紹了一種嵌入式雙協(xié)議棧的實現(xiàn)，實踐證明它是一個符合TCP/IP協(xié)議規(guī)范的，高性能，低開銷，可移植的IPv4/IPv6雙協(xié)議棧。本協(xié)議棧僅實現(xiàn)了基本的IPv4和IPv6通信功能，還有需多需要改進和增強的地方，擴展IPv6的移動功能是此協(xié)議棧下一步的研究重點。

本文作者創(chuàng)新點：嵌入式雙協(xié)議棧的實現(xiàn)獨立于操作系統(tǒng)內核和硬件平臺。設計了具有較高處理效率的緩沖區(qū)管理機制，對IPv6功能模塊進行了裁減，對TCP模塊中的運行狀態(tài)機和滑動窗口機制進行了簡化。