端到端通信中TCP和Semi-TCP協議兼容問題的分析與解決

鄭濤，王菲，姜勝明

（上海海事大學信息工程學院，上海 201306）

0 引言

在以移動自組織網絡為代表的無線多跳網絡中，其網絡信道質量往往較差，存在著大量的非擁塞型丟包，傳統TCP的擁塞控制乃至擁塞判斷的方法，均不再適用。基于這種情況而提出的Semi-TCP改變了對網絡擁塞狀況判斷的依據，不再簡單地使用傳輸層ACK的數量進行估測[1]，改用數據鏈路層的緩存占用情況作為評判標準，從而在非擁塞型丟包狀況嚴重的無線多跳網絡中也能做出正確的擁塞判斷[2]。

但是，Semi-TCP和傳統TCP使用不同的擁塞判斷標準和擁塞處理方法，當二者共存于同一條通信鏈路時，截然不同的兩種擁塞控制算法無法與對方進行溝通轉換，勢必會造成網絡整體性能的下降[3]。在仿真軟件EXata中，當中間節點采用了不同的傳輸層協議，那么發送節點和接收節點之間的數據有時無法正常傳輸，這取決于Semi-TCP的具體實現方法。當一條通信鏈路同時包含有線和無線兩部分，且二者傳輸層分別使用傳統TCP和Semi-TCP協議時，本文提出一種方法，在協議交界面對兩種擁塞控制算法進行轉換。

另外，還有其他思路進行擁塞控制，例如TCPAP[4]，他根據網絡擁塞狀況在發送方自適應地調整發送速率，本文在EXata上對該協議也進行了實現，并與Semi-TCP設置平行實驗進行對比。

1 擁塞控制原理

1.1 擁塞控制的作用

擁塞控制對提高網絡吞吐量具有重要作用，理想的擁塞控制能夠隨著負載的提高逐漸提高網絡的吞吐量，直到某一最大值。實際的擁塞控制很難達到該最大值，并且由于擁塞控制需要付出相應的代價，所以會在網絡未發生擁塞或者輕度擁塞時，反而會降低網絡的吞吐量。但若不進行擁塞控制，一旦網絡發生擁塞，吞吐量會隨著負載的增加大幅降低，當負載達到一定程度時，網絡會無法工作，進入死鎖狀態[5]。

圖1 擁塞控制的作用

1.2 各種擁塞控制方法的對比

（1）傳統TCP協議：滑動窗口機制

TCP協議自最初的Tahoe開始，到目前為止已經有較多版本，例如 Reno、SACK、New Reno，其中 New Reno是目前無線網絡中應用最多的一種。本文所述的傳統TCP協議即以New Reno為例。傳統TCP的滑動窗口用于暫存通信用數據[6]，每臺計算機都有用于發送和接收的兩個滑動窗口[5]。傳統TCP通過窗口的滑動來調節傳輸速率，并進行流量控制。

圖2 發送緩存和發送窗口

圖3 接收窗口和接收緩存

發送窗口win的大小取決于擁塞窗口cwnd和接收窗口rwnd的較小者，即win=min(rwnd,cwnd)，使得發送速率能夠根據擁塞狀況進行調節，起到一定的擁塞控制作用。每當發方收到一個確認，就把擁塞窗口cwnd加1。每當發方檢測到擁塞發生，就降低擁塞窗口。

傳統TCP是在超時重傳和快速重傳之后進行的擁塞處理，也就是說，傳統TCP對擁塞判定的主要依據是發方能否在傳輸層及時地收到相應數據包的確認ACK。

（2）Semi-TCP協議：MAC層緩存占用率

在以鏈路不穩定、信道質量差、節點移動為特點的MANET網絡中，傳統TCP的擁塞處理機制頻繁地被非擁塞原因觸發[7]，錯誤地降低發送速率，導致傳統TCP在無線網絡中性能下降。針對無線場景的關于TCP協議的改進思路有很多，其中Semi-TCP認為，網絡擁塞是傳輸層之下的網絡層和數據鏈路層的概念，傳輸層只能采用估計的形式進行擁塞判斷，這才導致傳統TCP在無線網絡中經常發生擁塞的誤判。所以，Semi-TCP提出將擁塞控制功能轉到MAC層來實現。

目前已有兩種Semi-TCP的實現方式，基于RTS/CTS握手機制實現的Semi-TCP和基于MAC層確認機制實現的Semi-TCP。考慮到RTS/CTS握手機制主要應用于大文件傳輸的場景，其使用范圍受到更多地限制，故而本文所做的兼容性研究與優化都是以后者為基礎的。

基于確認機制實現的Semi-TCP，根據自身MAC緩存占用率對自身擁塞情況做出定量的判斷，并根據一跳內的鄰居節點廣播的擁塞信息對鄰居節點的擁塞狀況進行記錄。為避免ACK對MAC層緩存的占用可能引起擁塞的誤判，還將MAC層緩存細分為兩部分：發送緩存和接收緩存[8]。

擁塞判據：如圖4，假設接收緩存容量的最大值為L1，CT1為其擁塞門限，即當接收緩存內數據包個數N1≥CT1時，節點判定自身為擁塞狀態；L2為發送緩存容量的最大值，CT2為其擁塞門限，當傳輸層有數據要發送，且當前發送緩存中數據包個數N2滿足N1+N2＜CT2時，將數據直接送往發送緩存，否則，暫時不將數據送往發送緩存，以此來控制傳輸層的發送速率[9]。

（3）TCP-AP協議：速率自適應

Elrakabawy等人提出的 TCP-AP（TCP with Adap?tive Pacing），是一種應用于無線網絡的基于速率自適應的擁塞避免算法。TCP-AP[10]通過在發方調節發送間隔來實現對發送速率的控制，間隔的計算依賴于發方檢測到的RTT，通過RTT的變化來判定網絡當前的負載程度，并在每次接收到ACK后，重新計算發送間隔，從而實現發方根據網絡狀況對發送速率的自適應調節。該協議能夠避免傳統TCP協議在無線網絡中容易產生突發流量的問題，但其計算公式非常復雜，很容易受到網絡中節點計算能力的限制，且其對無線多跳網絡吞吐量的提高也很有限[11]。

圖4 節點內緩存的劃分

2 兼容性問題的分析與解決

2.1 兼容問題

傳統TCP協議使用滑動窗口機制進行擁塞控制，使用擁塞窗口對擁塞信息進行表征，當擁塞發生，即發方在規定時間內沒有收到對某一數據包的確認或者收到超過三次以上對某一數據包的重復確認時，通過主動減小擁塞窗口來間接地減小發送窗口，以此降低發送速率，減輕網絡擁塞。傳統TCP的擁塞控制是一種端到端的全局擁塞管控，只在通信兩端對擁塞進行檢測和處理，無法得知是在通信鏈路中何處發生擁塞。

Semi-TCP協議屬于逐跳擁塞控制，使用節點內MAC層緩存占用率對擁塞信息進行表征，當節點檢測到自身緩存占有率到達某閾值，即判定自身處于擁塞狀態，并向上游節點反饋自身擁塞狀況，當上游節點收到擁塞信息反饋時，就降低發送速率，以此實現擁塞的檢測和處理[7]。Semi-TCP舍棄了傳輸層的擁塞控制功能，通過MAC層緩存占用率來表示和檢測網絡擁塞狀況，能夠精確地檢測到擁塞發生在通信過程中的哪個節點，進行局部擁塞管控。

TCP-AP是一種透過表象做反應的協議，它使用最近一次往返時間RTT的大小來表征網絡擁塞信息。當RTT較大時，說明當前網絡負載嚴重，需要降低發送速率。發送速率的控制則依賴于兩次數據發送的間隔，當需要降低發送速率時，就將該間隔增大。

圖5 端到端通信中TCP與Semi-TCP共存現象

如圖5，傳統節點是使用傳統TCP協議的節點，Semi節點是使用Semi-TCP協議的節點，兩端分別是傳統節點和Semi節點的節點稱為協議交界面，在協議交界面對兩種協議的兼容問題進行解決。假設①的左側均為傳統節點，稱為傳統區，②的右側均為Semi節點，稱為Semi區。二者使用不同的擁塞控制機制，具有不同的擁塞判斷標準，①和②之間如果不做擁塞信息的轉換，勢必會對網絡整體性能造成負面影響。

2.2 協議交界面

（1）協議交界面的確定

在TCP連接的建立階段，確定協議交界面，具體做法如下：

選擇幀結構中的某一空閑位作為flag，并修改Semi-TCP協議，使得只要是由Semi節點生成或者轉發的信息，就對該flag做置位操作，傳統節點不對flag進行檢測和置位。一條通信鏈路如果只存在一個協議交界面，則該交界面必然是所有節點中唯一一個既能接收到未被置位信息，又能接收到被置位信息的Semi節點。

圖6 仿真場景

傳統節點雖然也能接收到具有兩種flag狀態的消息，但本文只對Semi-TCP協議進行修改，因此傳統節點不會檢測flag，更不可能被設置為協議交界面。另外，這里僅考慮通信鏈路中僅存在一個協議交界面的情況。當一條通信鏈路中存在多個協議交界面時，上述檢測算法僅能檢測出圖5中最左邊的協議交界面。

（2）協議交界面的功能

被設置為協議交界面的節點，在收發雙方建立TCP連接時，會在傳輸層創建與傳統節點匹配的虛擬發送/接收/擁塞窗口，以及與Semi節點相匹配的MAC層緩存，整個節點被分為圖5中的①和②兩部分，網絡擁塞控制也被劃分為傳統區和Semi區兩部分。

在協議交界面，所有消息都會被上傳到本節點的傳輸層，再根據flag位判斷信息來源，根據數據發送方向做相應的處理，具體流程如下：

1）數據發送方向：傳統節點-＞Semi節點

傳統節點將數據發往協議交界面，①接收到來自傳統節點的消息（Data）后，按照滑動窗口機制保存數據并修改接收窗口，只不過數據不再上傳至更高層，而是交給②，之后按照Semi-TCP的方式轉發該數據；Semi節點正確接收該報文后，回復ACK；當②接收到來自Semi節點的消息（ACK）后，根據②的緩存占用率判斷當前節點是否擁塞，若擁塞，則延遲適當時間后再將該確認包交給①，這樣，本應更早到達傳統節點的ACK，沒有那么早到達，作為數據發送方的傳統節點就會因等待ACK而延遲發送下一個數據，從而實現發送速率的降低。

2）數據發送方向：Semi節點-＞傳統節點

Semi節點將數據發往協議交界面，②接收到來自Semi節點的消息（Data）后，發給①，由①保存并決定何時轉發出去；傳統節點正確接收到該數據后，回復ACK；當①接收到來自傳統節點的消息（ACK）后，按照滑動窗口機制更新擁塞窗口等信息，并將該ACK轉發給②，由②按照Semi-TCP協議的方法進行轉發。

3 實驗結果與分析

本章將具體介紹傳統TCP協議與Semi-TCP協議共存于同一條通信鏈路時的性能測試，以及本文算法在EXata平臺上的實現與測試，主要是在考慮路由重建以及不考慮路由重建兩種情況下對優化前后的混合場景的網絡吞吐量進行對比。

3.1 仿真平臺與參數

本文使用軟件EXata進行所有的仿真實驗，EXata是美國SNT公司針對新型無線通信技術設計開發的網絡仿真系統，支持TCP/IP協議棧的標準層間接口，允許客戶對其核心代碼進行修改以實現并測試客戶自身實現的協議，由于采用先進的并行算法，其精確程度可以和真實網絡媲美。

吞吐量是評價一個網絡性能高低的重要參數，在對本文所提出的算法進行性能測試時所使用的評價標準就是網絡吞吐量。在本文進行的所有測試中，除了傳輸層所選用的協議以及節點移動性設置以外，包括節點位置信息在內的所有參數均不再變化。表1給出了幾項相對重要的仿真場景的參數，這些參數的設置在所有實驗中均不改變：

3.2 對比測試

（1）靜態場景測試

在圖6的仿真場景中，所有節點均不移動，僅改變傳輸層所使用的協議。當所有節點的傳輸層均使用NewReno協議時，多次重復實驗表明其網絡吞吐量維持在185.6kbps；當傳輸層協議換成基于確認機制實現的Semi-TCP協議時，網絡吞吐量維持在49.9kbps；當節點1-4使用NewReno作為傳輸層協議，而5-9節點使用Semi-TCP協議時，實驗結果各不相同，網絡吞吐量在49.9kbps到185.6kbps之間波動，多次仿真結果中從未出現高于185.6kbps的情況，但偶爾會低于49.9kbps，這證實了本文的猜想：當一條通信鏈路中的節點在傳輸層使用不同的擁塞檢測標準和擁塞解決方法時，如果不加以處理，其吞吐量會大大降低。這里取8次重復實驗的平均值作為混合場景的網絡吞吐量。

表1 場景固定參數

圖7 不考慮路由重建時各場景吞吐量對比（bps）

由仿真結果可以發現，在不考慮路由重建時，Ne?wReno協議是傳輸層更好的選擇，使用Semi-TCP協議的網絡吞吐量較低。在混合場景中，網絡吞吐量會受到Semi-TCP/ACK的限制，使得網絡吞吐量較之New Reno場景降低了43.6%，當使用本文方法進行中間節點的設置及優化后，較之優化前，網絡吞吐量提高了39.0%。

（2）動態場景測試

較之圖6的仿真實驗，這里設置所有節點具有隨機移動的屬性，其他參數均不改變，仿真結果如圖8所示。

在動態場景中，節點移動會導致路由信息的丟失，NewReno協議的吞吐量大幅降低，而Semi-TCP/ACK的吞吐量則大幅提高，原因在于實驗設置的仿真場景中節點的數量較少，而且為了保證實驗場景中僅存在一個中間節點，節點初始位置的選擇都不是隨機設置而導致的。

圖8 考慮路由重建時各場景吞吐量對比（bps）

混合場景的性能在這里受到了NewReno協議的限制，原因在于其對擁塞的誤判使得發送窗口頻頻降低，浪費了網絡帶寬資源。優化前的混合場景在吞吐量方面較之Semi-TCP降低了48.1%，而在優化后的場景中，吞吐量有所提高，較之Semi-TCP僅降低了25.9%。

由于TCP-AP是在TCP發送方檢測RTT變化來調整發送速率，因此其性能不會受到通信鏈路中其他節點傳輸層所設置的協議種類的影響。

4 結語

本文對一條通信鏈路中，當節點傳輸層使用不同的擁塞檢測標準及擁塞解決方法時所產生的影響進行分析，針對傳統TCP協議和Semi-TCP協議的共存情況提出一種解決方法，方法能夠在不改變傳統TCP協議的情況下檢測出中間節點。在靜態與動態場景的仿真分析中均驗證了使用不同擁塞檢測標準會導致網絡性能下降，并且，當在中間節點進行優化處理時，網絡性能會得到提高。本算法在不改變原有傳統TCP協議的情況下，使得配置了Semi-TCP協議的節點能夠檢測出中間節點，并在中間節點對不同發送方向的數據進行適當的延遲發送，提高了混合場景的吞吐量。