一種精簡TCP/IP協議棧的設計與實現

趙 川，伍瑞卿，樊 豐

（電子科技大學 電子工程學院，四川 成都 611731）

1 引言

網絡視頻傳輸得到了越來越廣泛的應用，如IP可視電話、數字攝像機、網絡視頻會議、視頻監控系統，數字視頻播放器/點播機等。在很多應用場合，都需要小型的嵌入式系統來實現[1]。通常，基于DSP的協議棧都移植自LWIP，uIP。而這些協議棧并不針對視頻傳輸設計。視頻傳輸中通常使用UDP協議以保證傳輸的實時性[2]。但是UDP的傳輸是無連接的，不可靠的。例如，在H.264中，如果丟掉解碼圖像需要的參數集或者IDR圖像，會造成無法解碼的結果。筆者提出了一種針對視頻流傳輸的改進的UDP協議，在確保正確解碼的同時，保證了較小的開銷和較高的效率。

2 TMS320DM642 DSP開發平臺

TMS320DM642（簡稱DM642）是TI公司的一款專用于數字媒體應用的高性能32位定點DSP芯片。工作主頻高達720 MHz，處理能力可達5 760 MI/s（兆指令/秒），外部總線時鐘100MHz。DM642集成了64個32 bit的通用寄存器，能夠在一個時鐘周期內處理4個16 bit的乘法和8個8 bit的乘法。64 bit寬度的EMIF總線，可連接大容量 SDRAM，Flash，ATA等存儲器資源。4路PAL/NTSC標準模擬視頻輸入，1路PAL/NTSC標準模擬視頻輸出，以及一個支持10/100 Mbit/s自適應網卡的EMAC/MDIO模塊，通過寄存器配置可提供一定的QoS保證[3]。因此，該芯片非常適合視頻數據的處理和傳輸。

3 網絡驅動程序的開發

網絡接口控制芯片主要由 EMAC Control，EMAC，MDIO等模塊控制。

3.1 模塊主要功能和結構

MAC Control：主要作為DSP與EMAC/MDIO的接口，提供4 kbyte的本地內存空間給EMAC的包緩沖描述符；具有總線仲裁、重啟EMAC/MDIO、全局中斷使能、中斷邏輯控制等功能，與EMAC模塊一起初始化。

MDIO：使用有限狀態機配置和監控物理層設備（PHY）。

EMAC：用于在網絡上發送和接收數據包。而開發設備驅動主要是對該模塊編程。EMAC的特點是：1）作為DMA控制器，在DSP內部和外部存儲空間之間傳送數據；2）連接PHY的介質無關接口（MII）；3）8個接收和8個發送通道，提供一定的QoS支持；4）可選的發送CRC校驗；5）支持多播、廣播和混合模式；6）硬件流控制。

模塊框圖如圖1所示，其中EMAC/MDIO通過中斷映射到DSP的11號中斷，EMAC通過DSP內存轉換控制器讀寫DSP的內部外部存儲空間，模塊的控制寄存器通過DSP配置總線映射到DSP存儲空間。

圖1 模塊結構框圖

3.2 底層驅動的軟件結構

EMAC使用描述符來管理接收和發送緩沖隊列。描述符是一個16 byte的內存結構，存儲在EMACControl模塊中，包含數據包的長度，存放位置等信息[4]。每個描述符表示1個以太網包。每次發送或者接收操作完成，EMAC都會向DSP發送中斷，調整描述符隊列。

以太網包的接收和發送是通過一個緩沖描述符系統實現的。EMAC提供256個可用的描述符，每個接收或發送通道都有自己的通道描述符結構，用來維系描述符鏈表。設備驅動取出空的描述符以便EMAC能夠將收到的以太網包的數據寫入對應緩存，將緩存中的即將發送的數據送出并且清理對應的描述符以便重復利用。

EMAC接收和發送數據的流程如圖2和圖3所示。

圖2 接收流程圖

圖3 發送流程圖

4 精簡協議棧的設計與實現

4.1 協議層的結構

嵌入式系統中實現的協議要根據各個系統的特點及功能來設計其獨特的TCP/IP協議簇，實現與需要有關的部分，而不使用的協議則省略。在局域網上使用的很多功能，比如路由協議、SNMP都不需要，只使用ARP，IP，ICMP和UDP，可省略應用層協議。在用于視頻數據傳輸的網絡中，如果簡化協議基于TCP的話，不僅開銷較大，丟失分組將會造成播放延時的增大[2]。并且視頻流本身具有一定的錯誤恢復能力，所以本文的協議棧主要以UDP的發送和接收為設計和測試對象。

4.2 存儲緩沖的管理

TCP/IP棧和設備驅動使用包緩沖區發送及接收網絡包數據。在該協議棧中，開辟32個包緩沖區構成的緩沖池，而以太網幀長度限制在1 514 byte或1 518 byte（加入CRC校驗），因此設置每個緩沖為1 536 byte=（1 024+512） byte，這樣分配可以對齊Cache邊界，保證沖洗（flush）Cache時，不會與其他緩沖區發生沖突，并且節省存儲空間。32個包緩沖頭使用EMAC的EMAC_Pkt結構。兩段緩沖均存放在片外SDRAM中。協議棧的數據處理和底層設備接口使用sk_buff的結構，編碼如下：

其中包含1個底層EMAC的數據包指針，這樣就可以方便地將EMAC接收的數據包放入協議棧的緩沖中。協議棧中的緩沖skb即是這種結構。

在每次發送1個數據包之前，都要首先分配skb的存儲空間。從EMAC的空隊列中彈出1個EMAC_Pkt的數據包，并將skb內的這個數據包指針指向它，然后對skb進行操作。在釋放skb時，將這個數據包壓入空隊列中以便繼續使用。

每層協議在封裝幀頭前，在數據區前預留這些幀頭的空間，而數據區域不變。這樣數據在各層協議之間傳遞都使用數據指針，從而避免了數據的重復搬移，以提高效率。當提交到下層協議時，將數據指針pskb-＞data向前移動1個幀頭長度。而在接收數據時，每層協議去掉幀頭，將數據指針向后移動1個幀頭長度。

由于I幀大小一般超過了1 514 byte，需要加入IP分片的功能。首先計算需要分片數，預留該傳輸層需要的幀頭，填入傳輸層的幀頭數據，然后從原始數據復制到pskb-＞data，剩下的片預留IP層需要的幀頭，填入幀頭數據后發送。

ARP的實現需要建立1個ARP列表，存放網絡中主機（DSP或PC）的ARP信息。在收到1個IP包后，DSP首先發送1個廣播包，查找該報文中源IP對應的MAC地址，如果不在列表中，發送ARP請求，在接收到回應后，將MAC地址和對應的IP加入列表。

在以太網層，調用csl中EMAC_sendPacket發送數據。

加入類BSD套接字函數，封裝底層函數，包括socket，accept，bind，connect，recv，recvfrom，send，sendto 等， 便于應用程序調用。

5 協議棧的改進

5.1 改進的UDP協議

鑒于參數集和I幀的重要性，為了提高傳輸的可靠性，保證正確接收端正確解碼，并盡量使協議棧簡單，采用類似TCP的重傳機制，流程如圖4所示。

圖4 改進的UDP傳輸

閾值 RTO 采用 TCP 的計算方法[5]：RTO=β×RTT，RTT為平均往返時延。RTT=α×RTTold+（1-α）×RTTnew，RTTold為上一次的平均往返時間，RTTnew為新的往返時間。往返時間可根據發送時刻的絕對時間和接收到接收報告的絕對時間來計算[5]，每發送1個序列（IDR幀更新）就計算1次。在小型網絡中，為及時重傳關鍵的數據包，取α=0.25，β=1.5。為測試簡便，由幾次實驗估計，取RTO的值為50ms。

如果需要更可靠的傳輸，可以在接收端每收到1個數據包就發送1個IP數據包，內容為成功接收標志位，用于發送端判斷是否重傳以及接收端剩余的緩存空間，用于發送端決定是否延遲一小段時間，等待接收端清理出足夠的緩存空間再發送數據。

5.2 接收報告的設計

視頻流的接收情況需要反饋給發送端以便客戶端和服務端的交互，發送速率需要根據接收端接收和解碼的速率來進行一些調整以達到匹配，還可以使發送端對出現的問題進行分析和采取一些解決措施。通常的反饋接收報告中設置固定的時間間隙發送接收報告[1]，缺乏靈活性，并且該時間需要大量實驗來驗證，時間太短會導致網絡流量增大，時間太長可能無法及時使發送端獲得網絡狀況并由此控制發送端調整發送速率。因此設計在接收端成功接收到參數集和I幀后，或者解碼1個序列（下一個IDR幀到來）后，發送1個接收報告。發送端可以根據接收報告檢測網絡狀況及延時抖動，然后相應的調整發送速率。如果在報文中加入各幀解碼時間，還可以調整編碼的碼率，以達到編碼和解碼的速率的匹配。

為了提高兼容性和擴展性，參照使用RTCP報文的頭部，以便其他能夠解析RTCP包的應用程序識別。報頭格式如圖5所示。

圖5 報文頭格式

圖5中，V為版本號，用于識別報文的合法性。P為填充位，為1時表示數據包末位有填充位。RC為報告位，數據包中所含有的報告數目。PT為類型，不同的值代表不同類型的包，可針對不同的用途設計不同內容的報文，以類型區分。例如，用于視頻監控（基本檔次），用于流媒體播放（擴展檔次）等。Len為整個數據包的長度，不包括報頭長。每種類型的報文有固定的長度，如果不符合可以直接丟棄。報文內容如圖6所示。

圖6中，T n為第n幀的傳輸時間。n由發送端的I幀周期決定，或者由接收端設定。丟包的序號由接收端根據發送的RTP數據包內容決定。丟包率表示從接收到第一個數據包開始的時間內丟掉的數據包總數與累積接收到的數據包的總數的比例?？刂茦酥疚粸?時，不變；為1時，提高碼率；為2時，降低碼率；為3時，關掉此連接。

圖6 報文內容

6 測試結果

測試使用網線直連DSP和PC，如果PC網卡沒有自適應交叉線/直通線功能，則必須制作交叉線來進行測試。

在PC（IP地址為192.168.1.20）上使用控制臺ping配置的DSP的IP地址（192.168.1.10），并且使用wireshark軟件抓取PC網卡上的數據包。測試結果如圖7所示。

圖7 wireshark測試結果

首先，PC網卡向DSP發送第1個ping請求，DSP接收到后發送ARP請求，PC回應自己IP對應的網卡地址，DSP回應ping請求。表明ARP協議和ICMP協議正確實現。

在實際視頻序列傳輸中，采用foreman，news的QCIF以及CIF序列測試，解碼端能夠正確解碼播放，并且達到設定的幀率。對于誤碼重傳仿真測試，本文不再詳述。

7 小結

基于DSP的視頻傳輸有著廣闊的應用空間，筆者提出了一個精簡協議棧的設計和實現方法，以及與EMAC底層驅動的連接，并針對H.264視頻流的特點做了一些改進。實驗證明，該協議?？蓾M足多種應用需求。

[1]王力生，梅巖，曹南洋.輕量級嵌入式TCP/IP協議棧的設計[J].計算機工程，2007，33（2）：246-248.

[2]畢厚杰.新一代視頻壓縮編碼標準——H.264/AVC[M].北京：人民郵電出版社，2005.

[3]Texas Instruments.TMS320C6000 DSP EMAC／MDIO module refer ence guide （Rev.A）[EB/OL].[2009-10-20].http://focus.ti.com/lit/ug/spru628a/spru628a.pdf.

[4]方懷東，陳啟美.基于TMS320DM642的嵌入式TCP/IP協議棧的實現[J].電子技術應用，2006，32（9）：25-29.

[5]謝希仁.計算機網絡[M].4版.大連：大連理工大學出版社，1989.