基于ＴＣＰ異構網絡的動態性能擴展代理

摘要：由于互聯網中大量異構網絡的存在，導致網絡的傳輸性能大大降低。為此，首先分析了異構網絡中TCP的性能特點，其次詳細介紹了如何通過增加PEP(performance enhancement proxies)的方法來改善異構網絡的傳輸性能。

關鍵詞：異構網絡; 性能擴展代理; 提前應答; 往返延遲

中圖分類號：TP393.01文獻標志碼：A

文章編號：1001-3695(2007)12-0324-03

0引言

隨著因特網的快速發展，其應用范圍越來越廣。但是傳輸距離、延遲、有效帶寬不同，導致很多結構不相同的局域網要進行互聯。這種結構的網絡稱為異構網絡，如衛星網絡、無線網絡、QoS網絡等。異構網絡進行互聯時，傳輸性能將大大下降。為了提高網絡的傳輸性能，本文首先分析在異構網絡中TCP的性能，然后介紹一種通過路由器支持的動態擁塞控制方法來改善TCP的性能。其中特別使用了性能擴展代理^[1]。

1傳統TCP的問題

為了描述異構網絡中TCP的性能指標，本文采用如圖1所示的網絡結構，并用NS2模擬軟件進行模擬。

圖1中，在A與C、D與B之間的連接模擬本地可達的網絡，并且它們固定為10 Mbps的帶寬和10 ms的延遲。C與D之間的連接模擬因特網中的異構網絡，并且它擁有不同的延遲（由參數d確定）和1 Mbps的帶寬，因此它是這個網絡的連接瓶頸。假設從A到B之間是一個長的TCP數據流，使用標準的TCP配置，如TCP NewReno，窗口大小為20，初始擁塞窗口為1，每個連接等待隊列大小為50。本文將比較B點的吞吐量。

首先來看在延遲與帶寬均不同的情況下TCP的性能。從圖2可以看到，隨著延遲的增加，吞吐量越來越低。這是因為一旦延遲變高，要達到有效帶寬所允許的最大吞吐量，在瓶頸連接處就需要較大的TCP窗口和較大的緩存。從圖2中還可以看到，隨著延遲時間變大，慢啟動的時間也變長，從而導致TCP的性能下降。這是非常重要的，因為在一個TCP連接中，慢啟動時間對吞吐量影響很大，特別是在Web通信中。較大的時延將嚴重影響TCP性能。

圖2所示的模擬結果說明，延遲和帶寬這兩個參數將嚴重影響網絡的吞吐量，從而導致TCP的性能下降。其原因在于TCP端到端的控制模型。標準的TCP使用定時的ACK包來估計當前可用的帶寬，并且使用加性增長和乘性減少的方法來對發送方的窗口大小作出反應。假如給標準TCP一個小的緩存，這種方法將變得無效，因為緩存的反應時間可能會比帶寬的變化速度還要慢，其結果將使TCP的性能下降。

2新的體系結構解決方法

為了改善性能，提高吞吐量，可以通過在異構網絡的邊緣路由器上設置PEP來控制TCP的數據流量（圖3）。其基本思路就是利用PEP來監控網絡中通過其TCP數據流中的ACK包。在PEP處故意加快或減慢ACKs的發送，從而改變發送方數據包的發送速度，使控制循環（發送方到PEP再到發送方）縮短以達到更好的擁塞控制并提高吞吐量。

2．1在PEP下的擁塞控制

如果假設網絡擁塞通常發生在不同網絡的邊界處， PEP便可以控制所有經過PEP的數據流，并且通過產生提前應答來達到提高吞吐量的目的。通常情況下，當接收方接收到一個數據包時，會給發送方發送一個ACK表示接收到數據；發送方只有在接收到ACK后才可能繼續發送下一個數據包。但是如果采用了PEP，每當有數據通過PEP時，它就會相應地產生一個premature ACK返回給發送方；發送方在接收到premature ACK后，就可以發送下一個數據包，從而縮短了RTT的時間，增加了發送數據包的數量，提高了吞吐量。

當使用premature ACK技術時，恢復那些被PEP確認過但可能丟失的包便成了PEP要解決的問題。因此，PEP必須要為那些已經被提前確認過但相應真實的ACK還沒有從接收方回到PEP的包提供一個緩存。當真實的ACK到達時，PEP必須從緩存中清除相應的數據包，并且丟棄這個真實的ACK（因為發送方已經提前接收到了premature ACK）。同時也要注意其他可能引起丟包的情況，如超時重傳。此外，PEP必須控制premature ACK的發送速度，以防止發送方發包的速度過快而導致PEP的緩存溢出。

在PEP中設置一個緩存來存儲每一個通過PEP的數據包，并且通過設置一個閾值（watermark）來表示緩存的狀態。 這個狀態信息將被用于控制TCP數據流中的ACK。當一個TCP數據流首次啟動時，PEP便相應地設定緩存的最大值和watermark的初始值。當一個TCP數據報文段到達邊緣路由器時，PEP將根據當前緩存大小和watermark來做以下工作：

a）如果當前緩存中數據包的數量小于watermark，PEP將拷貝這個報文段，并將其存入緩存；同時向發送方發送一個premature ACK，并將這個報文段標志為packed。

b）如果當前緩存中數據包的數量大于或等于watermark，但是小于最大的緩存大小，PEP也將拷貝這個報文段，并將其存入緩存，但是不產生premature ACK，并將這個報文段標志為stored。

c）如果當前緩存中數據包的數量大于或等于最大緩存大小（如緩存已滿），PEP什么也不做（如讓這個報文段就像沒有PEP一樣通過）。

當一個真實的ACK返回到PEP時，相應的數據報文段將從緩存中取出并清除掉。如果這個數據報文段已經標志為packed，路由器便丟棄這個ACK包。另外，由于這樣會縮短緩存長度，一些之前已經被標志為stored的報文段可能會下降且低于watermark。PEP將為這些報文段產生新的premature ACK，并且將它們的標志從stored改為packed。這就是說，PEP向發送方發出提示以發送更多的數據。

2．2閾值

從以上的討論中可以看出，watermark在PEP的擁塞控制中是一個很重要的變量。Watermark是該方法設計中一個很重要的點。Watermark將PEP緩存分成兩部分。當可用緩存長度下降到低于watermark時，表示TCP發送方發送速度過慢。因此，在這種情況下，PEP總是產生premature ACK。當可用緩存長度上升大于watermark時，表示TCP發送方發送速度過快。此時，PEP便抑制premature ACK的發送。當真實的ACK到來時，這些之前被抑制的premature ACK便可以被釋放。這樣，PEP便能夠使用TCP發送方的自同步（self－clocking）來控制它的發送速度。

在某種意義上，watermark決定了發送方向接收方發送數據的速度。由于這個最佳速度是基于當前可用帶寬的，watermark必須是動態的，不能固定不變。例如，緩存長度低于watermark并且可用帶寬下降，由于固定的watermark，PEP將仍然發送premature ACK來促使發送方發送更多的數據，這將導致緩存溢出和擁塞；如果可用帶寬上升，但是watermark沒有相應地作出改變，盡管網絡中可以傳輸更多的數據，PEP可能還是會抑制發送premature ACK，這將導致吞吐量達不到最大。

總結這個體系結構，PEP擁塞控制要優于傳統TCP的擁塞控制。當在異構網絡中發生擁塞時，傳統TCP中端節點發現有效帶寬變化要很長一段時間，而PEP擁塞控制就是要利用premature ACK來縮短TCP控制循環的反饋時間以避免產生該問題。

3模擬結果

筆者已經在NS2中實現了PEP體系結構。模擬設置除了將PEP代理置于節點C之外與圖1的結構一樣。C是異構網絡的邊緣路由器。在為新的模擬過程采集完數據之后，筆者將其與先前沒有PEP時的情況作了比較，并將這些數據做成了圖表，如圖4所示。標有“TCP”的曲線代表先前模擬過程所得的數據，標有“PEP”的曲線代表新的有PEP的模擬過程所得到的數據。

圖4比較了標準TCP和有PEP存在時的網絡基本吞吐量。結果表明有PEP存在時的吞吐量要比標準TCP的吞吐量提高了約100%。其原因首先在于premature ACK機制。在這個網絡模擬中，PEP收到發送方的數據報文段用了10 ms。所以每隔20 ms，一個premature ACK就可以回到發送方使其擁塞窗口加倍，然而標準TCP將花費220 ms或者420 ms來收到第一個ACK并使其擁塞窗口加倍。其次，在TCP傳輸中，PEP將調整watermark的值以改變緩存長度從而使發送方加快或減慢數據的發送速度，以達到最大的吞吐量。標準的TCP不能預先確定高的延遲，并且當有足夠帶寬時發送速度仍然很低，從而使吞吐量也低。

4結束語

國內外也有很多方法來處理TCP的性能問題。它們大多是通過采用一種新的TCP機制（如TCP擴展^[2]和新的算法^[3]）或者是一種不合理的配置（如極大的窗口大小）來對TCP進行修改。但是這些方法最大的缺點在于一開始就要搞清楚中間網絡的狀態并作出合理的配置。本文首先說明了在帶寬不同和延遲差距增大情況下TCP的性能，然后介紹了一種新的基于PEP的方法，使用了premature ACK和動態watermark機制來確保發送方與接收方之間數據流的傳輸速度，從而提高了網絡吞吐量。通過模擬試驗可以得出，在TCP的傳輸中，PEP更加適合于帶寬和延遲不同的異構網絡。

參考文獻：

[1]BORDER J， KOJO M， GRINER J， et al. RFC 3135， Performance enhancing proxies[S].2000.

[2]JACBSON V， BRADEN R， BORMAN D. IETF RFC 1323， TCP ex－

tensions for high performance[S].1992.

[3]FLOYD S， HENDERSON T. IETF RFC 2582， The NewReno modification to TCP’s fast recovery algorithm[S]. 1999.

[4]TANENBAUM A S.計算機網絡[M].3版.北京:清華大學出版社，1998:259-432.

[5]徐雷鳴，龐博，趙耀.NS與網絡模擬[M].北京:人民郵電出版社，2003.

[6]STEVENS W R. TCP/IP詳解 卷1:協議[M].北京:機械工業出版社，2002:223-359.

[7]ALLMAN M， DAWKINS S， GLOVER D， et al. RFC 2760， Ongoing TCP research rebated to satellites[S]. 2000.

[8]DUTTA D， ZHANG Y. An active proxy based architecture for TCP in heterogeneous variable bandwidth networks[C]//IEEE Global Telecommunications Conference. San Antonio: IEEE Press， 2001:2316-2320.

[9]OSADA S， YOKOHIRA T， WANG H， et al. Performance improvement of TCP using performance enhancing proxies－effect of premature ACK transmission timing on throughput[C]//Proc of the 6th Asia－Pacific Symposium on Information and Telecommunication Technologies(APSITT). 2005:7－12.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”