利用VPN網關改善遠程TCP傳輸性能的方法研究

摘 要:為了改善遠程TCP的傳輸性能，提出一種基于VPN網關的TCP代理方法，通過對TCP數據包的ACK確認號和通告窗口進行修改，屏蔽TCP發送端對于網絡丟包的感知，防止了擁塞窗口不必要的降低。實驗結果表明，這種方法可以有效地消除高丟包率所帶來的影響，提高了鏈路的利用率以及遠程TCP連接的傳輸速度。

關鍵詞:傳輸控制協議;丟包率;虛擬專用網;緩存技術

中圖分類號:TP393.02 文獻標志碼:A

文章編號:1001-3695(2010)03-1099-03

doi:10.3969/j.issn.1001-3695.2010.03.081

Method to improve performance of remote TCP connection using VPN gateway

CHEN Tao1，2，WANG Shao-lin1，2，ZHANG Xi-guang1，2，YAN Bao-ping1，2

(1.Computer Network Information Center， Chinese Academy of Sciences，Beijing 100190，China;2.Graduate School， Chinese Academy of Sciences， Beijing 100049， China)Abstract:To improve the performance of remote TCP connection，this paper proposed a method named TCP-Proxy on VPN gateway.Through the modification of acknowledge number field and window field in TCP header， VPN gateway shielded TCP sender from the perception of packet loss， and thus prevented the unnecessary reduction of congestion window. Experiment shows that this method can effectively eliminate the influence of high packet loss rate，therebyincrease the utilization of VPN network and the speed of remote TCP connection.

Key words:TCP; packet loss rate; VPN; buffer technology

0 引言

隨著計算機網絡和通信技術的飛速發展，網絡通信環境不斷改變，目前遠程的TCP連接占據了主導地位。傳輸路徑的增長導致數據包的丟失概率成倍增加，在AIMD[1]的窗口調整方式下，直接造成TCP傳輸的擁塞窗口持續偏小;同時遠程TCP連接的延遲(round-trip time， RTT)較大，數據包發送周期隨之變長，造成遠程TCP協議在大多數的時間里都處于等待狀態。上述現象的存在使得遠程的TCP連接不能獲得很好的傳輸性能，進而影響了遠程用戶之間的通信。

針對上述現象，研究者在傳輸層和應用層上做了大量的工作。HighSpeed TCP[2]、scalable TCP[3]、TCPM-AckCC[4]、ECN[5]等針對TCP協議本身進行修改，需要用戶在自己的操作系統內核中安裝相應的協議棧;而Reliable Blast UDP[6]、Tsunami[7]等應用層的研究則多是基于UDP協議開展，通過在應用層添加相應的傳輸控制避免修改傳輸層協議，但卻增加了自己的調用接口，需要應用程序針對此接口進行重寫。基于上述研究現狀，當前迫切需要在傳輸層之下引入新的重傳方式，降低TCP發送端對于網絡丟包的感知，進而改善遠程TCP連接的傳輸性能。而VPN網絡的出現為此研究的實現提供了便利條件。

本文提出了一種基于VPN網關的TCP代理(TCP-Proxy)機制，并在OpenVPN系統中加以實現:VPN網關通過修改ACK確認號和通告窗口的方式，屏蔽TCP發送端對于網絡丟包的感知，防止擁塞窗口的無謂降低，而丟失數據的重傳則交予VPN網關進行，保證數據的正確性和完整性。實際的測試表明，TCP代理機制可以有效地消除高延遲和高丟包率所帶來的影響，提高了TCP的穩定性以及遠程TCP連接的傳輸速度。

1 有丟包時穩態情況下TCP帶寬模型

對于有線網絡中的TCP而言，其傳輸性能主要取決于TCP數據在網絡中的延遲和傳輸的丟包率。對某一特定的TCP連接而言，假設其具有固定的延遲時間(RTT)，并且具有固定的丟包率p(周期性地第1/p個數據包丟失)，則在穩態情況下，此TCP連接將具有如圖1所示的擁塞窗口變化曲線。

由擁塞避免算法可知，在每次發生丟包以后，擁塞窗口將從當前最大值W變為W/2，從而使得穩態情況下TCP擁塞窗口的變化呈現周期性的鋸齒狀分布(每周期發生一次丟包)。由于此時擁塞窗口每RTT時間的增加量為1，使周期穩定為W/2個RTT時間(或RTT×W/2 s)，故可以得出每周期時間內TCP發送的數據包個數(data per cycle)為式(1)所示。

data per cycle=(W2)2+12(W2)2=38W2(1)

由于這里假設丟包率為p，故有1/p=3/8 W2，由此可以估算出穩態情況下TCP所取得的帶寬為式(2)所示。

BW=data per cycletime per cycle=MSS×38W2RTT×W2=MSS/pRTT23p(2)

實際的抓包分析表明，當前鏈路中TCP連接的MSS值多取為1 376 Byte，故對于0.001~0.7之間的丟包率以及1~700 ms之間的RTT而言，TCP連接有如圖2所示的帶寬變化曲線。

由圖2可以看出，在穩態情況下，TCP的帶寬將隨著丟包率和RTT的增大而急劇減小，這是因為大的丟包率會造成擁塞窗口的不斷減小，而大的RTT又增加了TCP的響應時間，從而急劇降低了TCP連接所能獲得的傳輸帶寬。而在上述兩種影響因素中，網絡延遲因受傳輸介質的影響無法改變(除非發明新的介質替代網線和光纖)，因此，如何降低網絡中的丟包率，并借此提升TCP的傳輸性能成為本文的關注點。

2 VPN的TCP-proxy機制

TCP協議要獲得較高的傳輸性能，需要有比較低的丟包率、比較小的延遲，這樣才能使得數據包具有很高的成功傳輸概率。本文引入新的TCP代理(TCP-Proxy)機制，通過在OpenVPN程序中對ACK確認號進行修改(VPN軟件取代TCP發送方進行數據的重傳恢復工作)，從而策略地屏蔽TCP協議對于隧道丟包的感知，同時ACK的修改從邏輯上將TCP連接分為兩段，從而降低了各段TCP連接的延遲。

2.1 OpenVPN中的數據封裝

OpenVPN借助于另一個開源的虛擬網卡(TUN/TAP驅動)項目來實現數據的隧道封裝工作。利用TUN/TAP驅動，可以將TCP/IP協議棧處理好的網絡分包傳送給任何一個使用TUN/TAP驅動的進程，由此進程重新處理后再發到實際的物理鏈路中，詳細的封裝格式如圖3所示(采用TAP封裝方式)。VPN隧道的引入近似于在TCP/IP網絡四層協議的基礎上進行擴展，將四層協議擴展為六層乃至更多，而OpenVPN作為中間數據處理所必須經過的一環，可以方便地對數據進行增添。這為本文算法的實現提供了實驗平臺。

2.2 TCP-Proxy機制的原理

TCP-Proxy選擇在OpenVPN上對TCP發送的數據包進行緩存，并根據緩沖區中緩存的數據情況來修改ACK的確認號。

圖4給出了對ACK確認號進行修改的示意圖，由于TCP client端安裝有OpenVPN軟件，其同時也作為VPN client端完成TCP數據的緩存和處理工作。

在圖4中，TCP server端發送序號為6401~7777的數據包到TCP client端，VPN server接收到此數據包，并將其緩存在自身的緩存隊列當中。由于先前序號為5025~6401的數據包在隧道的傳輸中發生丟失，故TCP client端在將此數據包緩存的同時，返回的ACK消息為ACK 5025，其含義為期望收到序號為5025的數據包。VPN server端在接收到此ACK消息之后，判斷此ACK消息是否為重復的ACK，如果是則進一步判斷ACK的重復是否達到三次。在ACK達到三次后，VPN server端將從自身的緩存隊列中取出序號為5025~6401的數據包，并將其重傳至TCP client端。在判斷是否為重復ACK之后，VPN server端將根據自身緩沖區的數據緩存情況，將ACK的確認號修改為7777，表示其期望接收到序號為7777的數據包。這樣，通過修改ACK消息和VPN server重傳數據包，成功地將表示數據包丟失的ACK 5025信息過濾。

由此可見，在采用TCP-Proxy機制以后，一條完整的TCP連接近似被分割為兩部分:TCP server到VPN server之間的TCP連接1和VPN server到TCP client之間通過隧道進行的TCP連接2，如圖5所示。

由于VPN多是被用于子網的接入，一般情況下，TCP ser-ver與VPN server多處于同一個子網之中，兩者之間的網絡常具有較小的延遲及較高的數據成功傳輸概率，故而TCP連接1普遍具有良好的傳輸性能。與之相對的TCP連接2因為隧道丟包和延遲的存在將成為整條TCP連接的瓶頸。這就意味著TCP連接2需要控制TCP連接1的發送速度，以免由于速度過快而產生VPN上緩沖區的溢出(由于VPN server上緩存有限)。

2.3 VPN接收緩沖的設定

由于VPN server的緩存空間有限，TCP-Proxy機制在修改ACK確認號的同時，也需要相應地修改TCP包頭中的16位通知窗口大小，以免發送方發送過多的數據沖垮VPN server和TCP client的緩存，進而造成TCP傳輸性能的下降。由于TCP client端接收緩沖的限制(為TCP協議的接收緩沖)，僅靠VPN server中接收緩沖的增加并不能提升整條TCP流的傳輸性能，本文中VPN server端緩沖大小的設定將與TCP協議保持一致，統一設置為87 380 Byte。

圖6給出了VPN接收緩沖更新的示意圖。在圖中，序列號為5025~6401的數據包同樣在隧道的傳輸中發生丟失，故TCP client端將發送“ACK 5025，win 5504”的數據包至通信對端，表示其期望收到的數據包序號為5025，并且TCP接收緩沖的右邊沿為5025+5504=10529;VPN server端接收到此消息后，得知序號在5025之前的數據包都已成功地被TCP client端接收，故將釋放其緩沖區中保存的序號在5025之前的數據，并更新自身緩沖區的右邊沿為10529;同時根據其自身的數據緩沖情況，將ACK的確認號修改為7777，并更新16位的通知窗口為10529-7777=2752。

通過上述的VPN接收緩沖更新機制，VPN server可以使其接收緩沖窗口與TCP client保持同步，從而有效限制TCP server端所發送的數據量，避免發送方發送過多數據，造成TCP傳輸性能下降。

2.4 實驗床測試與性能比較

本文在OpenVPN系統中實現了TCP-Proxy機制，并搭建實驗床進行了測試，測試的場景和參數如圖7和表1所示。圖8~13分別從TCP有效帶寬和TCP吞吐率的變化兩方面給出了相應的比較結果。

表1 有線網絡的實驗床參數設置

參數值

有線信道帶寬100 Mbps

測試時間100 s

圖8和9分別給出了采用TCP-Proxy機制后，在RTT為1.5 ms和300 ms的情況下，TCP傳輸帶寬隨網絡丟包率的變化情況。從圖中可以看出，與原始的OpenVPN相比，在丟包率較高的情況下，TCP-Proxy機制所取得的TCP帶寬將有較大提升(RTT為1.5 ms，丟包率為0.26時分別提高了5987.41%和1962.03%)，而在延遲和丟包率較低的情況下，TCP-Proxy機制的帶寬卻比原始OpenVPN要低(丟包率為0.05時降低了52.73%)。究其原因在于，TCP-Proxy機制在提高數據包傳輸可靠性的同時也引入了數據查找、加入和刪除，TCP校驗和的重新計算(由于ACK確認號和通知窗口的修改)以及特定TCP連接的定位等附加開銷。由于測試采用的VPN服務器性能不高，在數據傳輸速率較高的情況下，上述開銷將直接對VPN服務器的性能造成較大影響，從而造成了低丟包率時TCP帶寬的降低。

圖10和11給出的TCP吞吐率變化曲線也同樣證明了TCP-Proxy的有效性。在采用TCP-Proxy機制之后，由于TCP發送端不會頻繁感受到丟包現象的產生，故而能保持較高的擁塞窗口。此時TCP協議可以獲得更加穩定的吞吐率，而不會出現像原始OpenVPN機制那樣的大幅抖動。

圖12和13同樣給出了RTT為300 ms時TCP吞吐率的變化曲線。從圖中可以看出，在采用TCP-Proxy機制之后，TCP的吞吐率有了較大的提升，并且消除了TCP吞吐率由于超時而降為零的現象。但圖示所表示出來的吞吐率還存在較大的波動，這是由于1 s的采樣時間相對于300 ms的RTT而言太小(僅為2~3個傳送周期)，從而造成了TCP吞吐率的波動。

由上述測試結果可知，在采用TCP-Proxy機制以后，由于屏蔽了隧道內層的TCP協議對于丟包的感知，使得TCP協議可以一直保持較大的擁塞窗口，提升了TCP的傳輸有效帶寬(特別是高誤碼率和高延時狀態下的帶寬)，同時使得TCP協議能夠獲得較為平穩的吞吐率，從而全面提升了TCP協議的傳輸性能。

3 結束語

TCP-Proxy機制能夠屏蔽內層TCP協議對丟包的感知，在高延遲和高誤碼率的情況下依然能取得較好的傳輸性能，但從具體的測試結果來看，TCP-Proxy機制的性能還沒有達到最優性能，存在進一步改進的空間。

首先，雖然TCP-Proxy機制可以使得TCP發送端保持較高的擁塞窗口，但是由圖8來看，在RTT為1.5 ms的情況下，當丟包率小于0.08時，其性能卻比原始的VPN傳輸要低。其中雖然有VPN服務器性能的牽制，但接收端窗口所帶來的影響也是一個主要原因:由于此時發送端TCP的擁塞窗口保持較大，故此時的傳送速度主要受接收端窗口限制。其次，由圖9可以看出，在延遲較大的情況下，雖然TCP-Proxy比原始的VPN機制具有更好的傳輸性能，但其所獲得的傳輸帶寬依舊不高，究其原因是由于較高RTT的影響所引起的。由于

降低TCP連接的延遲(主要延遲存在于隧道段)，同時分割后的TCP連接緩沖也沒有任何增加，故而整條TCP的傳輸性能并不能得到較大提升。

上述兩個問題可以通過加大VPN隧道的緩沖區進一步得到改善。具體的做法是將TCP連接分割為TCP server-VPN server、VPN server-VPN client、VPN client-TCP client三段，而在VPN隧道的兩端采用較大的緩沖區，以提升整條TCP連接的傳輸性能。這部分改進工作將在以后的研究工作中加以實現。

參考文獻:

[1]

CHIU D，JIAN R.Analysis of the increase and decrease algorithm for congestion avoidance in computer networks[J].Computer Networks and ISDN System，1989，17(1):1-14.

[2]FLOYD S.RFC 3649，HighSpeed TCP for large congestion windows[S].2003.

[3]KELLY T.Scalable TCP:improving performance in high-speed wide area networks[J].ACM SIGCOMM Computer Communication Review，2003，33(2):83-91.

[4]FLOYD A，ARCIA A，ROS D，et al.Adding acknowledgement congestion control to TCP[R/OL].(2009-07-04).http://tools.ietf.org/html/draft-floyd-tcpm-ackcc-06.

[5]KUZMANOVIC A，MONDAL A，FLOYD S，et al.RFC 5562，adding explicit congestion notification (ECN) capability to TCP’S SYN/ACK pockets[S].2009.

[6]HE E，LEIGH J，YU O，et al.Reliable Blast UDP:predictable high performance bulk data transfer[C]//Proc of IEEE International Confernece on Cluster Computing.Washington，DC:IEEE Computer Society，2002:317-324.

[7]MEISS M R.Tsunami:a high-speed rate-controlled protocol for file Transfer[EB/OL].(2004-09-28).http://steinbeck.ucs.indiana.edu/~mmeiss/papers/tsunami.pdf.