文獻標識碼： A
隨著通信網絡的不斷發展，不同類型的網絡并存成為目前通信領域的一種普遍現象，有線/無線混合網絡成為目前通信研究的一個熱點，通常情況下這種有線/無線混合網絡被稱為異構網絡。異構網絡的整體性能受TCP協議算法的影響，所以提高TCP協議性能對提高異構網絡的整體性能來說是非常必要的。目前應用最廣泛的TCP協議是TCP Reno協議，它是為有線網絡設計的，在有線網絡環境中性能表現良好。由于異構網絡中有著較高的誤碼率，較大的帶寬延時積，鏈路帶寬不對稱等特性，使得傳統的TCP Reno協議應用在異構網絡環境中性能低下。因此如何提高異構網絡下的TCP性能已經成為了一個研究熱點[1-3]。
目前改善TCP協議在異構網絡環境下的性能的方法主要分為以下三類：鏈路層方法、分離連接方法和端到端方法。
鏈路層方法是通過本地重傳和前向糾錯屏蔽發送端與鏈路相關的丟包。但由于鏈路層協議與高層協議都有獨立的差錯控制功能，存在一定的重復性，相互競爭會降低無線信道的利用率，導致端到端吞吐量下降。代表性協議是Snoop[4]。
分離鏈接方法是在基站處將TCP連接分成有線連接和無線連接兩部分：有線連接部分使用傳統的TCP協議，無線連接部分使用改進的TCP協議。它破壞了端到端的TCP語義連接性。代表性協議是Indirect-TCP[5]。
端到端方法只修改TCP發送端和接收端的協議，保證了端到端的TCP語義連接性。代表性協議是TCP Westwood[6]。該協議在發端監視收到的ACK數據流，并以此來估計當前鏈路的可用帶寬。一旦丟包，發端將利用估計的帶寬對慢啟動閾值和擁塞窗口進行適當設置，保證了網絡的快速恢復并可更有效地避免擁塞。
本文提出了一種適用于異構網絡的TCP算法TCP -BM(TCP Based Measurement),其基本思想是利用往返時延RTT來控制擁塞窗口的增長速度，使發送窗口穩定在一個比較理想的狀態，在網絡發生丟包后，通過對RTT的實時分析判斷出丟包原因，從而采取相應的控制措施。
1 傳統TCP Reno協議及分析
1.1 TCP Reno協議流程
TCP Reno協議包括慢啟動、擁塞避免、快速重傳和快速恢復4個階段：
(a)慢啟動階段：TCP將擁塞窗口值設為1，發送端每收到一個新的ACK就把擁塞窗口值增加一個，即W=W+1，W表示擁塞窗口；
(b)擁塞避免階段：發送端每收到一個新的ACK就把擁塞窗口值增加擁塞窗口值的倒數，即W=W+1/W；
(c)丟包標志為3個重復ACK：發送端重傳丟失的包，并且在窗口范圍內繼續發送新的數據包，此后發送端每收到1個重復的ACK就將擁塞窗口值增加1；
(d)丟包標志為計時器超時：發送端重傳丟失的包，然后將慢啟動閾值設為當前窗口的一半，將擁塞窗口設為1。
因為TCP協議是端到端的協議，因此這里的說明只涉及發送端和接收端。在連接開始時，發送端執行(a), 直到擁塞窗口值大于(或等于)慢啟動閾值或者出現丟包：(1)如果是出現丟包，發送端執行策略與丟包標志相關，如果丟包標志為3個重復ACK,則發送端執行(c), 直到發送端收到新的ACK為止，然后發送端TCP將擁塞窗口和慢啟動閾值都設為快速重傳前擁塞窗口值的一半，重新開始擁塞避免階段；如果丟包標志為計時器超時，則發送端執行(d)，重新開始慢啟動階段；(2)如果是擁塞窗口大于(或等于)慢啟動閾值，則發送端執行(b),該策略一直持續到出現丟包為止，一旦出現丟包，發送端執行策略同慢啟動階段出現丟包時采取的策略一樣。
1.2 TCP Reno協議分析
快速恢復算法避免了在快速重傳之后通道為空的現象，從而避免了在單個報文丟失后重新開始慢啟動階段。TCP發送端在每個往返時延內最多重傳1個包，因此在只有1個數據包丟失的情況下，該協議性能最佳。當1個窗口中有2個報文丟失時，在TCP發送端快速重傳和快速恢復就將被執行2次，因為在快速恢復階段窗口的調整策略為ssthresh=cwnd/2,cwnd=ssthresh，因此慢啟動閾值和擁塞窗口都將被減小2次，這是不必要的。當有更多數據包丟失時，根據Reno協議TCP發送端就必須等待重發計時器超時才能恢復。
2 TCP-BM協議
該算法的基本思想是在慢啟動階段根據網絡的實時狀況來合理地調節擁塞窗口的增長速度；將擁塞避免過程分為正增長過程和負增長過程，從而使發送窗口穩定在比較理想的狀態而有預見性地避免擁塞。在網絡發生丟包后，通過對RTT的實時分析以及估計的帶寬判斷出丟包原因，從而采取不同的恢復措施。下面詳細介紹TCP-BM協議的幾個階段，未說明部分沿用傳統的TCP Reno協議。
2.1慢啟動階段
開始時數據量較少，對帶寬的利用率較低，因此可以使擁塞窗口較快地增長；當擁塞窗口增大到一定程度時，減小其增長速度，使其相對緩慢并且平滑地增加；最后當擁塞窗口的大小接近于慢啟動閾值時，再次減小其增加速度，使其更加緩慢且平滑地接近于慢啟動閾值。算法描述如下：
If (cwnd<ssthresh)
If (cwnd*(1+(double)(rtt/rttmin)) <ssthresh)
cwnd+=(double)(rtt/rttmin);
else if (2*cwnd < ssthresh)
cwnd+=1;
else cwnd+=(double)(rttmin/ rtt)
其中，cwnd表示擁塞窗口;ssthresh表示慢啟動閾值，rtt表示當前的往返時延值,它反映當前的網絡狀態；rttmin表示往返時延歷史數據中的最小值，它反映歷史上網絡的最好狀態。在連接開始時，擁塞窗口大小設為1，以后每收到一個ACK，擁塞窗口就增加(double)(rtt/rttmin)；擁塞窗口增大到一定程度時降低其增長速度，變為每收到一個ACK，擁塞窗口就增加1；最后當擁塞窗口接近于慢啟動閾值時，擁塞窗口以更緩慢的方式進行增長，cwnd+=(double)(rttmin/rtt)， 直到擁塞窗口大于(或等于)慢啟動閾值或者出現丟包為止。
2.2 擁塞避免階段
當擁塞窗口大于(或等于)慢啟動閾值后，TCP發送端發送的數據量已經向網絡所能容忍的一個限度靠近，此時不能再使擁塞窗口像慢啟動階段那樣快速地增長，因此利用往返時延值將此階段分為正增長和負增長2個階段，使傳輸過程能更長時間地穩定在該階段。算法描述如下：
if（(rtt/rttmin)< A
cwnd = cwnd + B1*increment;
else
cwnd = cwnd - B2*increment;
令T=rtt/rttmin，則T表示當前往返時延值是往返時延歷史數據中的最小值的多少倍，即當前的網絡狀態比歷史上網絡的最好狀態差多少；A表示擁塞閾值,即當前往返時延值達到往返時延歷史數據中的最小值的A倍時，網絡將趨于擁塞。在擁塞避免階段，如果T≥A,則說明網絡趨于擁塞，此時TCP發送端不宜再增加擁塞窗口，相反，TCP發送端將減小擁塞窗口以避免擁塞，擁塞窗口減小策略為cwnd=cwnd-B2*increment，B2>0；如果T<A,說明網絡還沒有趨于擁塞，此時TCP發送端可以增加擁塞窗口大小，進一步提高網絡帶寬利用率，擁塞窗口增加策略為cwnd=cwnd+B1*increment，B1>0； B1、B2為調整因子，B1用來增加擁塞窗口的大小，過大會使擁塞窗口增長過快，容易導致擁塞丟包，過小則無法充分利用網絡資源；B2用來減小擁塞窗口的大小，有預見性地避免擁塞。B1、B2相互制約，使得擁塞窗口在增大到一定程度以后開始減小，這樣可以使擁塞窗口維持在一個理想的發送狀態，而使網絡不至于發生擁塞。經過多次仿真分析A取1.5，B1取1，B2取0.5能達到較好的性能。
2.3快速重傳和快速恢復
網絡發生丟包后，TCP發送端采取快速重傳措施，重傳丟失的報文，然后根據丟包標志的不同，通過比較最新的往返時延值和前一次的往返時延值以及估計的帶寬值來區分丟包原因，從而采取不同的控制措施。算法描述如下：
If (dupacks)
if(rtt>=lastrtt&&bw2<bw1)
ssthresh= cwnd /2, cwnd =ssthresh;
if (timeout)
ssthresh=cwnd/2,cwnd=1;
其中，dupacks表示3個重復ACK的情況，lastrtt表示上一次的往返時延值，bw2和bw1分別表示第二個重復ACK時的測量帶寬和第三個重復ACK時的測量帶寬(bw1=d/(t2-t1)，bw2=d/(t3-t2),d表示ACK所確認的報文段的長度，t1表示第一個重復ACK到來的時間，t2表示第二個重復ACK到來的時間，t3表示第三個重復ACK到來的時間），timeout表示計時器超時的情況。當丟包標志為dupacks時，如果rtt≥lastrtt并且bw2<bw1，則認為是網絡擁塞導致丟包，因此需要減小擁塞窗口和慢啟動閾值，調整策略與傳統的TCP Reno協議方法相同；否則就認為是無線誤碼導致網絡丟包，對慢啟動閾值和擁塞窗口值不做調整。當丟包標志為timeout時，因為計時器超時是比3個重復ACK更嚴重的情況，所以此處沿用傳統的方法對擁塞窗口和慢啟動閾值進行調整，其調整策略見算法描述。
3 性能分析
在ns-2[7]仿真平臺上進行仿真，其網絡拓撲如圖1所示。網絡拓撲由3段鏈路和4個節點組成，其中S表示TCP發送端，R表示路由器，BS表示基站，D表示TCP接收端，有線部分包括從發送端到路由器，從路由器到基站兩部分，最后一段為無線部分。其中發送端與路由器之間的有線鏈路帶寬為100 Mb/s，延遲為1 ms，路由器與基站之間的有線鏈路帶寬為100 Mb/s， 延遲為49 ms，基站與接收端之間的無線鏈路帶寬為1 Mb/s,延遲為0.01 ms。數據包的大小采用固定長度，其值設為1 000 byte，無線誤碼率設為0，仿真時間設為200 s,且只采用一個FTP數據流，該數據流在10 s開始，在200 s結束。
在上述仿真環境下比較TCP-BM協議和TCP Reno協議擁塞窗口隨時間的變化情況，結果如圖2所示。
圖2中，橫軸表示時間，單位為s，縱軸表示擁塞窗口大小，單位為packet。從圖2中不難看出，在整個200 s的仿真過程中，TCP Reno協議的擁塞窗口大小隨時間的變化非常劇烈，而TCP-BM協議的擁塞窗口的大小除了出現少數幾次較為劇烈的波動之外，其余時間變化則較為平緩。對仿真追蹤所得到的實驗數據進行統計分析，TCP Reno協議的擁塞窗口最小值為1，最大值為26，且變化頻繁，變化范圍集中在10~18；而TCP-BM協議的擁塞窗口最小值為1，且只出現了屈指可數的幾次，最大值為21，穩定之后變化范圍集中在13~17。
對擁塞窗口值在時間上進行平均，TCP Reno協議的擁塞窗口平均值大小為13.10，而TCP-BM協議的擁塞窗口平均值大小為14.03,這說明TCP-BM協議發送量比TCP Reno協議有明顯增加，這必將會導致業務吞吐量的提高。
對擁塞窗口值的方差在時間上進行平均可得TCP Reno協議的擁塞窗口值的平均方差大小為28.86，而TCP-BM協議的擁塞窗口值的平均方差為1.72，這表明了TCP-BM協議的擁塞窗口變化情況要比改進前緩和得多，說明了TCP-BM協議的帶寬利用率較為穩定。
對TCP Reno協議和TCP-BM協議吞吐量變化情況進行比較，結果如圖3所示。
圖3中，橫軸表示時間，單位為s，縱軸表示吞吐量，單位為kb/s。從圖3中可以明顯看出，TCP-BM協議的吞吐量比TCP Reno協議有明顯的提高。對仿真數據進行統計分析可知，TCP Reno協議的吞吐量從零開始，然后急劇增加，增加到500 kb/s左右后發生波動，且波動幅度較大，60 s后趨于穩定，最終穩定在540 kb/s左右；TCP-BM協議的吞吐量從零開始，然后急劇增加，增加到600 kb/s左右開始緩慢地上升，分別在50 s和145 s左右時出現2次相對大的波動，這是因為出現了計時器超時的情況。圖2中TCP-BM的擁塞窗口波動也可以說明這一問題。最終其吞吐量穩定在644 kb/s左右，TCP-BM協議的吞吐量比TCP Reno協議提高了大約19.3%。
最后對丟包率進行統計分析，對上述仿真結果進行計算可得，TCP Reno協議的丟包率為1.65%，而TCP-BM協議的丟包率為0.21%，對其進行比較可發現，TCP-BM協議的丟包率比TCP Reno協議的丟包率減小了1.44%，這也從一定程度上說明了TCP-BM協議的吞吐量比TCP Reno協議的吞吐量有所提高。
在傳統的TCP Reno協議的基礎上提出了一種適用于異構網絡的TCP擁塞控制協議，該協議在慢啟動階段根據往返時延值適當調整擁塞窗口的增長速度，在擁塞避免階段利用當前的往返時延與往返時延的歷史最小值的比值來控制擁塞窗口的增加與減小，不但能充分利用網絡資源，并且在一定程度上可以有預見性地避免擁塞，當網絡發生丟包后，通過比較當前的往返時延值與歷史記錄以及比較測量的帶寬，從而區分丟包原因，對擁塞窗口和慢啟動閾值采取不同調整策略。經過仿真驗證，改進后的TCP算法性能優于傳統的TCP Reno協議。下一步工作是要進一步改進該算法，使之適用于更復雜的網絡環境。
參考文獻
[1] 曲大鵬，黃東軍. 一種新的適用于異構網絡的TCP算法[J]. 計算機應用， 2007,27(10):2437.
[2] 葛鴿，張國清.一種適用于異構網絡的TCP協議設計及其仿真[J].系統仿真學報,2004,16(12):2875.
[3] 葉進，王建新，龔皓. 無線/有線網絡中基于自適應丟包區分的TCP改進[J].通信學報，2007,28(5):15-16.
[4] BAL K H, SASHA S, KATE R H. Improving reliable transport and handoff performance in cellular wireless networks[J]. ACM，Wireless Networks, 1995,1(4)：469-481.
[5] BAKER A, BADRINATH B R. I-TCP: Indirect TCP for mobile hosts[A]. In the Proceedings of the 15th International Conference on Distributed Computing Systems,1995：136-143.
[6] CASETTI C, GERLA M, MASCOLO S, et al. TCP Westwood: Bandwidth estimation for enhanced transport over wireless links[A]. In Proceedings of ACM Modicums, 2001:287-297.
[7] The network simulator - ns-2 [EB/OL]. http://www.isi.edu/nsnam/ns/