VxWorks是美國Wind River公司推出的一款專門為實時系統(tǒng)設(shè)計開發(fā)的操作系統(tǒng)內(nèi)核，為程序員提供了高效的實時多任務(wù)調(diào)度,、中斷管理,，實時的系統(tǒng)資源以及實時的任務(wù)間通信。它是一種功能強(qiáng)大而且比較復(fù)雜的操作系統(tǒng),，包括進(jìn)程管理,、存儲管理、設(shè)備管理,、文件系統(tǒng)管理,、網(wǎng)絡(luò)協(xié)議及系統(tǒng)應(yīng)用等部分。目前VxWorks應(yīng)用已經(jīng)十分廣泛,，從數(shù)碼相機(jī),、路由器到B2隱形轟炸機(jī)、火星探路者，都有它的身影,。在863某交通重大專項計劃控制系統(tǒng)國產(chǎn)化研究項目中,，分區(qū)控制計算機(jī)（DCC）和電機(jī)控制單元（MCU）也都采用了VxWorks操作系統(tǒng)。在現(xiàn)場測試過程中,，我們發(fā)現(xiàn)基于TCP/IP網(wǎng)絡(luò)協(xié)議傳輸?shù)臄?shù)據(jù)有時會出現(xiàn)粘包現(xiàn)象（即發(fā)送方發(fā)送的若干包數(shù)據(jù)傳輸?shù)浇邮辗綍r粘成一包）,。針對這種情況，我們進(jìn)行了專題研究與實驗,。本文重點分析了TCP/IP協(xié)議的粘包問題,，并結(jié)合實驗結(jié)果提出了解決該問題的對策和方法。

1,、報文粘連問題的現(xiàn)象及分析

    1.1 報文粘連問題的現(xiàn)象

    TCP/IP報文粘連是指發(fā)送方發(fā)送的若干包數(shù)據(jù),，在接收方接收到時粘成一包，即后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾,。由于報文長度與接收緩沖區(qū)長度有可能不成整倍數(shù)關(guān)系,，所以粘連在一起的報文中有不完整的包。VxWorks操作系統(tǒng)會先將由網(wǎng)絡(luò)傳輸來的數(shù)據(jù)放入系統(tǒng)接收緩沖區(qū)中,，以備用戶進(jìn)程從中調(diào)用數(shù)據(jù),。此處假設(shè)接收方緩沖區(qū)長為L字節(jié)，L應(yīng)有一定的長度,，以保證至少可以存儲一包數(shù)據(jù),。由于DCC和MCU之間需要傳輸不同種類的報文來進(jìn)行數(shù)據(jù)交互，所以用戶在程序中應(yīng)為不同的報文分別設(shè)置不同的接收緩沖區(qū)來存放不同的報文數(shù)據(jù),。此處假設(shè)只有應(yīng)答報文和狀態(tài)報文兩種,，分別以用戶緩沖區(qū)1和2來存儲；長度應(yīng)與用戶層對應(yīng)報文的長度相等,假設(shè)分別為m和n,。粘包情況如圖1所示,。

圖1 粘包情況示意圖

    1.2 報文粘連問題的分析

    報文粘連既可能由發(fā)送方產(chǎn)生，也可能由接收方產(chǎn)生,，還可能由進(jìn)行數(shù)據(jù)傳輸?shù)慕粨Q機(jī)產(chǎn)生,。

    (1) 發(fā)送方引起的報文粘連

    由發(fā)送方引起的報文粘連是源于TCP協(xié)議本身。因為TCP協(xié)議為提高傳輸效率采用了Nagle算法（詳見RFC896）,，發(fā)送方要等收集到1460字節(jié)的數(shù)據(jù)才會發(fā)送一包數(shù)據(jù),，或是等到發(fā)送緩沖區(qū)滿后才會發(fā)送一包數(shù)據(jù)，這就造成了報文的粘連,。

    (2) 接收方引起的報文粘連

    由接收方引起的報文粘連,，往往是因為接收方進(jìn)程沒有及時處理數(shù)據(jù)造成的。接收方要先把收到的數(shù)據(jù)放入接收數(shù)據(jù)緩沖區(qū),，用戶進(jìn)程再從該緩沖區(qū)中讀取數(shù)據(jù),。如果在下一包數(shù)據(jù)到達(dá)時前一包數(shù)據(jù)還未被用戶進(jìn)程取走,，則新一包數(shù)據(jù)就接到前一包數(shù)據(jù)之后,，而用戶要根據(jù)事先設(shè)定好的緩沖區(qū)大小從系統(tǒng)接收緩沖區(qū)中讀取數(shù)據(jù),，這就造成了一次取到了多包數(shù)據(jù)。

    (3) 由交換機(jī)引起的報文粘連

    由交換機(jī)引起的報文粘連,，往往是因為由交換機(jī)相連的各個部件在一段時間內(nèi)發(fā)送的報文數(shù)據(jù)太多,，以至于超出了交換機(jī)的處理能力。這樣,，本來發(fā)送端分開發(fā)送的數(shù)據(jù)報文在交換機(jī)內(nèi)部的緩沖區(qū)中粘連在一起?，F(xiàn)在，在實驗現(xiàn)場DCC等使用VxWorks操作系統(tǒng)的部件需要使用一個獨立的端口進(jìn)行程序下載,，還要有一個獨立的端口提供給SecureCRT軟件以進(jìn)行實時監(jiān)控,；同時DCC與MCU和中央控制系統(tǒng)的數(shù)據(jù)傳輸也要在同一臺交換機(jī)中進(jìn)行。這就有可能導(dǎo)致在某一段時間內(nèi)數(shù)據(jù)量超過了交換機(jī)的處理能力,。

    1.3 文粘連對系統(tǒng)的影響

    如果系統(tǒng)發(fā)生了報文粘連現(xiàn)象而不進(jìn)行相應(yīng)處理,，則將導(dǎo)致整個系統(tǒng)無法正常運行。

    如果用于傳輸數(shù)據(jù)的報文被粘連導(dǎo)致無法正常處理,，則將使接收方無法進(jìn)行運算,，現(xiàn)場實時的數(shù)據(jù)無法獲得，從而使標(biāo)志位無法置位,，程序無法繼續(xù)進(jìn)行,。如果作為生命信號的報文被粘連導(dǎo)致無法正常處理，則將使接收方認(rèn)為發(fā)送方出現(xiàn)故障,；若此情況連續(xù)發(fā)生,，則接收方將認(rèn)為發(fā)送方死機(jī)，從而停機(jī),，以保證整個系統(tǒng)的安全,。

2、報文粘連問題的解決方法

    2.1 發(fā)送方的解決方法

    對于由發(fā)送方引起的報文粘連,，可以采用以下兩種方法解決,。

    （1） 關(guān)閉Nagle算法

    由于VxWorks系統(tǒng)支持Windows Sockets 1.1標(biāo)準(zhǔn)，可以將setsockopt函數(shù)中的level項設(shè)置為IPPROTO_TCP1,，這樣就可以關(guān)閉Nagle優(yōu)化算法,。

    （2） 將Winsock kernel buffer設(shè)置為0

    此方法只有在支持Windows Sockets 2.0標(biāo)準(zhǔn)的系統(tǒng)上才能使用（VxWorks不能支持），可在發(fā)送方為工控機(jī),、接收方為使用VxWorks操作系統(tǒng)的處理器的情況下使用,。只需將setsockopt項中的level設(shè)為SOL_SOCKET，將SO_SNDBUF值設(shè)為0,。

    2.2 接收方的解決方法

    對于由接收方引起的報文粘連,，也有兩種方法解決,。

    （1） 提高報文處理任務(wù)的優(yōu)先級

    使用VxWorks操作系統(tǒng)可以方便地設(shè)置任務(wù)的優(yōu)先級。使用taskSpawn函數(shù)啟動任務(wù),，其中priority的數(shù)值就是任務(wù)的優(yōu)先級（從0～255,，優(yōu)先級依次降低）。使用此函數(shù)將處理報文任務(wù)的優(yōu)先級設(shè)為比其他任務(wù)高,，但是為了減小意外發(fā)生的可能,，該值應(yīng)小于100，因為taskSpawn的默認(rèn)優(yōu)先級為100,。

    （2） 將粘連在一起的報文進(jìn)行分包處理

    此方法是規(guī)定報文數(shù)據(jù)某一位的內(nèi)容為該幀報文數(shù)據(jù)的總長度,，接收方先提取出此內(nèi)容，如果緩沖區(qū)中的數(shù)據(jù)長度大于等于該長度,，則按該內(nèi)容的長度從緩沖區(qū)中提取數(shù)據(jù),；如果長度不夠則不提取數(shù)據(jù)，等到長度達(dá)到要求時再提取數(shù)據(jù),。這樣即使出現(xiàn)報文粘連現(xiàn)象,，應(yīng)用程序也會將粘連在一起的數(shù)據(jù)進(jìn)行分包處理，不會出現(xiàn)數(shù)據(jù)丟失無法識別報文ID的情況,。下面通過一個具體例子進(jìn)行詳細(xì)說明,。

    在實驗線上MCU發(fā)送給DCC的狀態(tài)報文長度為84字節(jié)（報文ID為91H），應(yīng)答報文長度為20字節(jié)（報文ID為81H）,，接收緩沖區(qū)為90字節(jié),。如果狀態(tài)報文粘連在應(yīng)答報文之后，則將使DCC無法收到完整的狀態(tài)報文,。這種情況連續(xù)發(fā)生3次之后,，DCC將認(rèn)為任務(wù)MCU發(fā)生故障，系統(tǒng)將停機(jī),，因而結(jié)果必然是錯誤的,。如果將報文長度放在報文的第一位中，報文ID放在第二位中,，則進(jìn)行分包處理后就不會出現(xiàn)上述的診斷錯誤,。處理過程如圖2所示。

圖2 分包處理過程

    2.3 交換機(jī)的解決方法

    對于由交換機(jī)引起的報文粘連,，有3種解決方法：

    （1） 使用有更強(qiáng)處理能力的交換機(jī)

    可使用處理能力更強(qiáng),、擁有較大緩存空間的交換機(jī)?？墒悄壳皩嶒灛F(xiàn)場已經(jīng)使用了某外國著名廠商的16口交換機(jī),，且該交換機(jī)有1MB的緩存空間，使用更高檔的交換機(jī)無疑會使成本增高,。

    （2） 增加交換機(jī)數(shù)量

    可將1臺16口交換機(jī)的工作量交由2臺8口交換機(jī)來完成,，再將這兩臺交換機(jī)進(jìn)行連接,。這種方法可以明顯降低一臺交換機(jī)的數(shù)據(jù)處理負(fù)擔(dān)，但會使系統(tǒng)的可靠性和安全性指標(biāo)大幅度降級,；而且隨著以后實驗設(shè)備的增加,，不斷連接新交換機(jī)的方法有可能使網(wǎng)絡(luò)形成環(huán)路，這將造成網(wǎng)絡(luò)癱瘓,。所以,，不建議使用此方法。

    （3） 修改對交換機(jī)的配置

    可通過修改相關(guān)參數(shù)將交換機(jī)數(shù)據(jù)傳輸方式設(shè)置為無等待傳輸,，即在交換機(jī)得到數(shù)據(jù)后不放入內(nèi)部緩沖區(qū)，而是直接交給接收方,。這種方式在一定程度上可以避免粘包現(xiàn)象的發(fā)生,，但當(dāng)報文傳輸很緊密時也有繼續(xù)產(chǎn)生粘包現(xiàn)象的可能。

3,、結(jié)論

    通過對發(fā)送方和接收方4種解決方法的現(xiàn)場實驗,，我們發(fā)現(xiàn)效果不盡相同。

    ① 在關(guān)閉Nagle算法的情況下,，發(fā)現(xiàn)Nagle算法依然在使用,。最終的結(jié)論是，這是Winsock的一個BUG,，并且已經(jīng)在微軟的BUG目錄中得到了證實,，所以此方法無效。

    ② 將Winsock kernel buffer設(shè)置為0后粘包問題得到了解決,，但傳輸速度明顯降低,。經(jīng)測試，每秒大概只能傳送5幀數(shù)據(jù),，這在VxWorks這種硬實時系統(tǒng)中是無法接受的,。

    ③ 提高報文處理任務(wù)優(yōu)先級的方法可以對報文粘連起到防治，但有可能產(chǎn)生一些不易發(fā)現(xiàn)的任務(wù)調(diào)度問題,。

    ④ 分包處理的方法雖然不能防止粘連的發(fā)生,，但是可以完全防止報文粘連對系統(tǒng)產(chǎn)生的影響。實踐證明,，使用分包處理的方法可以在高速數(shù)據(jù)傳輸?shù)那闆r下保證傳輸?shù)恼_性,，而且不會產(chǎn)生任何副作用，對處理速度的影響也很小,，可以忽略不計,。這種方法已經(jīng)在實驗現(xiàn)場使用了很長一段時間，運行情況良好,。

參考文獻(xiàn)

[1] Nagle J. Congestion Control in IP/TCP Internet works[S]. RFC896,1984.
[2] 陳智育,，溫彥軍,，陳琪.VxWorks程序開發(fā)實踐[M].北京：人民郵電出版社，2004.
[3] 鄺堅.Tornado/VxWorks入門與提高[M].北京：科學(xué)出版社,，2004.
[4] WindRiver. VxWorks for PowerPC Architecture Reference 5.5,2003,。