一種基于CAPPROBE帶寬估計(jì)的TCP Westwood算法

袁鵬飛，鄭 濤，楊李冬，3，戴平陽，謝 怡，2＊

（1.廈門大學(xué)信息科學(xué)與技術(shù)學(xué)院，福建 廈門361005；2.廈門大學(xué)云計(jì)算與大數(shù)據(jù)中心，福建 廈門361005；3.廈門大學(xué)深圳研究院，廣東 深圳518052）

傳 輸 控 制 協(xié) 議 （transmission control protocol，TCP）是因特網(wǎng)最重要的協(xié)議之一.TCP通過流量控制、差錯(cuò)控制和擁塞控制保證端到端通信的可靠性.其中，擁塞控制通過調(diào)整發(fā)送端傳輸速率來適應(yīng)網(wǎng)絡(luò)容量的實(shí)時(shí)變化，避免網(wǎng)絡(luò)擁塞的發(fā)生.一旦投入網(wǎng)絡(luò)的數(shù)據(jù)超過網(wǎng)絡(luò)核心設(shè)備（如路由器）的處理能力，就很容易發(fā)生網(wǎng)絡(luò)擁塞，并導(dǎo)致網(wǎng)絡(luò)性能的急劇下降.

本文主要討論擁塞控制機(jī)制對(duì)TCP傳輸性能的影響，尤其是它在無線網(wǎng)絡(luò)中的作用.擁塞控制主要包括4個(gè)經(jīng)典算法［1］：慢啟動(dòng)、擁塞避免、快重傳和快恢復(fù).這些算法在有線網(wǎng)絡(luò)和應(yīng)用中體現(xiàn)了很好的性能.但在無線網(wǎng)絡(luò)中丟包的原因既可能因?yàn)榫W(wǎng)絡(luò)擁塞也可能是由信道錯(cuò)誤引起.若在這種情況下使用傳統(tǒng)TCP，所有的丟包事件都會(huì)觸發(fā)擁塞控制機(jī)制而減小擁塞窗口（cwnd），導(dǎo)致不必要的參數(shù)調(diào)整，從而降低網(wǎng)絡(luò)性能.因此，不少研究者致力于設(shè)計(jì)更適合無線網(wǎng)絡(luò)的 TCP擁塞機(jī)制，例如 TCP Peach［2］，TCP Veno［3］和 TCP Westwood（TCPW）［4］.

TCPW通過監(jiān)控ACK流來估計(jì)帶寬，根據(jù)帶寬值調(diào)整cwnd.許多研究結(jié)果表明［4－5］，TCPW 相比于傳統(tǒng)TCP在無線網(wǎng)絡(luò)中具有更好吞吐量和更小的時(shí)延.實(shí)時(shí)帶寬估計(jì)是TCPW的關(guān)鍵部分，而其原始的帶寬估計(jì)方法不準(zhǔn)確［6］.

本文基于CAPPROBE帶寬估計(jì)算法［7］，提出了一種新的網(wǎng)絡(luò)擁塞控制算法TCPW CAPPROBE（TCPWC）.CAPPROBE是基于雙包探測(cè)技術(shù)的帶寬估計(jì)算法.與其他基于探測(cè)包算法［8－9］相比，CAPPROBE的計(jì)算代價(jià)更小，速度更快，而且更精確.當(dāng)探測(cè)包尺寸減小時(shí)，獲得精確帶寬的概率將更大.在TCPWC中，小尺寸的ACK所扮演的就是探測(cè)包的角色.由于ACK只有幾十字節(jié)，這樣的小尺寸探測(cè)包易于獲得瓶頸鏈路的準(zhǔn)確帶寬.

因此，TCPWC算法能通過更準(zhǔn)確的帶寬估計(jì)來合理地調(diào)整cwnd和慢啟動(dòng)閾值（ssthresh），避免擁塞控制機(jī)制的過度反應(yīng)，從而提高無線網(wǎng)絡(luò)的傳輸性能.

1 相關(guān)工作

1.1 TCPW及相關(guān)研究

基于TCP Reno機(jī)制的TCPW，同樣具有慢啟動(dòng)、擁塞避免、快速重傳等機(jī)制.在慢啟動(dòng)階段，發(fā)送端每收到一個(gè)新的ACK，cwnd增加1個(gè)最大數(shù)據(jù)分組（maximal segment size by bytes，MSS）.當(dāng)cwnd大于ssthresh時(shí)，網(wǎng)絡(luò)進(jìn)入擁塞避免階段.此時(shí)，發(fā)送端每接收到一個(gè)新的ACK，cwnd增加1／cwnd個(gè)MSS，即呈線性增長(zhǎng)方式.當(dāng)網(wǎng)絡(luò)擁塞或者鏈路錯(cuò)誤而產(chǎn)生丟包時(shí)，TCPW不是簡(jiǎn)單地減小參數(shù)而是根據(jù)帶寬估計(jì)值BW對(duì)cwnd和ssthresh進(jìn)行更新，具體算法如下：cwnd＝1，ssthresh is given，flag＿FF＝0；∥初始化，flag＿FF用來標(biāo)記是否處于快重傳階段

其中，RTTmin是整個(gè)連接過程中RTT樣本的歷史最小值，SegmentSize指?jìng)魉蛿?shù)據(jù)段大小.若網(wǎng)絡(luò)擁塞程度增加而引起丟包，BW估計(jì)值因RTT采樣值的增大而減小，而RTTmin值仍為歷史最小值，因此ssthresh減小以緩解擁塞，發(fā)送端減緩數(shù)據(jù)發(fā)送.

接下來，本文介紹TCPW根據(jù)ACK流估計(jì)當(dāng)前帶寬b的算法，如公式（1）.其中，Cack代表ACK數(shù)量，Sseg是TCP包大小，tnow表示當(dāng)前ACK的接收時(shí)間，tlast表示上一個(gè)ACK的接收時(shí)間.

僅使用公式（1）得到帶寬可能存在較大錯(cuò)誤.為了得到更準(zhǔn)確的帶寬值，Astrom等［10］提出了基于Tusin近似值的平滑模型處理，以當(dāng)前平滑帶寬值＾bk作為實(shí)時(shí)帶寬估計(jì)值，如公式（2）所示.

TCPW在無線網(wǎng)絡(luò)通信方面表現(xiàn)了較傳統(tǒng)TCP更好的性能潛力，因此大量的研究圍繞著它展開.研究方法各有側(cè)重，有些工作關(guān)注數(shù)據(jù)TCP傳輸?shù)耐掏铝亢蛿?shù)據(jù)延遲等指標(biāo).例如CMT機(jī)制［11］在估計(jì)帶寬值之后，使用新的策略來更新cwnd值，從而實(shí)現(xiàn)高效傳輸.趙文波等［12］則通過調(diào)整TCPW擁塞控制算法慢啟動(dòng)階段和擁塞避免階段的發(fā)送窗口增長(zhǎng)規(guī)則來提高網(wǎng)絡(luò)性能.有些工作關(guān)注TCP的友好性和公平性.例如TCPW for multiple paths（MPTCPW）［13］在通信鏈路之間進(jìn)行協(xié)作式的擁塞控制，從而達(dá)到鏈路負(fù)載均衡以及瓶頸鏈路的公平性.還有些研究在TCPW與帶寬估計(jì)算法的結(jié)合方面投入較大精力［6，14］.例如 Gangadhar等［6］指出TCPW采用的帶寬估計(jì)算法因?yàn)锳CK壓縮現(xiàn)象會(huì)導(dǎo)致估計(jì)帶寬偏高，因此提出使用RTT的相關(guān)值來估計(jì)帶寬.本文則巧妙地將ACK機(jī)制與基于雙包技術(shù)的CAPPROBE帶寬估計(jì)算法相結(jié)合，更準(zhǔn)確地估計(jì)帶寬，并對(duì)cwnd和ssthresh進(jìn)行更合理的自適應(yīng)調(diào)整，以達(dá)到充分利用鏈路可用容量的目標(biāo).

1.2 帶寬估計(jì)及相關(guān)研究

網(wǎng)絡(luò)傳輸路徑由從數(shù)據(jù)發(fā)送端到接收端的一系列鏈路組成.路徑帶寬指該路徑能提供的最大IP層傳輸速率.因此，路徑帶寬取決于瓶頸鏈路帶寬.端對(duì)端路徑可用帶寬估計(jì)要反映瓶頸鏈路的可用帶寬，并以此作為網(wǎng)絡(luò)鏈路性能的重要測(cè)量參數(shù).

目前大部分帶寬估計(jì)方法都是基于雙包技術(shù)［7，15］.具體做法是，發(fā)送兩個(gè)連續(xù)的數(shù)據(jù)包，而經(jīng)過瓶頸鏈路的時(shí)候會(huì)使得他們產(chǎn)生間隔，接收方根據(jù)這個(gè)間隔來計(jì)算瓶頸鏈路帶寬.還有一類工作以觀測(cè)TCP數(shù)據(jù)段的單向延遲來測(cè)量帶寬，不足是需要發(fā)送大量的探測(cè)TCP數(shù)據(jù)段報(bào)文，如Pathload［16］.這類技術(shù)額外發(fā)送的探測(cè)報(bào)文本身就可能造成網(wǎng)絡(luò)的阻塞.其它無線網(wǎng)絡(luò)帶寬估計(jì)方法［17－18］也存在類似的問題.

相比以上帶寬估計(jì)算法，本文采用的CAPPROBE算法巧妙地改造TCP的ACK機(jī)制進(jìn)行帶寬估計(jì).它未引用額外的數(shù)據(jù)探測(cè)分組，探測(cè)包就是小尺寸的ACK分組.因此，具有代價(jià)小，速度快，而且更精確的特點(diǎn).

2 TCPWC的設(shè)計(jì)

2.1 CAPPROBE帶寬估計(jì)算法

雙包技術(shù)［19］于1991年首次被提出，其關(guān)鍵是發(fā)送端發(fā)送兩個(gè)連續(xù)沒有空隙的探測(cè)包.假設(shè)，L是雙包中第2個(gè)包的大小，B是經(jīng)過路徑中的瓶頸鏈路帶寬，則雙包經(jīng)過瓶頸鏈路而導(dǎo)致的到達(dá)間隔時(shí)間為T＝L／B.由此，可以得到B的表達(dá)公式：

然而，真實(shí)網(wǎng)絡(luò)存在背景流量，此時(shí)測(cè)量帶寬值可能有偏差，如圖1所示.圖1（a）表示沒有背景流量影響的理想環(huán)境下，帶寬估計(jì)值是準(zhǔn)確的.但一旦有背景流量，就很難獲得準(zhǔn)確的可用帶寬.例如圖1（b），當(dāng)雙包中第1個(gè)包由于背景流而遭遇的時(shí)延比第2個(gè)更長(zhǎng)，就導(dǎo)致T減小，從而估算的帶寬會(huì)偏大；再如圖1（c），當(dāng)?shù)?個(gè)包排隊(duì)的時(shí)間延長(zhǎng)，導(dǎo)致T增大，因此估算的帶寬值會(huì)偏小.

首先定義雙包時(shí)延和為數(shù)據(jù)包對(duì)中兩個(gè)包的單向時(shí)延之和.在沒有背景流量的理想環(huán)境中估計(jì)的帶寬是比較準(zhǔn)確的，所以我們?cè)陔p包時(shí)延和最小的情況下測(cè)得的帶寬是最接近準(zhǔn)確值.因此，CAPPROBE綜合考慮時(shí)間間隔T和探測(cè)包對(duì)的時(shí)延.由于每對(duì)探測(cè)包都會(huì)因排隊(duì)產(chǎn)生時(shí)延，CAPPROBE將逐一記錄所有的雙包的時(shí)延和以及對(duì)應(yīng)的雙包間隔T值.在估測(cè)帶寬時(shí)，根據(jù)已有的記錄找出時(shí)延和最小的探測(cè)包樣本，然后用該樣本相應(yīng)的T值來估計(jì)瓶頸鏈路帶寬，然后再根據(jù)包間隔模型公式［20］計(jì)算可用帶寬值.每次帶寬估計(jì)完成后，對(duì)時(shí)延和T的記錄表進(jìn)行初始化清零，重新開始記錄新的雙包信息.

2.2 TCPWC的設(shè)計(jì)

本文在TCPW的基礎(chǔ)上結(jié)合CAPPROBE做了帶寬估測(cè)的改進(jìn).其主要思想是：接收端對(duì)于收到任何數(shù)據(jù)包都發(fā)送兩個(gè)連續(xù)的相同的ACK包，發(fā)送端根據(jù)接收到的ACK包使用CAPPROBE算法進(jìn)行帶寬估計(jì)，進(jìn)而對(duì)cwnd和ssthresh值進(jìn)行合理的調(diào)整，即由ACK包扮演雙包技術(shù)中的探測(cè)包角色.

如圖2，SEQ為TCP頭部序列號(hào)字段，ACK是TCP頭部確認(rèn)號(hào)字段，假設(shè)每個(gè)數(shù)據(jù)段都是滿數(shù)據(jù)段.首先發(fā)送方和接收方通過3次握手建立TCP連接，然后進(jìn)入發(fā)送數(shù)據(jù)階段.發(fā)送方正常發(fā)送數(shù)據(jù)包；接收方每收兩個(gè)滿數(shù)據(jù)段觸發(fā)一次確認(rèn)，連續(xù)回復(fù)兩個(gè)重復(fù)的ACK.當(dāng)發(fā)送方收到雙ACK包，則進(jìn)行雙包處理階段.若發(fā)生超時(shí)或者收到3個(gè)重復(fù)的標(biāo)準(zhǔn)ACK，發(fā)送端找出時(shí)延T和最小的樣本L計(jì)算實(shí)時(shí)帶寬BW，詳見公式（3）.實(shí)時(shí)帶寬BW將應(yīng)用1.1節(jié)所示的TCPW算法實(shí)現(xiàn)TCPWC的擁塞控制.

圖1 雙包探測(cè)的3種情況Fig.1 Packet pair dispersion

圖2 TCPWC時(shí)序圖Fig.2 The sequence chart of TCPWC

為了區(qū)分標(biāo)準(zhǔn)ACK包和輔助ACK包，本文對(duì)輔助ACK包進(jìn)行了標(biāo)記.TCP的頭部結(jié)構(gòu)有個(gè)保留（reserved）字段，共6位，默認(rèn)全置.保留字段是為了將來定義新的用途而設(shè)，而本文利用它來標(biāo)記輔助ACK包，即使其置全1，如圖3所示.根據(jù)發(fā)送方收到ACK的3種情況，雙包處理階段如下：

1）收到ACK雙包時(shí)，將根據(jù)保留字段值來區(qū)分兩類ACK包.若值為全1，僅需要記錄其達(dá)到時(shí)間等相關(guān)信息；若值為全0，則記錄相關(guān)信息后，進(jìn)入標(biāo)準(zhǔn)TCP協(xié)議的控制運(yùn)作.

2）僅收到標(biāo)準(zhǔn)ACK.不進(jìn)行實(shí)時(shí)帶寬測(cè)量的采樣，直接進(jìn)入標(biāo)準(zhǔn)TCP協(xié)議的控制運(yùn)作.

3）僅收到輔助ACK.將輔助ACK的反饋信息利用起來，亦直接進(jìn)入標(biāo)準(zhǔn)TCP協(xié)議的控制運(yùn)作.

圖3 輔助ACK的TCP頭部結(jié)構(gòu)Fig.3 The structureof TCP header in an assistant ACK

3 TCPWC的實(shí)現(xiàn)及評(píng)估

本文采用仿真環(huán)境NS3來實(shí)現(xiàn)、驗(yàn)證和評(píng)估TCP擁塞控制機(jī)制的性能.首先，本文在NS3（v.3.17）加載了 TCPW 的補(bǔ)丁［6］，并實(shí)現(xiàn)了 TCPWC.

3.1 TCPWC的NS3仿真實(shí)現(xiàn)

本文在NS3仿真環(huán)境中實(shí)現(xiàn)了TCPWC模塊，TCPWC的主要流程如圖4所示，主要功能函數(shù)如下：

圖4 TCPWC流程圖Fig.4 The flowchart of TCPWC

Ack（）：處理新接收的ACK，記錄相關(guān)信息.

CutAck（）：根據(jù)ACK包頭部的保留字段識(shí)別是否構(gòu)造ACK包，如值置全1，則丟棄.

CountAck（）：保存接收端收到的連續(xù)ACK的數(shù)量.

EstimateBWC（）：TCPWC根據(jù) CAPPROBE 算法估計(jì)帶寬.

NewAck（）：根據(jù)TCP Reno的規(guī)則來設(shè)置cwnd和ssthresh的值.

DupAck（）：接收的ACK數(shù)量超過某個(gè)常數(shù)之后，根據(jù)估計(jì)的帶寬對(duì)cwnd和ssthresh值進(jìn)行調(diào)整.

Data（）：接收者收到新的數(shù)據(jù).

SendPacketC（ACK）：這里除了發(fā)送正常的ACK包之外，還緊接著發(fā)送一個(gè)本文構(gòu)造的ACK包.

3.2 實(shí)驗(yàn)環(huán)境

為了評(píng)估不同指標(biāo)下各TCP版本的吞吐量對(duì)比，本文建立了圖5的拓?fù)洵h(huán)境.其中吞吐量是指網(wǎng)絡(luò)在單位時(shí)間內(nèi)成功傳送的數(shù)據(jù)總量.在利用圖5拓?fù)浔容^吞吐量的實(shí)驗(yàn)中，拓?fù)渲兄挥幸粭lTCP連接，每次實(shí)驗(yàn)采用不同擁塞控制機(jī)制的TCP版本.此時(shí)，吞吐量的值只需考慮一條連接在單位時(shí)間內(nèi)成功傳送的數(shù)據(jù).路由器左邊的鏈路帶寬為10Mbits／s，傳播時(shí)延為25ms，路由器右邊鏈路帶寬為2Mbits／s，傳播時(shí)延為0.01ms.為了模擬無線環(huán)境，鏈路都配置了錯(cuò)誤模塊來模擬無線鏈路丟包.為了和文獻(xiàn)結(jié)果［4］進(jìn)行對(duì)比，本文都保持了許多典型參數(shù)，例如誤包率（packet error rates，PER）設(shè)置為0.05且符合均勻分布，最大傳輸單元（maximum transmission unit，MTU）大小為400B，延遲 ACK計(jì)數(shù)為2，延遲ACK超時(shí)時(shí)間為200ms，代表性的數(shù)據(jù)流來自FTP應(yīng)用.為了實(shí)驗(yàn)結(jié)果的可靠性，每次仿真模擬時(shí)間長(zhǎng)達(dá)300s，每次仿真試驗(yàn)都重復(fù)多次，再計(jì)算指標(biāo)的平均值.詳細(xì)參數(shù)見表1.

圖5 仿真拓?fù)鋱DFig.5 Simulation topology of throughput

表1 仿真參數(shù)Tab.1 Simulation parameters

本文還針對(duì)算法的友好性和公平性的評(píng)估設(shè)計(jì)了圖6的拓?fù)洵h(huán)境.與圖5拓?fù)洳煌瑘D6仿真拓?fù)浒鄺lTCP連接，吞吐量的計(jì)算需要考慮多條連接.路由器A和B之間是一條帶寬為2Mbits／s，傳播時(shí)延為2ms的瓶頸鏈路.源主機(jī)通過一條帶寬為10 Mbits／s，時(shí)延為0.01ms的Access鏈路與路由器A連接，目的主機(jī)通過一條同樣的Access鏈路與路由器B連接.

3.3 評(píng) 估

本文考慮了瓶頸鏈路傳播時(shí)延，瓶頸鏈路誤包率和瓶頸鏈路傳播帶寬這3個(gè)參數(shù)對(duì)流量控制算法的影響.主要分析在不同取值下，不同TCP版本獲得的鏈路吞吐量的對(duì)比.

圖6 友好性與公平性仿真拓?fù)鋱DFig.6 Simulation topology of friendliness and fairness

首先，當(dāng)以上3個(gè)重要參數(shù)采用表1的默認(rèn)值時(shí)（即誤碼率為0.01，瓶頸鏈路帶寬為2Mbits／s，瓶頸鏈路傳播時(shí)延0.01ms），對(duì)不同TCP版本在2種經(jīng)典數(shù)據(jù)流模型進(jìn)行了簡(jiǎn)單吞吐量對(duì)比，如表2.一個(gè)是經(jīng)典的固定比特率（CBR）數(shù)據(jù)流模型；另一個(gè)是基于FTP應(yīng)用產(chǎn)生的數(shù)據(jù)流.

表2 2種數(shù)據(jù)流模型吞吐量對(duì)比Tab.2 Throughput of two flow model Mbits／s

由表2可以看出，在2種數(shù)據(jù)流模型下，TCPWC相比于傳統(tǒng)TCP版本有明顯的性能提升.同時(shí)對(duì)于TPCW也體現(xiàn)了一定的優(yōu)越性.接下來，本文將FTP數(shù)據(jù)流模型為代表，對(duì)各TCP版本的性能進(jìn)行詳細(xì)對(duì)比分析.

接著，觀察在無線鏈接的不同誤包率情況下，TCPW、TCPWC以及其他的TCP算法的性能.誤包率的范圍設(shè)置為0.000 1～0.1.如圖7所示，同其他TCP版本相比較，TCPW和TCPWC的吞吐量有了顯著的提高.這是因?yàn)橥ㄟ^估計(jì)帶寬來設(shè)置cwnd，提高了網(wǎng)絡(luò)利用率.由于CAPPROBE算法提高了帶寬估計(jì)的準(zhǔn)確性，當(dāng)誤包率大于0.001，TCPWC的吞吐量也比TCPW明顯提高.

同時(shí)，本文觀察瓶頸鏈路造成的傳播時(shí)延.假設(shè)誤包率固定為0.005，瓶頸鏈路傳播時(shí)延范圍設(shè)為0.1 ms到25ms.如圖8所示為不同傳播時(shí)延下網(wǎng)絡(luò)的吞吐量情況.結(jié)果表明，同舊版本的TCP比較，TCPW的性能有了很顯著的提高，同時(shí)TCPWC的性能比TCPW也有接近15%的性能提升.TCPWC更充分地利用了鏈路容量.

圖7 吞吐量vs.瓶頸鏈路誤包率Fig.7 Ave throughput vs.bottleneck link error rates

圖8 吞吐量vs.時(shí)延Fig.8 Ave throughput vs.bottleneck link delay

圖9則描述瓶頸鏈路在不同帶寬下獲得的吞吐量比較結(jié)果，其中帶寬范圍從1Mbits／s到4Mbits／s，且時(shí)延設(shè)置為固定值0.01ms，誤包率設(shè)置為固定值0.005.從圖9中可以看出與之前結(jié)果類似，TCPWC的性能表現(xiàn)最好，其次是TCPW，最后為傳統(tǒng)TCP算法.

同時(shí)，友好性和公平性也是評(píng)估TCP算法的重要指標(biāo).友好性指一種新的TCP擁塞控制算法，必須能夠和其他現(xiàn)存TCP擁塞控制算法共存，即對(duì)其他TCP擁塞算法的友好（因篇幅有限，本文以TCP Reno作為現(xiàn)存擁塞控制算法的代表）.公平性指對(duì)于采用相同TCP擁塞控制算法的多條連接，它們?cè)诜€(wěn)定時(shí)應(yīng)公平地使用帶寬.接下來，本文基于圖6的拓?fù)浣Y(jié)構(gòu)進(jìn)行了友好性和公平性的仿真評(píng)估.

首先，設(shè)置路由器之間的瓶頸鏈路延時(shí)為25ms，誤包率為0.008，TCP連接共2個(gè).

圖9 吞吐量vs.瓶頸鏈路帶寬Fig.9 Ave throughput vs.bottleneck bandwidth

圖10 吞吐量vs.Reno連接數(shù)量Fig.10 Ave throughput vs.the number of TCP Reno connections over lossy link

1）建立2條基于TCPWC的數(shù)據(jù)連接，模擬發(fā)送數(shù)據(jù)100s.可觀察到各連接平均吞吐量為0.97 Mbits／s，最大吞吐量比平均值高出約16%，而最小值比平均值低約18%.與上一個(gè)實(shí)驗(yàn)相比，公平性略有下降.

2）保持TCPWC和TCP Reno的連接總數(shù)為2，模擬發(fā)送數(shù)據(jù)100s.結(jié)果如圖10所示，橫坐標(biāo)表示TCP Reno的連接條數(shù)，縱坐標(biāo)表示基于相同算法的各連接的平均吞吐量.TCPWC可以與TCP Reno共存，但性能更優(yōu)越，可獲得高出其約20%的平均吞吐量.

綜上分析，TCPWC具有較好的傳輸速度，良好的友好性和公平性.雖然隨著網(wǎng)絡(luò)擁塞程度增加，公平性有所下降，但不會(huì)過度搶占其他連接資源.

4 結(jié) 論

本文將CAPPROBE帶寬估計(jì)算法應(yīng)用于TCPW，提出了一種基于CAPPROBE帶寬估計(jì)算法的網(wǎng)絡(luò)擁塞控制算法TCPWC.通過設(shè)計(jì)ACK雙包機(jī)制，本文使用CAPPROBE算法獲得更精確的瓶頸鏈路帶寬估計(jì)值，從而優(yōu)化擁塞控制參數(shù)的設(shè)置，避免無線鏈路高誤包率的影響.本文在NS3中實(shí)現(xiàn)了TCPWC，并與TCPW、傳統(tǒng)的TCP機(jī)制NewReno、Reno和Tahoe做了性能比較.從實(shí)驗(yàn)結(jié)果可以看出，TCPWC的吞吐量有了明顯的改進(jìn)，并同時(shí)表現(xiàn)出友好性和公平性.考慮到真實(shí)網(wǎng)絡(luò)環(huán)境的復(fù)雜性和不可預(yù)測(cè)性，仿真的結(jié)果帶有一定局限性.例如，還未深入分析TCPWC對(duì)RTT過大的TCP連接的性能影響（經(jīng)過同步衛(wèi)星鏈路的TCP連接，其RTT通常大于0.5s）.因此，將來的工作是搭建網(wǎng)絡(luò)測(cè)試平臺(tái)，通過更細(xì)致全面的通信實(shí)驗(yàn)，進(jìn)一步驗(yàn)證TCPWC的性能.

［1］Allman M，Paxson V，Stevens W.TCP congestion control，IETF RFC 2581［EB／OL］.［1999－04］.http：∥www.tools.ietf.org／rfc／rfc2581.txt.

［2］Akyildiz I F，Morabito G，Palazzo S.TCP－Peach：a new congestion control scheme for satellite IP networks［J］.IEEE／ACM Transactions on Networking，2001，9（3）：307－321.

［3］Fu C P，Liew S C.TCP veno：TCP enhancement for transmission over wireless access networks［J］.IEEE Journal on Selected Areas in Communications，2003，21（2）：216－228.

［4］Mascolo S，Casetti C，Gerla M，et al.TCP westwood：bandwidth estimation for enhanced transport over wireless links［C］∥Proceedings of the 7th Annual International Conference on Mobile Computing and Networking.Rome，Italy：ACM，2001：287－297.

［5］Sheth A M，Patel K D，Chaudhari J P，et al.Analysis of TCP westwood NR protocol in congested and lossynetwork［J］.International Journal of Engineering and Technology，2013，4：477－482.

［6］Gangadhar S，Nguyen T A N，Umapathi G，et al.TCP Westwood（＋）Protocol Implementation in ns－3［C］∥Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques.Cannes，F(xiàn)rance：ICST，2013：167－175.

［7］Kapoor R，Chen L J，Li L，et al.CapProbe：a simple andaccurate capacity estimation technique［C］∥Proceedings of the 2004Conference on Applications，Technologies，Architectures，and Protocols for Computer Communications.Portland，Oregon，USA：ACM，2004：67－78.

［8］Lai K，Baker M.Measuring link bandwidth using a deterministic model of packet delay［C］∥Proceedings of the 2000Conference on Applications，Technologies，Architectures，and Protocols for Computer Communications.Stockholm，Sweden：ACM，2000：283－294.

［9］Downey A B.Using pathchar to estimate internet link characteristics［C］∥Proceedings of the 1999Conference on Applications，Technologies，Architectures，and Protocols for Computer Communications.Cambridge，Massachusetts，USA：ACM，1999：241－250.

［10］Astrom K J，Wittenmark B."Computer controlled systems"theory and design［M］.New Jersey，USA：Prentice Hall，1997.

［11］Lan K，Sha N.A CMT congestion window updates mechanism based on TCP westwood［C］∥Proceedings of the Mechatronic Science，Electric Engineering and Computer（MEC）2011International Conference on.Jilin，China：IEEE，2011：2119－2122.

［12］趙文波，孫小科，馬草川.基于非線性窗口增長(zhǎng)的TCP Westwood改進(jìn)算法［J］.計(jì)算機(jī)應(yīng)用，2011，31（9）：2344－2348.

［13］Le T A，Hong C S，Huh E N.Coordinated TCP westwood congestion control for multiple paths over wireless networks［C］∥Proceedings of the International Conference on Information Network 2012.Bali，Indonesia：IEEE，2012：92－96.

［14］Hagag S，El－Sayed A.Enhanced TCP westwood congestion avoidance mechanism（TCP westwood new）［J］.International Journal of Computer Application，2012，45（5）：21－29.

［15］Goldoni E，Rossi G，Torelli A A.A new method for available bandwidth estimation［C］∥Proceedings of the 4th International Conference on Internet Monitoring and Protection.Mestre，Italy：IEEE，2009：130－136.

［16］Jain M，Dovrolis C.Pathload：a measurement tool for endtoend available bandwidth［C］∥Proceedings of the Passive and Active Measurements （PAM）Workshop.Colorado，USA：Citeseer，2002：14－25.

［17］Li M，Mark C，Rober K.WBest：a bandwidth estimation tool for IEEE 802.11wirelessnetworks［C］∥Proceedings of the 33rd IEEE Conference on Local Computer Networks（LCN）.Montreal，Canada：IEEE，2008：374－381.

［18］Sarr C，Chaudet C，Chelius G.Bandwidth estimation for IEEE 802.11－based ad hoc networks［J］.Mobile Computing，IEEE Transactions on，2008，7（10）：1228－1241.

［19］Keshav S.The packet pair flow control protocol［M］.Berkeley：International Computer Science Institute，1991.

［20］Strauss J，Katabi D，Kashoek F.A measurement study of available bandwidth estimation tools［C］∥Proceedings of the 3rd ACM SIGCOMM Conference on Internet Mesurement.Miami，USA：ACM，2003：39－44.