文獻標識碼： A
文章編號： 0258-7998(2013)06-0100-03
目前在Internet中廣泛使用且較為成熟的算法是TCP Reno，它通過觀測發送端數據包的丟失來估計當前網絡的可用帶寬，調整擁塞控制窗口以調節發送速率。TCP Vegas是TCP Reno的改進算法，其在發生丟包之前就可以根據往返時間RTT(Round Trip Time)來調整窗口大小。TCP Vegas比TCP Reno能夠更好地利用帶寬，且吞吐量穩定[1]。但是其自身也存在一些無法解決的問題，如公平性、響應不及時以及為保持吞吐量的穩定而不能最大限度地利用帶寬等問題，從而很大程度地限制了它的實際應用性。
以往的研究中,大多只對TCP Vegas的某一方面進行了改進[2-3]，雖然效果有所提升，但不能從根本上改變TCP Vegas存在的問題。本文通過建立TCP Vegas網絡的數學模型，從理論上分析了TCP Vegas在擁塞避免階段的競爭能力處于明顯劣勢的原因，并提出一種TCP Vegas擁塞避免機制的改進算法，分別從數學模型分析與網絡狀況仿真等兩個方面驗證了改進算法，該算法可以改變TCP Vegas擁塞避免機制所帶來的固有問題。
TCP Vegas根據預期傳送率和實際傳送率之間的差異值來調整cwnd的大小。當diff的值大于β時，意味著傳送速率太快，應該減小cwnd的值以減緩傳送的速率。反之，當diff的值小于α時，則表明傳送速率較慢，應該加大cwnd的值，以增加傳送的速率。
2 TCP Vegas存在的不足及原因分析
(1)路徑變更問題。由于Base_rtt是最小的回路響應延時。當文件傳輸過程中路徑發生變化時，如果新的路徑有一個較長的延時，TCP Vegas連接不能推斷這個長的rtt是由擁塞還是變更路徑造成的。由于TCP Vegas把rtt的增大都視為擁塞造成的，因此減少了擁塞窗口，進而導致吞吐量退化。
(2)不公平性問題。 由于期望吞吐量的計算是基于
Base_rtt的測量。當新的連接開始發送數據而其他的連接仍然存在時,其Base_rtt必定會大于其他連接的Base_rtt，因此它比其他的連接更容易增加擁塞窗口。新的連接能夠獲得更高的帶寬，從而導致在TCP Vegas連接中帶寬的不公平分配。
(3)帶寬利用問題。由于TCP Vegas為了保證其發送速率的穩定性，將rtt中的最小值作為Base_rtt來計算期望吞吐量，在很大程度上限制了發送窗口的增大，從而不能最大限度地利用有效帶寬,在保持穩定性的同時,犧牲了帶寬利用率。
(4)響應不及時問題。由于TCP Vegas擁塞避免階段所使用的rtt為所有rtt的平均值，因此rtt的變化不能隨著實時rtt的變化而及時變化，導致TCP Vegas對現有網絡擁塞狀況感知比較遲緩,不能對網絡變化及時做出響應。
(5)不兼容性問題。當TCP Vegas和TCP Reno共享一個瓶頸連接的時候，TCP Reno持續地增加窗口大小直到檢測到一個包的丟失。隨著TCP Reno窗口的不斷增大，鏈路中rtt的值會迅速增大，而TCP Vegas則認為這是擁塞信號，減少擁塞窗口,因此,TCP Reno會竊取TCP Vegas的帶寬，這種不兼容性限制了Vegas的采用。
3 TCP Vegas擁塞避免機制的算法改進
在TCP Vegas-N中，對Base_rtt和rtt的值選取方式做了改進，使其能夠與網絡情況動態聯系起來，并改進了diff的計算方法，使其更能及時準確地反應網絡狀況，從而較好地彌補了上述缺點，改進部分的代碼如下：
將rtt的取值由平均值改為實時值：
rtt = currentTime - v_begtime_；
將Base_rtt由最小值改為rtt的加權值，使Base_rtt隨著rtt變化而及時變化：
if (rttLen ≤ 1)
Base_rtt = rtt；
else
Base_rtt = Base_rtt*a+rtt*(1-a)；
其中a為0~1的加權因子，a值越小，Base_rtt隨rtt的變化越及時（本文實驗中a的取值為0.3）。
用新的計算公式來計算diff值：
b= Base_rtt/rtt；
diff=(1-b*b*b)*cwnd(t)+c;
其中c為常數，本文實驗中取值為0.999 999 999。α取1, β取3。
4 仿真實驗和性能分析
為了驗證改進算法的有效性，本文利用網絡仿真軟件NS2基于圖1中的拓撲結構對原始擁塞控制算法和改進算法進行了仿真實驗對比。
實驗2：驗證公平性問題。建立兩條鏈路，兩條鏈路相隔5 s開始，時間設為100 s。
圖4為TCP Vegas兩條鏈路相隔5 s后出發的擁塞窗口情況，后開始的鏈路的Base_rtt大于先前的Base_rtt，從而將會更大地增加發送窗口，導致了不公平性的發生。圖5為改進后的TCP Vegas擁塞窗口情況，保持了良好的公平性。
實驗3：驗證響應不及時問題。建立三條鏈路，兩條鏈路在0秒同時開始，第三條鏈路在第100秒開始，第200秒結束，總時間設為300秒。
在圖6中,當第三條鏈路在第100 s開始時，TCP Vegas只有第一條鏈路感知到了網絡擁塞變化，并降低了發送窗口。在第200秒時，當第三條鏈路結束發送，前兩條鏈路仍然保持原來發送窗口不變。而在圖7中，TCP Vegas-N可以根據網絡擁塞情況及時做出反應，既保證了各條鏈路的公平性，同時又充分利用了有效帶寬。
本文從Base_rtt和rtt的值選取方式入手，通過改進TCP Vegas擁塞避免算法，立足于解決TCP Vegas的固有問題。仿真實驗表明，改進后的算法有效地解決了TCP Vegas本身所存在的公平性、路由更換、帶寬利用和響應不及時等問題。本文給出了詳細的算法描述，該算法只需在發送端進行修改，不需要修改中間路由器，易于網絡實施。
參考文獻
[1] Chan Yicheng， LIN C L，CHAN C T，et al． Improving performance of TCP Vegas for high bandwidth-delay product networks[C]. Proc of the 8th International Conference on Advanced Communication Technology．2006：464．
[2] 李鵬，陳元琰，羅曉署．無線異構網絡環境中基于擁塞狀態區分的TCP Vegas改進算法[J]．計算機應用，2010，30(2):309－311．
[3] 王云濤，方建安，張曉輝．基于TCP Vegas的網絡擁塞控制改進算法[J]．計算機應用研究，2009，26(12)：4645－4647．
[4] BRAKMO L S， O′MALLEY S W， PETERSON L． TCP Vegas:New techniques for congestion detection and avoidance[J]．IEEE/ACM Transactions on Networking，1994，24(4)：1024－1035.