VxWorks是一種功能強大而且比較復雜的操作系統，包括進程管理、存儲管理、設備管理、文件系統管理、網絡協議及系統應用等部分。目前VxWorks應用已經十分廣泛，從數碼相機、路由器到B-2隱形轟炸機、火星探路者，都有它的身影。在863某交通重大專項計劃控制系統國產化研究項目中，分區控制汁算機（DCC）和電機控制單元（MCU）也都采用了VxWorks操作系統。在現場測試過程中，我們發現基于TCP/IP網絡協議傳輸的數據有時會出現粘包現象（即發送方發送的若干包數據傳輸到接收方時粘成一包）。針對這種情況，我們進行了專題研究與實驗。本文重點分析了TCP/IP協議的粘包問題，并結合實驗結果提出了解決該問題的對策和方法。 1 報文粘連問題的現象及分析 1．1 報文粘連問題的現象 TCP/IP報文粘連是指發送方發送的若干包數據，在接收方接收到時牯成一包，即后一包數據的頭緊接著前一包數據的尾。由于報文長度與接收緩沖區長度有可能不成整倍數關系，所以粘連在一起的報文中有不完整的包。VxWorks操作系統會先將由網絡傳輸來的數據放入系統接收緩沖區中，以備用戶進程從中凋用數據。此處假設接收方緩沖區長為L字節，L應有一定的長度，以保證至少可以存儲一包數據。由于DCC和MCU之間需要傳輸不同種類的報文來進行數據交互，所以用戶在程序中應為不同的報文分別設置不同的接收緩沖區來存放不同的報文數據。此處假設只有應答報文和狀態報文兩種，分別以用戶緩沖區1和2米存儲；長度應與用戶層對應報文的長度相等，假設分別為m和n。粘包情況如圖1所示。 1．2 報文粘連問題的分析 報文粘連既可能由發送方產生，也可能由接收方產生，還可能由進行數據傳輸的交換機產生。 （1）由發送方引起的報文粘連 由發送方引起的報文粘連是源于TCP協議本身。因為TCP協議為提高傳輸效率采用了Nagle算法（詳見RFC896），發送方要等收集到1460字節的數據才會發送一包數據，或是等到發送緩沖區滿后才會發送一包數據，這就造成了報文的粘連。 （2）由接收方引起的報文粘連 由接收方引起的報文粘連，往往是因為接收方進程沒有及時處理數據造成的。接收方要先把收到的數據放入接收數據緩沖區，用戶進程再從浚緩沖區中讀取數據。如果在下一包數據到達時前一包數據還未被用戶進程取走，則新一包數據就接到前一包數據之后，而用戶要根據事先設定好的緩沖區大小從系統接收緩沖區中讀取數據，這就造成了一次取到了多包數據。 （3）由交換機引起的報文粘連 由交換機引起的報文粘連，往往是因為由交換機相連的各個部件在一段時間內發送的報文數據太多，以至于超出了交換機的處理能力。這樣，本來發送端分開發送的數據報文在交換機內部的緩沖區中粘連在一起。現在，在實驗現場DCC等使用VxWorks操作系統的部件需要使用一個獨立的端口進行程序下載，還要有一個獨立的端口提供給SecureCRT軟件以進行實時監控；同時DCC與MCU和中央控制系統的數據傳輸也要在同一臺交換機中進行。這就有可能導致在某一段時間內數據量超過了交換機的處理能力。 1.3 報文粘連對系統的影響 如果系統發生了報文粘連現象而不進行相應處理，則將導致整個系統無法正常運行。 如果用于傳輸數據的報文被粘連導致無法正常處理，則將使接收方無法進行運算，現場實時的數據無法獲得，從而使標志位無法置位，程序無法繼續進行。如果作為生命信號的報文被粘連導致無法正常處理，則將使接收方認為發送方出現故障；若此情況連續發生，則接收方將認為發送方死機，從而停機，以保證整個系統的安全。 2 報文粘連問題的解決方法 2.1 發送方的解決方法 對于由發送方引起的報文粘連，可以采用以下兩種方法解決。 （1）關閉Nagle算法 由于VxWorks系統支持Windows Socketsl.1標準，可以將setsockopt函數中的1evel項設置為LPPROTO_TCPl，這樣就可以關閉Nagle優化算法。 （2）將Winsock kernel buffer設置為0 此方法只有在支持Windows Sockets 2．0標準的系統上才能使用（VxWorks不能支持），可在發送方為工控機、接收方為使用VxWorks操作系統的處理器的情況下使用。只需將setsockopt項巾的level設為SOL_SOCKET，將SO_SNDBUF值設為0。 2.2 接收方的解決方法 對于南接收方引起的報文粘連，也有兩種方法解決。 （1）提高報文處理任務的優先級 使用VxWorks操作系統可以方便地設置任務的優先級。使用taskSpawn函數啟動任務，其中priority的數值就是任務的優先級（從0～255，優先級依次降低）。使用此函數將處理報文任務的優先級設為比其他任務高，但是為了減小意外發生的可能，該值應小于100，因為taskSpawn的默認優先級為100。 （2）將粘連在一起的報文進行分包處理 此方法是規定報文數據某一位的內容為該幀報文數據的總長度，接收方先提取出此內容，如果緩沖區中的數據氏度大于等于該長度，則按該內容的長度從緩沖區中提取數據；如果長度不夠則不提取數據，等到長度達到要求時再提取數據。這樣即使m現報文粘連現象，應用程序也會將粘連在一起的數據進行分包處理，不會出現數據丟失無法識別報文ID的情況。下面通過一個具體例子進行詳細說明。 在實驗線上MCU發送給DCC的狀態報文長度為84字節（報文ID為91H），應答報文長度為20字節（報文ID為81H），接收緩沖區為90字節。如果狀態報文粘連在應答報文之后，則將使DCC無法收到完整的狀態報文。這種情況連續發生3次之后，DCC將認為任務MCU發生故障，系統將停機，因而結果必然是錯誤的。如果將報文長度放在報文的第一位中，報文ID放在第二位中，則進行分包處理后就不會出現上述的診斷錯誤。處理過程如圖2所示。 2．3 交換機的解決方法 對于由交換機引起的報文粘連，有3種解決方法： （1）使用有更強處理能力的交換機 可使用處理能力更強、擁有較大緩存空間的交換機。可是日前實驗現場已經使用了某外國著名廠商的16口交換機，且該交換機有1MB的緩存空間，使用更高檔的交換機無疑會使成本增高。 （2）增加交換機數量 可將1臺16口交換機的工作量交由2臺8口交換機來完成，再將這兩臺交換機進行連接，這種方法可以明顯降低一臺交換機的數據處理負擔，但會使系統的可靠性和安全性指標大幅度降級；而且隨著以后實驗設備的增加，不斷連接新交換機的方法有可能使網絡形成環路，這將造成網絡癱瘓。所以，不建議使用此方法。 （3）修改對交換機的配置 可通過修改相關參數將交換機數據傳輸方式設置為無等待傳輸，即在交換機得到數據后不放入內部緩沖區，而是直接交給接收方。這種方式在一定程度上可以避免粘包現象的發生，但當報文傳輸很緊密時也有繼續產生粘包現象的可能。 3 結論 通過對發送方和接收方4種解決方法的現場實驗，我們發現效果不盡相同。 ①在關閉Nagle算法的情況下，發現Nagle算法依然在使用。最終的結論是，這是Winsock的一個BUG，并且已經在微軟的BUG目錄中得到了證實，所以此方法無效。 ②將Winsock kernel buffer設置為O后粘包問題得到了解決，但傳輸速度明顯降低。經測試，每秒大概只能傳送5幀數據，這在VxWorks這種硬實時系統中是無法接受的。 ③提高報文處理任務優先級的方法可以對報文粘連起到防治，但有可能產生一些易發現的任務調度問題。 ④分包處理的方法雖然不能防止粘連的發生，但是可以完全防止報文粘連對系統產生的影響。 實踐證明，使用分包處理的方法可以在高速數據傳輸的情況下保證傳輸的正確性，而且不會產生任何副作用，對處理速度的影響也很小，可以忽略不計。這種方法已經在實驗現場使用了很長一段時間，運行情況良好。