廈門工學(xué)院，福建廈門 361024

一、引言

近來，隨著移動互聯(lián)網(wǎng)的飛速發(fā)展，人們的生活方式發(fā)生了翻天覆地地變化。通過移動通信設(shè)備來網(wǎng)絡(luò)購物，網(wǎng)上訂餐或者是視頻會議等等，給人們的生活和工作帶來很多的便利。但是移動互聯(lián)網(wǎng)的訪問速度慢，訪問失敗率高以及視頻播放不流暢等用戶體驗差的問題仍時常困擾著人們。因此，如何提高人們在移動互聯(lián)網(wǎng)的用戶體驗成了首要問題。

優(yōu)化服務(wù)器端的TCP協(xié)議是提高無線網(wǎng)絡(luò)中的用戶體驗的方法之一。傳統(tǒng)的TCP協(xié)議是為有線鏈路設(shè)計的。在有線的應(yīng)用環(huán)境下，TCP對于端到端的延遲和包丟處理顯示出優(yōu)越的性能。主要原因是位出錯率較低，鏈路性能好，主機(jī)比較固定[1]。但是在無線網(wǎng)絡(luò)接入現(xiàn)有的Internet網(wǎng)絡(luò)中，由于無線網(wǎng)絡(luò)的鏈路特性問題，使得在沒有擁塞的情況下啟動擁塞控制，從而使TCP在無線網(wǎng)絡(luò)中性能大大降低[2]。

本文通過NS2軟件模擬仿真幾種常用TCP算法在無線網(wǎng)絡(luò)中吞吐量和發(fā)包行為，并選出一種最適合無線網(wǎng)絡(luò)的擁塞算法，以提高人們在移動互聯(lián)網(wǎng)中的用戶體驗。

二、TCP擁塞算法概述

TCP Reno算法是現(xiàn)有眾多算法的基礎(chǔ)，包括慢啟動、擁塞避免、快速恢復(fù)以及快速重傳機(jī)制。但它為了平衡必須周期性地產(chǎn)生一些丟包，再用AIMD（加式增加，乘式減少）的機(jī)制來調(diào)整，這樣導(dǎo)致帶寬的利用率不高。

TCP Vegas是通過計算期望值的吞吐量與實際吞吐量的差值來估計網(wǎng)絡(luò)瓶頸處的可用帶寬。這樣Vegas不用依靠丟包就能檢測到網(wǎng)絡(luò)擁塞，從而在丟包前就進(jìn)行擁塞避免，能減少數(shù)據(jù)丟包，并更有效的利用帶寬[3]。

TCP Veno 采用類似Vegas的機(jī)制來判斷網(wǎng)絡(luò)的擁塞狀態(tài)，通過判斷丟包的性質(zhì)來采取不同的擁塞控制策略。當(dāng)網(wǎng)絡(luò)處于真正的擁塞時，采用TCP Reno的擁塞控制機(jī)制，當(dāng)網(wǎng)絡(luò)丟包是由誤碼等原因產(chǎn)生的隨即丟包時，采用一種擁塞控制機(jī)制[4]。

TCP Westwood算法通過檢測應(yīng)答ACK返回發(fā)送端的速率估算網(wǎng)絡(luò)的可用帶寬，并利用估算出的可用帶寬計算出擁塞窗口cwnd以及慢啟動閾值ssthresh，從而進(jìn)行流量控制以改善網(wǎng)絡(luò)的擁塞狀況[5]。

表1 無線鏈路參數(shù)配置

三、網(wǎng)絡(luò)仿真環(huán)境搭建

有線網(wǎng)絡(luò)試驗的網(wǎng)絡(luò)拓?fù)鋱D如1所示。其中PC到路由R0之間和R1到服務(wù)器之間的鏈路配置相同帶寬1000Mbps，時延0ms，隊列類型Drop Tail，最大隊列30000個MSS；而R0和R1之間的帶寬100Mbps，時延64ms，隊列類型Drop Tail，最大隊列220個MSS。從上面參數(shù)中可看到，該網(wǎng)絡(luò)的瓶頸在于路由器R0與R1之間。

無線誤碼率約10-4為嚴(yán)重受干擾的信道，無線誤碼率小于10-6為干擾很小的信道，無線誤碼率在10-6～10-5之間為信道干擾的一般狀態(tài)，由無線信道誤碼率BER與丟包率p存在以下關(guān)系：

其中，p(t)—丟包率；

BER—無線信道誤碼率；

packet length—報文章長度。

如 在 10-6～10-5之間取誤碼率為10-5（一般干擾），每報文長度為1000Byte（8000bit），則無線丟失概率為7%[6]。

因此，無線網(wǎng)絡(luò)試驗的網(wǎng)絡(luò)拓?fù)鋱D如圖2所示。其中，智能機(jī)與訪問點的距離為45m（無線網(wǎng)絡(luò)仿真中其距離最大不能超過250m，超過即沒有信號），丟包率為7%，采用MAC/802_11協(xié)議，其基本速率為1Mbps，數(shù)據(jù)速率為11Mbps，其余配置見表1。

四、有線鏈路與無線鏈路中數(shù)據(jù)傳輸?shù)谋容^

圖3、圖4為有線網(wǎng)絡(luò)環(huán)境和無線網(wǎng)絡(luò)環(huán)境下Reno擁塞窗口變化圖，其中，紅線為擁塞窗口的變化，綠線代表慢啟動門限的變化，橫坐標(biāo)為時間。從圖3中可以看出，有線鏈路發(fā)送平穩(wěn)，擁塞窗口變化處于一個有限的區(qū)域內(nèi)，而且沒有頻繁地切換，慢啟動門限基本沒有發(fā)生變化。而在無線鏈路中擁塞窗口變化起伏大。

圖5和圖6為有線鏈路與無線鏈路的吞吐量仿真結(jié)果圖。圖5的有線鏈路下的TCP Reno吞吐量基本穩(wěn)定在一定范圍內(nèi)，而圖6無線鏈路下的TCP Reno中，多次吞吐量被拉至零。

由圖3和圖5中，可以看出，有線鏈路吞吐量與擁塞窗口密切相關(guān)，說明了有線鏈路中包丟失主大部份原因是由于擁塞而造成的路由器緩沖區(qū)溢出。

由圖4和圖6中，可以看出，造成無線網(wǎng)性能降低的因素并不只是擁塞，還受差錯率以及時延的影響。同時也提示了這些因素中對TCP數(shù)據(jù)傳輸?shù)挠绊懀阂驗榇蟮难訒r使得確認(rèn)報文的返回時間較長，TCP發(fā)送窗口的增長速度較慢；鏈路差錯的存在造成報文段的丟失，進(jìn)而使得TCP多次將擁塞窗口置為1，重新開始慢啟動的過程，從而降低了TCP的發(fā)送速率，影響TCP的性能。

從圖3、圖4的擁塞窗口與圖5、圖6吞吐量的變化圖中可以看出無線鏈路較有線鏈路：擁塞窗口變化大，吞吐量波動范圍大，吞吐量小等特點。

五、TCP協(xié)議各算法在無線鏈路上的數(shù)據(jù)傳輸性能比較

由于所設(shè)的發(fā)送速率遠(yuǎn)未達(dá)到鏈路瓶頸，本文不考慮擁塞報文丟失，故認(rèn)為信道態(tài)不佳是造成報文丟失的主要原因。各版本的TCP協(xié)議擁塞窗口及吞吐量隨時間的變化見圖7～圖14。

1、各TCP版本擁塞窗口比較及分析

各TCP版本報文大小為1000Byte，丟包率為7%下?lián)砣翱谝妶D7～圖10。

從圖7與圖8比較看到，由于Vegas是通過RTT提前探測網(wǎng)絡(luò)的擁塞情況，所以相對于Reno其擁塞窗口一直穩(wěn)定在一定范圍內(nèi)，但擁塞窗口一直保持在較小的值。而無線上的RTT較大，因此不適用于無線網(wǎng)絡(luò)。

從圖7與圖9比較看到，與Reno算法相比，由于Veno在擁塞狀態(tài)發(fā)生時，通過判斷丟包的性質(zhì)來采取不同的擁塞控制策略，所以不會盲目降低擁塞窗口的增加速度，而當(dāng)擁塞發(fā)生時，發(fā)送端將擁塞窗口增速放緩，從而能使擁塞窗口更長時間地保持在較大的狀態(tài)。因此，從圖中看出，在一定時間內(nèi)擁塞窗口的變化明顯小于Reno的變化。

Westwood算法通過檢測應(yīng)答ACK返回發(fā)送端的速率估算網(wǎng)絡(luò)的可用帶寬，并利用估算出的可用帶寬計算出擁塞窗口cwnd以及慢啟動閾值ssthresh，從而進(jìn)行流量控制以改善網(wǎng)絡(luò)的擁塞狀況。但從圖9與圖10比較看到，Westwood的擁塞窗口窗口的平均值明顯比Veno擁塞窗口的平均值大。

2、各TCP版本吞吐量比較及分析

各TCP版本分組大小為1000Byte丟包率為7%下吞吐量見圖11～圖14。

從上述4圖中比較，在丟包率為7%的情況下，Vegas的吞吐量最為穩(wěn)定，波動范圍較小，相比于其他算法，Vegas將吞吐量拉至0的次數(shù)明顯較少；而相比于其他算法，Westwood算法的吞吐量的平均值最高。

六、小結(jié)

本文首先對有線鏈路與無線鏈路的擁塞窗口與吞吐量進(jìn)行比較，然后幾種TCP算法以及丟包率對擁塞窗口和吞吐量的影響進(jìn)行了比較與分析，最后得出以下結(jié)論。

在無線鏈路中，如果整個網(wǎng)絡(luò)都使用Vegas算法，能達(dá)到很不錯的效果，即更大的吞吐量和更低的丟包率。但是很顯然，這是不現(xiàn)實的。Vegas算法的帶寬競爭力太弱了，比Reno算法還不激進(jìn)，因此不建議采用。

Veno算法避免Reno算法盲目的將擁塞窗口減半，因此能夠維持更大的擁塞窗口，吞吐量也比Reno算法大，取得更高的帶寬利用率。其友好性和公平性也較好，與其他的TCP也具有較好的共存性。

Westwood通過對帶寬進(jìn)行估計來調(diào)整cwnd和ssthress的值，使得免受隨機(jī)丟包的影響，因此cwnd一直處于較大的位置，從而提高了吞吐量。另外，Westwood對隨機(jī)丟包不敏感，因此在以上幾種算法中，westwood在無線網(wǎng)絡(luò)丟包率較高時表現(xiàn)最好。本文建議在無線網(wǎng)絡(luò)中選用westwood算法作為擁塞控制算法。