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

　　1 報文粘連問題的現象及分析

　　1.1 報文粘連問題的現象

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

圖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 Sockets 1.1標準，可以將setsockopt函數中的level項設置為IPPROTO_TCP1，這樣就可以關閉Nagle優化算法。

　　（2） 將Winsock kernel buffer設置為0

　　此方法只有在支持Windows Sockets 2.0標準的系統上才能使用（VxWorks不能支持），可在發送方為工控機、接收方為使用VxWorks操作系統的處理器的情況下使用。只需將setsockopt項中的level設為SOL_SOCKET，將SO_SNDBUF值設為0。