目前在Internet中廣泛使用且較為成熟的算法是TCP Reno，它通過觀測(cè)發(fā)送端數(shù)據(jù)包的丟失來估計(jì)當(dāng)前網(wǎng)絡(luò)的可用帶寬，調(diào)整擁塞控制窗口以調(diào)節(jié)發(fā)送速率。TCP Vegas是TCP Reno的改進(jìn)算法，其在發(fā)生丟包之前就可以根據(jù)往返時(shí)間RTT(Round Trip Time)來調(diào)整窗口大小。TCP Vegas比TCP Reno能夠更好地利用帶寬，且吞吐量穩(wěn)定[1]。但是其自身也存在一些無法解決的問題，如公平性、響應(yīng)不及時(shí)以及為保持吞吐量的穩(wěn)定而不能最大限度地利用帶寬等問題，從而很大程度地限制了它的實(shí)際應(yīng)用性。

    以往的研究中,大多只對(duì)TCP Vegas的某一方面進(jìn)行了改進(jìn)[2-3]，雖然效果有所提升，但不能從根本上改變TCP Vegas存在的問題。本文通過建立TCP Vegas網(wǎng)絡(luò)的數(shù)學(xué)模型，從理論上分析了TCP Vegas在擁塞避免階段的競(jìng)爭(zhēng)能力處于明顯劣勢(shì)的原因，并提出一種TCP Vegas擁塞避免機(jī)制的改進(jìn)算法，分別從數(shù)學(xué)模型分析與網(wǎng)絡(luò)狀況仿真等兩個(gè)方面驗(yàn)證了改進(jìn)算法，該算法可以改變TCP Vegas擁塞避免機(jī)制所帶來的固有問題。

    TCP Vegas根據(jù)預(yù)期傳送率和實(shí)際傳送率之間的差異值來調(diào)整cwnd的大小。當(dāng)diff的值大于β時(shí)，意味著傳送速率太快，應(yīng)該減小cwnd的值以減緩傳送的速率。反之，當(dāng)diff的值小于α時(shí)，則表明傳送速率較慢，應(yīng)該加大cwnd的值，以增加傳送的速率。
2 TCP Vegas存在的不足及原因分析
    (1)路徑變更問題。由于Base_rtt是最小的回路響應(yīng)延時(shí)。當(dāng)文件傳輸過程中路徑發(fā)生變化時(shí)，如果新的路徑有一個(gè)較長(zhǎng)的延時(shí)，TCP Vegas連接不能推斷這個(gè)長(zhǎng)的rtt是由擁塞還是變更路徑造成的。由于TCP Vegas把rtt的增大都視為擁塞造成的，因此減少了擁塞窗口，進(jìn)而導(dǎo)致吞吐量退化。
   (2)不公平性問題。 由于期望吞吐量的計(jì)算是基于
Base_rtt的測(cè)量。當(dāng)新的連接開始發(fā)送數(shù)據(jù)而其他的連接仍然存在時(shí),其Base_rtt必定會(huì)大于其他連接的Base_rtt，因此它比其他的連接更容易增加擁塞窗口。新的連接能夠獲得更高的帶寬，從而導(dǎo)致在TCP Vegas連接中帶寬的不公平分配。
   (3)帶寬利用問題。由于TCP Vegas為了保證其發(fā)送速率的穩(wěn)定性，將rtt中的最小值作為Base_rtt來計(jì)算期望吞吐量，在很大程度上限制了發(fā)送窗口的增大，從而不能最大限度地利用有效帶寬,在保持穩(wěn)定性的同時(shí),犧牲了帶寬利用率。
    (4)響應(yīng)不及時(shí)問題。由于TCP Vegas擁塞避免階段所使用的rtt為所有rtt的平均值，因此rtt的變化不能隨著實(shí)時(shí)rtt的變化而及時(shí)變化，導(dǎo)致TCP Vegas對(duì)現(xiàn)有網(wǎng)絡(luò)擁塞狀況感知比較遲緩,不能對(duì)網(wǎng)絡(luò)變化及時(shí)做出響應(yīng)。
    (5)不兼容性問題。當(dāng)TCP Vegas和TCP Reno共享一個(gè)瓶頸連接的時(shí)候，TCP Reno持續(xù)地增加窗口大小直到檢測(cè)到一個(gè)包的丟失。隨著TCP Reno窗口的不斷增大，鏈路中rtt的值會(huì)迅速增大，而TCP Vegas則認(rèn)為這是擁塞信號(hào)，減少擁塞窗口,因此,TCP Reno會(huì)竊取TCP Vegas的帶寬，這種不兼容性限制了Vegas的采用。
3 TCP Vegas擁塞避免機(jī)制的算法改進(jìn)
    在TCP Vegas-N中，對(duì)Base_rtt和rtt的值選取方式做了改進(jìn)，使其能夠與網(wǎng)絡(luò)情況動(dòng)態(tài)聯(lián)系起來，并改進(jìn)了diff的計(jì)算方法，使其更能及時(shí)準(zhǔn)確地反應(yīng)網(wǎng)絡(luò)狀況，從而較好地彌補(bǔ)了上述缺點(diǎn)，改進(jìn)部分的代碼如下：
　    將rtt的取值由平均值改為實(shí)時(shí)值：
　    rtt = currentTime - v_begtime_；
　    將Base_rtt由最小值改為rtt的加權(quán)值，使Base_rtt隨著rtt變化而及時(shí)變化：
　    if (rttLen ≤ 1)
　        Base_rtt = rtt；
    else
　　      Base_rtt = Base_rtt*a+rtt*(1-a)；
    其中a為0~1的加權(quán)因子，a值越小，Base_rtt隨rtt的變化越及時(shí)（本文實(shí)驗(yàn)中a的取值為0.3）。
    用新的計(jì)算公式來計(jì)算diff值：
　　b= Base_rtt/rtt；
　    diff=(1-b*b*b)*cwnd(t)+c;
其中c為常數(shù)，本文實(shí)驗(yàn)中取值為0.999 999 999。α取1, β取3。
4 仿真實(shí)驗(yàn)和性能分析
    為了驗(yàn)證改進(jìn)算法的有效性，本文利用網(wǎng)絡(luò)仿真軟件NS2基于圖1中的拓?fù)浣Y(jié)構(gòu)對(duì)原始擁塞控制算法和改進(jìn)算法進(jìn)行了仿真實(shí)驗(yàn)對(duì)比。

    實(shí)驗(yàn)2：驗(yàn)證公平性問題。建立兩條鏈路，兩條鏈路相隔5 s開始，時(shí)間設(shè)為100 s。
    圖4為TCP Vegas兩條鏈路相隔5 s后出發(fā)的擁塞窗口情況，后開始的鏈路的Base_rtt大于先前的Base_rtt，從而將會(huì)更大地增加發(fā)送窗口，導(dǎo)致了不公平性的發(fā)生。圖5為改進(jìn)后的TCP Vegas擁塞窗口情況，保持了良好的公平性。

    實(shí)驗(yàn)3：驗(yàn)證響應(yīng)不及時(shí)問題。建立三條鏈路，兩條鏈路在0秒同時(shí)開始，第三條鏈路在第100秒開始，第200秒結(jié)束，總時(shí)間設(shè)為300秒。
    在圖6中,當(dāng)?shù)谌龡l鏈路在第100 s開始時(shí)，TCP Vegas只有第一條鏈路感知到了網(wǎng)絡(luò)擁塞變化，并降低了發(fā)送窗口。在第200秒時(shí)，當(dāng)?shù)谌龡l鏈路結(jié)束發(fā)送，前兩條鏈路仍然保持原來發(fā)送窗口不變。而在圖7中，TCP Vegas-N可以根據(jù)網(wǎng)絡(luò)擁塞情況及時(shí)做出反應(yīng)，既保證了各條鏈路的公平性，同時(shí)又充分利用了有效帶寬。

    本文從Base_rtt和rtt的值選取方式入手，通過改進(jìn)TCP Vegas擁塞避免算法，立足于解決TCP Vegas的固有問題。仿真實(shí)驗(yàn)表明，改進(jìn)后的算法有效地解決了TCP Vegas本身所存在的公平性、路由更換、帶寬利用和響應(yīng)不及時(shí)等問題。本文給出了詳細(xì)的算法描述，該算法只需在發(fā)送端進(jìn)行修改，不需要修改中間路由器，易于網(wǎng)絡(luò)實(shí)施。
參考文獻(xiàn)
[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] 李鵬，陳元琰，羅曉署．無線異構(gòu)網(wǎng)絡(luò)環(huán)境中基于擁塞狀態(tài)區(qū)分的TCP Vegas改進(jìn)算法[J]．計(jì)算機(jī)應(yīng)用，2010，30(2):309－311．
[3] 王云濤，方建安，張曉輝．基于TCP Vegas的網(wǎng)絡(luò)擁塞控制改進(jìn)算法[J]．計(jì)算機(jī)應(yīng)用研究，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.