畢業(yè)論文----tcp擁塞控制機(jī)制定量性能分析

1、<p><b>　　畢業(yè)設(shè)計(jì)（論文）</b></p><p>　　題 目：TCP擁塞控制機(jī)制定量性能分析 </p><p>　　指導(dǎo)教師： XXXX 職稱： X教授 </p><p>　　學(xué)生姓名： XXXX 學(xué)號(hào)： 20xxxxxxx </p>

2、<p>　　專 業(yè)： 計(jì)算機(jī)科學(xué)與技術(shù) </p><p>　　院（系）： 信息工程學(xué)院 </p><p>　　完成時(shí)間： </p><p><b>　　年

3、5 月 22日</b></p><p>　　畢業(yè)設(shè)計(jì)（論文）任務(wù)書</p><p>　　附表一 題目來源：指導(dǎo)老師推薦</p><p>　　此表指導(dǎo)教師填后、復(fù)印，指導(dǎo)教師、學(xué)生各保存一份，交院教學(xué)辦一份</p><p>　　畢業(yè)設(shè)計(jì)（論

4、文）開題報(bào)告</p><p><b>　　附表二</b></p><p>　　畢業(yè)設(shè)計(jì)工作中期檢查Ⅰ</p><p>　　附表三 2007年 4 月 6 日</p><p>　　此表學(xué)生填寫，指導(dǎo)教師給出評(píng)語后，復(fù)印件于第五周

5、交院教學(xué)辦公室。</p><p>　　畢業(yè)設(shè)計(jì)工作中期檢查Ⅱ</p><p>　　附表四 2007年 5 月 9 日</p><p>　　指導(dǎo)教師組織學(xué)生口頭匯報(bào)后，學(xué)生填寫該表，教師給出評(píng)語后，于第十周交院教學(xué)辦公室。</p><p>　　

6、TCP擁塞控制機(jī)制定量性能分析</p><p><b>　　摘要：</b></p><p>　　網(wǎng)絡(luò)擁塞問題一直困擾著因特網(wǎng)，隨著網(wǎng)絡(luò)信息技術(shù)的迅速發(fā)展，新的網(wǎng)絡(luò)應(yīng)用對(duì)網(wǎng)絡(luò)擁塞控制策略提出了更高的要求。目前，TCP協(xié)議承載著因特網(wǎng)超過70%的傳輸流量，TCP擁塞控制機(jī)制可以有效地改善網(wǎng)絡(luò)擁塞現(xiàn)象。本文主要研究幾種常見的TCP擁塞控制算法，借助于網(wǎng)絡(luò)模擬器NS2，對(duì)這幾

7、種常用算法的性能進(jìn)行定量分析，并給出相應(yīng)的合理建議，以便改進(jìn)算法，取得更好的網(wǎng)絡(luò)性能。</p><p>　　論文首先介紹了對(duì)TCP擁塞控制算法進(jìn)行研究的必要性，接著闡述了TCP擁塞控制算法的相關(guān)基礎(chǔ)知識(shí)，包括網(wǎng)絡(luò)擁塞的定義、成因，以及TCP擁塞控制算法的思想。</p><p>　　然后介紹了常用的TCP擁塞控制算法：Tahoe、Reno、NewReno、SACK和Vegas TCP。并對(duì)這

8、些擁塞控制算法進(jìn)行了詳細(xì)分析，剖析了這些算法對(duì)擁塞現(xiàn)象進(jìn)行控制的機(jī)制，包括慢啟動(dòng)、擁塞避免、快速重傳、快速恢復(fù)，以及加入PACK (Partial ACK)和SACK(Selective ACK)的快速恢復(fù)等等。</p><p>　　為了比較這些算法的性能，在NS2網(wǎng)絡(luò)模擬器環(huán)境下，我們以數(shù)據(jù)包丟失作為網(wǎng)絡(luò)擁塞的信號(hào)，對(duì)Tahoe、Reno、NewReno和SACK算法進(jìn)行了模擬實(shí)驗(yàn)。并且對(duì)仿真結(jié)果進(jìn)行了分析和比

9、較，結(jié)果證明：加入了PACK和SACK的快速恢復(fù)算法，可以使TCP更快地從網(wǎng)絡(luò)擁塞中恢復(fù)到正常工作狀態(tài)。</p><p>　　最后，對(duì)TCP擁塞控制算法做了總結(jié)，并對(duì)將來的工作進(jìn)行了展望。</p><p><b>　　關(guān)鍵詞：</b></p><p>　　擁塞控制 慢啟動(dòng) 擁塞避免 快速重傳 快速恢復(fù)</p><p>　

10、　Quantitative analysis on the performance of TCP congestion control mechanism</p><p>　　Abstract: </p><p>　　The Internet has suffered from the long-term problem of congestion at all times. With t

11、he rapid development of information technology, more careful-designed network congestion control algorithm is required. According to the statistic collected in recent years, TCP carries over 70% Internet traffic. And TCP

12、 congestion control mechanisms can improve congestion problem in the Internet effectively. In the thesis, we research on several common TCP congestion control algorithms，analyze the performanc</p><p>　　This

13、 thesis first introduces the necessity and importance of the network congestion control. And then, the thesis gives the basic concepts of network congestion, including the definition and cause of congestion and the think

14、ing of TCP congestion control algorithms.</p><p>　　Then, the thesis introduces five common TCP congestion control algorithms: Tahoe, Reno, NewReno, SACK and Vegas TCP, analyzes them in detail and discusses

15、the congestion control mechanisms used in them, which are slow-start, congestion avoidance, fast retransmit, fast recovery, fast recovery with PACK and SACK.</p><p>　　In order to compare the performance of t

16、hese algorithms, we use the loss of packets as the signal of network congestion and do simulation on Tahoe, Reno, NewReno and SACK algorithms in the environment of NS2 network simulator. Finally, we conclude that SACK an

17、d NewReno TCP perform better than Reno and Tahoe TCP, especially when multiple packets are dropped from a window of data. </p><p>　　Lastly, the thesis gives the conclusion and prospect.</p><p>　

18、　Key Words:</p><p>　　Congestion Control Slow Start Congestion Avoidance Fast Retransmit Fast Recovery</p><p><b>　　目錄</b></p><p><b>　　前言1</b></p>

19、<p><b>　　1．緒論1</b></p><p><b>　　1.1 擁塞1</b></p><p>　　1.1.1 基本概念1</p><p>　　1.1.2 產(chǎn)生原因1</p><p>　　1.2 擁塞控制2</p><p>　　2．TCP

20、擁塞控制3</p><p>　　2.1 TCP協(xié)議簡介3</p><p>　　2.2 TCP擁塞控制所要解決的主要問題4</p><p>　　2.3 TCP擁塞控制涉及到的參數(shù)4</p><p>　　2.4 TCP擁塞控制機(jī)制4</p><p>　　2.5 TCP擁塞控制算法5</p><

21、;p>　　2.5.1 Tahoe5</p><p>　　2.5.2 Reno6</p><p>　　2.5.3 NewReno7</p><p>　　2.5.4 SACK8</p><p>　　2.5.5 Vegas9</p><p>　　2.6 TCP擁塞控制算法的特點(diǎn)9</p>&l

22、t;p>　　2.7 TCP擁塞控制算法存在的主要問題9</p><p>　　2.8 TCP擁塞控制算法的改進(jìn)10</p><p>　　3．網(wǎng)絡(luò)仿真軟件NS-211</p><p>　　3.1 NS-2簡介11</p><p>　　3.2 使用NS-2進(jìn)行網(wǎng)絡(luò)模擬的方法和一般過程11</p><p>&l

23、t;b>　　4．仿真12</b></p><p>　　4.1 丟一個(gè)包情況下TCP實(shí)現(xiàn)的比較13</p><p>　　4.2 丟兩個(gè)包情況下TCP實(shí)現(xiàn)的比較14</p><p>　　4.3 丟三個(gè)包情況下TCP實(shí)現(xiàn)的比較16</p><p>　　4.4 丟四個(gè)包情況下TCP實(shí)現(xiàn)的比較18</p>&l

24、t;p>　　4.5 仿真小結(jié)20</p><p>　　5．結(jié)論及今后的工作20</p><p><b>　　5.1 結(jié)論20</b></p><p>　　5.2 今后的工作21</p><p><b>　　致謝22</b></p><p><b>　

25、　參考文獻(xiàn)23</b></p><p><b>　　附錄24</b></p><p><b>　　前言</b></p><p>　　因特網(wǎng)最初源于美國國防部的ARPANET，其最大特點(diǎn)是采用無連接的端到端的包交換服務(wù)。在過去的十年中，因特網(wǎng)逐步發(fā)展成為互聯(lián)全球的網(wǎng)絡(luò)，它使得用戶在世界范圍內(nèi)進(jìn)行通信成為可能。

26、隨著因特網(wǎng)的迅猛發(fā)展，它給人類社會(huì)帶來了巨大的變革。但就在因特網(wǎng)深刻影響人類歷史發(fā)展進(jìn)程的同時(shí)，因特網(wǎng)自身的發(fā)展卻面臨著種種困難，其中之一就是網(wǎng)絡(luò)擁塞。從因特網(wǎng)誕生起網(wǎng)絡(luò)擁塞就與其如影隨形。雖然因特網(wǎng)的相關(guān)技術(shù)日漸成熟，但網(wǎng)絡(luò)擁塞卻仍未很好解決，反而隨著因特網(wǎng)的規(guī)模、用戶和應(yīng)用的急劇增加，網(wǎng)絡(luò)擁塞問題日益突出。因此，如何進(jìn)行網(wǎng)絡(luò)擁塞避免及控制，提高網(wǎng)絡(luò)服務(wù)質(zhì)量是非常重要且亟待解決的問題。</p><p>　　目前

27、，端到端傳輸協(xié)議TCP承載著互聯(lián)網(wǎng)的絕大多數(shù)業(yè)務(wù)，其擁塞避免和控制機(jī)制是保證因特網(wǎng)穩(wěn)定性的重要因素，可以說，今天因特網(wǎng)的成功很大程度上得益于TCP擁塞控制算法的引進(jìn)，因此，對(duì)TCP擁塞控制算法進(jìn)行深入的研究具有重要的理論和應(yīng)用價(jià)值。</p><p>　　為了尋找擁塞控制的方案，科研工作者進(jìn)行了不懈的努力:1988年Jacobson針對(duì)TCP在網(wǎng)絡(luò)擁塞控制方面的不足，提出了慢啟動(dòng)(Slow Start)和擁塞避免(

28、Congestion Avoidance)算法；1990年出現(xiàn)的Reno TCP版本則增加了快速重傳(Fast Retransmit)和快速恢復(fù)(Fast Recovery)以提高TCP傳輸?shù)念B健性；NewReno TCP增加了恢復(fù)應(yīng)答(Recovery ACK)以提高TCP帶寬恢復(fù)能力等等。經(jīng)過近二十年的發(fā)展，TCP擁塞控制算法己經(jīng)擁有多個(gè)改進(jìn)版本，TCP協(xié)議的傳輸性能也因此得到了不斷的提高。</p><p>

29、　　在這樣的背景下，通過某種途徑對(duì)這些TCP擁塞控制算法進(jìn)行分析比較，并針對(duì)比較過程中出現(xiàn)的問題進(jìn)行研究以改善網(wǎng)絡(luò)性能，就顯得尤為重要。本文著重于深入理解幾種常見的TCP擁塞控制算法，并針對(duì)擁塞控制算法暴露出的一些問題，提出合理的建議，以此來改善當(dāng)前網(wǎng)絡(luò)擁塞的狀況。</p><p><b>　　1．緒論</b></p><p><b>　　1.1 擁塞<

30、;/b></p><p>　　1.1.1 基本概念</p><p>　　在某段時(shí)間，若對(duì)網(wǎng)絡(luò)中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞，這種情況就叫做擁塞（Congestion）。網(wǎng)絡(luò)中發(fā)生擁塞，會(huì)導(dǎo)致吞吐量減小，如果用戶仍不斷提出對(duì)網(wǎng)絡(luò)資源的需求，就會(huì)進(jìn)一步增加網(wǎng)絡(luò)的負(fù)擔(dān)，嚴(yán)重時(shí)會(huì)發(fā)生“擁塞崩潰”(Congestion Collapse)現(xiàn)象。一般來說，擁塞

31、崩潰往往發(fā)生在網(wǎng)絡(luò)負(fù)載的增加導(dǎo)致網(wǎng)絡(luò)效率降低的時(shí)候。</p><p>　　1.1.2 產(chǎn)生原因</p><p>　　擁塞發(fā)生的主要原因在于:網(wǎng)絡(luò)提供的資源不足，以及網(wǎng)絡(luò)資源使用不當(dāng)，以至于不能滿足用戶對(duì)網(wǎng)絡(luò)資源的需求。這些資源包括緩存空間、鏈路帶寬容量和中間節(jié)點(diǎn)的處理能力等。下面將詳細(xì)說明網(wǎng)絡(luò)資源與網(wǎng)絡(luò)擁塞的關(guān)系。</p><p>　　(1) 存儲(chǔ)空間不足。當(dāng)一個(gè)端

32、口收到幾個(gè)輸入端的報(bào)文時(shí)，接收的報(bào)文就會(huì)在這個(gè)端口的緩沖區(qū)中排隊(duì)。如果沒有足夠的存儲(chǔ)空間存儲(chǔ)，當(dāng)緩沖區(qū)占滿時(shí)，報(bào)文就會(huì)被丟棄。適當(dāng)增加存儲(chǔ)空間可以緩解擁塞，如果過于增加存儲(chǔ)空間，報(bào)文會(huì)因在緩沖區(qū)中排隊(duì)時(shí)間過長而超時(shí)，導(dǎo)致源端重發(fā)，從而進(jìn)一步加重網(wǎng)絡(luò)擁塞。如圖1-1描述了過多的分組訪問同一個(gè)交換機(jī)的緩存所發(fā)生的擁塞現(xiàn)象。假設(shè)通信網(wǎng)絡(luò)中節(jié)點(diǎn)2，3，5同時(shí)發(fā)送數(shù)據(jù)分組給節(jié)點(diǎn)1，且分組的聚合速率大于節(jié)點(diǎn)1往外發(fā)送分組的速率，則一定會(huì)有分組儲(chǔ)存在

33、節(jié)點(diǎn)1的緩沖區(qū)，若這種情況持續(xù)較長時(shí)間的話，節(jié)點(diǎn)1的緩沖區(qū)會(huì)被占滿，隨后的分組就被丟棄。當(dāng)目的端發(fā)現(xiàn)有分組丟失時(shí)，要求源端重發(fā)，這樣更多的分組涌向節(jié)點(diǎn)1，從而更加重?fù)砣?lt;/p><p>　?。?）帶寬容量不足。低速鏈路對(duì)高速數(shù)據(jù)流的輸入也會(huì)產(chǎn)生擁塞。根據(jù)香農(nóng)信息理論，任何信道帶寬最大值，即信道容量可以這樣計(jì)算：C=BLog2(1+S/N)(N為信道白噪聲的平均功率，S為信源的平均功率，B為信道帶寬)。所有信源發(fā)

34、送的速率R必須小于或等于信道容量C。如果R>C，則在理論上無差錯(cuò)傳輸就是不可能的，并會(huì)在網(wǎng)絡(luò)低速鏈路處形成帶寬瓶頸，當(dāng)其滿足不了通過它的所有源端帶寬要求時(shí)，網(wǎng)絡(luò)就會(huì)發(fā)生擁塞。</p><p>　?。?）處理器處理能力弱、速度慢。如果路由器的CPU在執(zhí)行排隊(duì)緩存，更新路由表等功能時(shí)，處理速度跟不上高速鏈路，也會(huì)產(chǎn)生擁塞。同樣，低速鏈路對(duì)高速CPU也會(huì)產(chǎn)生擁塞。</p><p>　　要避

35、免擁塞的發(fā)生，對(duì)以上3點(diǎn)原因需綜合考慮，合理分配和使用網(wǎng)絡(luò)資源。例如，提高鏈路速率而不增強(qiáng)處理器的處理能力，只會(huì)轉(zhuǎn)移網(wǎng)絡(luò)瓶頸，而不能避免擁塞。所以擁塞往往也是網(wǎng)絡(luò)系統(tǒng)各部分資源不匹配、不協(xié)調(diào)的結(jié)果。擁塞一旦發(fā)生往往會(huì)形成一個(gè)不斷加重的過程。如果路由器沒有空余的緩存，它就必須丟棄新到的數(shù)據(jù)包。當(dāng)數(shù)據(jù)包丟棄時(shí)，源端超時(shí)計(jì)時(shí)器會(huì)超時(shí)，要求重傳該包。由于沒有得到確認(rèn)，源端只能保留數(shù)據(jù)包，結(jié)果緩存會(huì)進(jìn)一步消耗，加重?fù)砣Ｒ虼?，擁塞控制是一個(gè)動(dòng)態(tài)的

36、、全局性的復(fù)雜過程，涉及到所有的主機(jī)、所有的路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。</p><p><b>　　1.2 擁塞控制</b></p><p>　　為了最大限度地利用資源，使網(wǎng)絡(luò)工作在輕度擁塞狀態(tài)是最為理想的，但這增加了滑向擁塞崩潰的風(fēng)險(xiǎn)，因此需要一定的擁塞控制機(jī)制來加以約束和限制。</p><p>　　為了便于闡述擁塞控制

37、機(jī)制的內(nèi)涵，我們首先用圖1-2來描述擁塞現(xiàn)象。當(dāng)網(wǎng)絡(luò)負(fù)載較小時(shí)，吞吐量基本上隨著負(fù)載的增長而增長，呈線性關(guān)系，響應(yīng)時(shí)間增長緩慢。當(dāng)負(fù)載達(dá)到網(wǎng)絡(luò)容量時(shí)，吞吐量呈現(xiàn)出緩慢增長，而響應(yīng)時(shí)間急劇增加，這一點(diǎn)稱為Knee。如果負(fù)載繼續(xù)增加，路由器就開始丟包，當(dāng)負(fù)載超過一定量時(shí)，吞吐量開始急劇下降，這一點(diǎn)稱為Cliff。</p><p>　　擁塞控制機(jī)制包含擁塞避免(Congestion Avoidance)和擁塞控制(Co

38、ngestion Control)兩種策略。前者的目的是使網(wǎng)絡(luò)運(yùn)行在Knee附近，避免擁塞的發(fā)生；而后者則是使得網(wǎng)絡(luò)運(yùn)行在Cliff的左側(cè)區(qū)域。前者是一種“預(yù)防”措施，維持網(wǎng)絡(luò)的高吞吐量、低延遲狀態(tài)，避免進(jìn)入擁塞；后者是一種“恢復(fù)”措施，使網(wǎng)絡(luò)從擁塞中恢復(fù)過來，進(jìn)入正常的運(yùn)行狀態(tài)。擁塞控制能夠有效地預(yù)防死鎖的發(fā)生，提高網(wǎng)絡(luò)的性能，其作用不言而喻。在下一章節(jié)，我們將詳細(xì)介紹TCP擁塞控制機(jī)制。</p><p>&l

39、t;b>　　2．TCP擁塞控制</b></p><p>　　2.1 TCP協(xié)議簡介</p><p>　　TCP(Transmission Control Protocol)協(xié)議是完成端到端信息傳輸?shù)膫鬏攲訁f(xié)議，是TCP/IP協(xié)議族的重要成員。TCP協(xié)議主要由差錯(cuò)控制機(jī)制和擁塞控制機(jī)制組成，它能夠自動(dòng)適應(yīng)網(wǎng)絡(luò)狀況的變化。</p><p>　　TCP協(xié)

40、議引入差錯(cuò)控制機(jī)制的目的是保障端到端傳輸?shù)目煽啃?，為無連接的IP網(wǎng)絡(luò)提供基于連接的傳輸服務(wù)。</p><p>　　TCP擁塞控制機(jī)制的意義更為重大，它可以根據(jù)網(wǎng)絡(luò)狀況對(duì)發(fā)送速率進(jìn)行調(diào)節(jié)，避免擁塞的擴(kuò)大，這使得互聯(lián)網(wǎng)絡(luò)的正常運(yùn)行成為可能。它所采用的擁塞控制算法本質(zhì)上是一種窗口上限可變的滑窗(Sliding-Window)式流量控制方法，是對(duì)滑窗流控算法的繼承和發(fā)展。傳統(tǒng)的滑窗式流控算法的窗口上限是固定的，發(fā)送端每發(fā)

41、送一個(gè)報(bào)文其發(fā)送窗口減小一個(gè)單位，而每接收到一個(gè)報(bào)文的確認(rèn)，發(fā)送窗口增加一個(gè)單位，這樣終端在一個(gè)輪次中能夠發(fā)送報(bào)文的最大個(gè)數(shù)是確定的，因此，在鏈路帶寬充足的情況下，發(fā)送端的傳輸能力將受到發(fā)送窗口上限的限制。TCP流控算法對(duì)傳統(tǒng)的滑窗算法進(jìn)行了擴(kuò)展，根據(jù)網(wǎng)絡(luò)狀況對(duì)窗口上限進(jìn)行調(diào)節(jié)。在TCP算法中，窗口上限由發(fā)送端的發(fā)送窗口和接收端的通知窗口共同決定(取兩者中的最小值)。這樣，在網(wǎng)絡(luò)正常工作時(shí)，TCP發(fā)送端可以通過增大窗口上限盡可能多地占用

42、網(wǎng)絡(luò)空閑帶寬；而當(dāng)網(wǎng)絡(luò)發(fā)生擁塞時(shí)，TCP發(fā)送端可以通過減小發(fā)送窗口上限的方式降低發(fā)送速率，從而起到緩解擁塞的作用。</p><p>　　2.2 TCP擁塞控制所要解決的主要問題</p><p>　　要改善TCP傳輸?shù)姆€(wěn)定性，減少擁塞的發(fā)生，或者要與非標(biāo)準(zhǔn)TCP應(yīng)用在同一網(wǎng)絡(luò)中共存，采取一定的TCP擁塞控制機(jī)制是必要的。TCP擁塞控制需要解決的主要問題有:</p><p&

43、gt;　　第一、滿足低的報(bào)文丟棄率的要求，提高帶寬利用率。</p><p>　　第二、高TCP傳輸?shù)姆€(wěn)定性，減少網(wǎng)絡(luò)狀態(tài)的振蕩。</p><p>　　第三、保證TCP公平，即TCP友好特性。</p><p>　　2.3 TCP擁塞控制涉及到的參數(shù)</p><p>　　TCP擁塞控制機(jī)制是通過控制一些重要參數(shù)的改變來實(shí)現(xiàn)的。用于TCP擁塞控制的

44、參數(shù)主要有:</p><p>　　(1)擁塞窗口(cwnd)：是擁塞控制的關(guān)鍵參數(shù)。它描述發(fā)送端在擁塞控制情況下一次最多能發(fā)送的數(shù)據(jù)包數(shù)量。</p><p>　　(2)通知窗口(awnd)：是接收端給發(fā)送端預(yù)設(shè)的發(fā)送窗口大小，它只在TCP連接建立的初始階段起作用。</p><p>　　(3)發(fā)送窗口(win)：是發(fā)送端每次實(shí)際發(fā)送數(shù)據(jù)的窗口大小。</p>

45、<p>　　(4)慢啟動(dòng)門限(ssthresh)：是擁塞控制中用來限制發(fā)送窗口大小的門限值，它是慢啟動(dòng)階段和擁塞避免階段的分界點(diǎn)，初始值設(shè)為65535字節(jié)或awnd的大小。</p><p>　　(5)回路響應(yīng)時(shí)間(RTT)：一個(gè)TCP數(shù)據(jù)包從發(fā)送端發(fā)送直至發(fā)送端收到確認(rèn)的時(shí)間間隔。</p><p>　　(6)重傳超時(shí)時(shí)長(RTO)：描述數(shù)據(jù)包從發(fā)送到失效的時(shí)間間隔，是判斷數(shù)據(jù)

46、包丟失與否、網(wǎng)絡(luò)是否擁塞的重要參數(shù)，通常設(shè)為2RTT或5RTT。</p><p>　　下面將介紹TCP擁塞控制機(jī)制是如何改變上述參數(shù)以達(dá)到控制網(wǎng)絡(luò)擁塞、提高網(wǎng)絡(luò)性能的目的的。</p><p>　　2.4 TCP擁塞控制機(jī)制</p><p>　　TCP的擁塞控制機(jī)制是由慢啟動(dòng)、擁塞避免、快速重傳和快速恢復(fù)四個(gè)核心算法組成的。慢啟動(dòng)階段用于快速探測并占有網(wǎng)絡(luò)可用帶寬；擁

47、塞避免階段是數(shù)據(jù)傳輸?shù)闹饕獣r(shí)段；快速重傳則完成了丟失報(bào)文的重傳；而快速恢復(fù)避免了由于過度地減小發(fā)送窗口而導(dǎo)致網(wǎng)絡(luò)性能下降的發(fā)生，使得網(wǎng)絡(luò)迅速從擁塞狀態(tài)中恢復(fù)。圖2-1描述了TCP擁塞控制中慢啟動(dòng)和擁塞避免兩個(gè)階段的動(dòng)態(tài)情況。有關(guān)它們的具體實(shí)現(xiàn)將在下一節(jié)詳細(xì)闡述。</p><p>　　2.5 TCP擁塞控制算法</p><p>　　TCP協(xié)議經(jīng)過多年的發(fā)展，有了多種具體的實(shí)現(xiàn)，其中包括Tah

48、oe、Reno、NewReno、SACK和Vegas TCP。運(yùn)行在主機(jī)中的這些實(shí)現(xiàn)使得TCP連接在網(wǎng)絡(luò)發(fā)生擁塞時(shí)回退，并對(duì)網(wǎng)絡(luò)中的擁塞信號(hào)進(jìn)行響應(yīng)，正是這些改進(jìn)的TCP實(shí)現(xiàn)的擁塞避免和擁塞控制算法防止了今天網(wǎng)絡(luò)的擁塞崩潰。下面詳細(xì)介紹這些TCP實(shí)現(xiàn)以及運(yùn)用于這些實(shí)現(xiàn)中的擁塞避免和擁塞控制算法。</p><p>　　2.5.1 Tahoe</p><p>　　Tahoe算法是最早被提出來的

49、TCP擁塞控制算法，雖然已歷經(jīng)近二十年，但至今仍被大多數(shù)TCP實(shí)現(xiàn)所采用。它的一些經(jīng)典理論也被后來的大多數(shù)TCP擁塞控制算法所沿用，為后繼算法奠定了基礎(chǔ)。其核心思想是讓cwnd以指數(shù)型增長方式迅速逼進(jìn)可用信道容量，然后慢慢接近均衡。Tahoe包括慢啟動(dòng)、擁塞避免和快速重傳三個(gè)部分。</p><p>　　(1)慢啟動(dòng) </p><p>　　初始時(shí)，cwnd值設(shè)置為1，每收到一個(gè)成功的A

50、CK，則：</p><p>　　cwnd = cwnd + 1</p><p>　　理想情況下，在一個(gè)RTT內(nèi)，發(fā)送端會(huì)收到cwnd個(gè)成功的ACK。這樣，每隔一個(gè)RTT:</p><p>　　cwnd = 2*cwnd</p><p>　　即在慢啟動(dòng)階段，cwnd以指數(shù)型增長，直到cwnd超過ssthresh值。當(dāng)cwnd>=ssthr

51、esh時(shí)，Tahoe進(jìn)入擁塞避免階段。</p><p>　　慢啟動(dòng)的目的是避免連接建立時(shí)大量突發(fā)數(shù)據(jù)流可能造成的擁塞。</p><p>　　(2)擁塞避免 </p><p>　　在擁塞避免階段，每收到一個(gè)成功的ACK，則：</p><p>　　cwnd = cwnd + 1 / cwnd</p><p>　　因此

52、，每隔一個(gè)RTT， cwnd增1。即在擁塞避免階段，cwnd線性增加。</p><p>　　如果發(fā)生超時(shí)或者連續(xù)收到3個(gè)重復(fù)的ACK（簡稱dup ACK），Tahoe就認(rèn)為網(wǎng)絡(luò)發(fā)生了擁塞。</p><p>　　對(duì)于超時(shí)，ssthresh = max(cwnd/2，2)</p><p><b>　　cwnd =1</b></p>&

53、lt;p><b>　　然后轉(zhuǎn)入慢啟動(dòng)。</b></p><p>　　若是收到連續(xù)3個(gè)dup ACK，則Tahoe進(jìn)入快速重傳階段。</p><p>　　可以看到，當(dāng)算法進(jìn)入擁塞避免階段后，擁塞窗口的增長趨于平緩，避免了擁塞窗口持續(xù)快速增長可能導(dǎo)致的擁塞。</p><p>　　(3)快速重傳 </p><p>

54、　　在此階段，首先立即重發(fā)丟失的分組，而不必等待重傳定時(shí)器超時(shí)，同時(shí)設(shè)置:</p><p>　　ssthresh=max(cwnd/2，2) </p><p><b>　　cwnd =1</b></p><p>　　然后，轉(zhuǎn)入慢啟動(dòng)階段?？焖僦貍骷涌炝怂惴ǖ捻憫?yīng)速度，減少了重傳超時(shí)的發(fā)生。</p><p>　　Ta

55、hoe核心算法可簡單描述為:</p><p>　　for every ack</p><p>　　{if cwnd < ssthresh then</p><p>　　cwnd++ //慢速啟動(dòng)</p><p>　　else cwnd +=1/cwnd //擁塞避免</p><p><

56、;b>　　}</b></p><p>　　for every loss //快速重傳</p><p>　　{ssthresh =max(cwnd/2，2)</p><p><b>　　cwnd=1</b></p><p><b>　　}</b></p>&l

57、t;p>　　Tahoe算法的提出使得TCP由以前的單純流量控制轉(zhuǎn)向擁塞控制，它明確地將TCP數(shù)據(jù)流的發(fā)送過程劃分為三個(gè)階段，慢啟動(dòng)避免了連接建立時(shí)突發(fā)數(shù)據(jù)流對(duì)網(wǎng)絡(luò)的沖擊；擁塞避免限制了在傳輸過程中無限制的速率增長，避免了由此可能導(dǎo)致的擁塞；快速重傳則加快了發(fā)送端對(duì)擁塞的響應(yīng)速度，使得擁塞能快速地消除。</p><p>　　2.5.2 Reno</p><p>　　Reno算法是對(duì)Ta

58、hoe的改進(jìn)，從上一小節(jié)我們可以看到，在收到連續(xù)3個(gè)dup ACK或在超時(shí)的情況下，Tahoe設(shè)置cwnd為l，然后進(jìn)入慢啟動(dòng)階段。這一方面會(huì)引起網(wǎng)絡(luò)的激烈振蕩，另一方面大大降低了網(wǎng)絡(luò)的利用率。針對(duì)這個(gè)問題，1990年Jacobson在Tahoe的基礎(chǔ)上提出了Reno算法。</p><p>　　Reno算法對(duì)Tahoe的改進(jìn)主要在兩個(gè)方面。第一，收到連續(xù)3個(gè)dup ACK后，算法不經(jīng)過慢啟動(dòng)，而直接進(jìn)入擁塞避免階

59、段。第二，增加了快速重傳/快速恢復(fù)(FR/FR)機(jī)制。事實(shí)上，每一個(gè)dup ACK表明已經(jīng)有一個(gè)數(shù)據(jù)包離開了網(wǎng)絡(luò)，不管它是不是我們所期望的。根據(jù)Jacobson的數(shù)據(jù)守恒理論(見2.5.3小節(jié))，發(fā)送端這時(shí)可以向網(wǎng)絡(luò)發(fā)送下一個(gè)數(shù)據(jù)包?？焖僦貍?快速恢復(fù)機(jī)制就是這樣做的。具體過程為:</p><p>　　(1)收到3個(gè)dup ACK進(jìn)入FR/FR</p><p>　　ssthresh =ma

60、x(cwnd/2，2)</p><p>　　(2)重發(fā)丟失的數(shù)據(jù)包</p><p><b>　　(3)窗口膨脹</b></p><p>　　cwnd =ssthresh + ndup</p><p>　　ndup為收到的dup ACK數(shù)。</p><p>　　(4)當(dāng)min(awnd， cwnd)

61、足夠大時(shí)，發(fā)送新的數(shù)據(jù)包</p><p>　　(5)當(dāng)收到非重復(fù)的ACK時(shí) cwnd =ssthresh</p><p>　　(6)轉(zhuǎn)入擁塞避免階段</p><p>　　經(jīng)過分析，可以看出：Reno在收到3個(gè)dup ACK后，就轉(zhuǎn)入FR/FR，而遇到超時(shí)后，Reno和Tahoe一樣進(jìn)入慢啟動(dòng)階段?？梢詮腞eno狀態(tài)轉(zhuǎn)換圖直觀地看到Reno的整個(gè)數(shù)據(jù)傳輸過程。<

62、;/p><p>　　Reno目前被廣泛采用，以其算法的簡單、有效和魯棒性成為TCP擁塞控制算法的主流。針對(duì)Reno的局限性，一些新算法如：NewReno，SACK等對(duì)其進(jìn)行了改進(jìn)。</p><p>　　2.5.3 NewReno</p><p>　　Reno TCP提出的快速恢復(fù)算法提高了報(bào)文丟失后TCP的吞吐量和頑健性，但是它僅考慮了每次擁塞發(fā)生時(shí)只丟失一個(gè)報(bào)文的情形

63、。然而在實(shí)際網(wǎng)絡(luò)中，一旦發(fā)生擁塞，路由器會(huì)丟棄大量的報(bào)文(對(duì)于采用Drop Tail的路由器而言，丟棄尤為嚴(yán)重)，TCP在一次擁塞中丟失多個(gè)報(bào)文的情形非常普遍。在這種情況下，采用Reno TCP算法的發(fā)送端多次將cwnd和ssthresh減半，其結(jié)果是TCP的發(fā)送速率呈指數(shù)降低，系統(tǒng)吞吐量急劇下降，更有甚者，當(dāng)發(fā)送窗口小于4 時(shí)無法有效地觸發(fā)快速重傳，Reno TCP發(fā)送端會(huì)陷入僅通過傳輸超時(shí)來發(fā)現(xiàn)報(bào)文丟失的困境中。</p>

64、<p>　　NewReno在Reno的基礎(chǔ)上對(duì)快速恢復(fù)算法進(jìn)行了修改，添加了恢復(fù)應(yīng)答(Recovery ACK)判斷功能，以增強(qiáng)TCP發(fā)送端通過ACK報(bào)文信息分析報(bào)文傳輸狀況的能力。NewReno使TCP發(fā)送端可以把一次擁塞丟失多個(gè)報(bào)文的情形與多次擁塞的情形區(qū)分開來，進(jìn)而在每一次擁塞發(fā)生后擁塞窗口僅減半一次，從而提高了TCP的頑健性和吞吐量。 </p><p>　　恢復(fù)應(yīng)答(Recovery ACK

65、)— 改進(jìn)的快速恢復(fù)算法</p><p>　　為了介紹NewReno中改進(jìn)的快速恢復(fù)算法，首先定義部分應(yīng)答(Partial ACK，簡稱PACK)和恢復(fù)應(yīng)答(Recovery ACK，簡稱RACK)報(bào)文。</p><p>　　把TCP發(fā)送端恢復(fù)階段中接收到的ACK報(bào)文（非dup ACK)記為ACKx，在接收到ACKx時(shí)TCP終端己發(fā)出的序列號(hào)(SN)最大的報(bào)文記為PKTy，如果ACKx不是

66、PKTy的應(yīng)答報(bào)文則稱報(bào)文ACKx為部分應(yīng)答，即PACK報(bào)文；反之，若ACKx恰好是PKTy的應(yīng)答報(bào)文，則報(bào)文ACKx被稱為恢復(fù)應(yīng)答，即RACK報(bào)文。TCP發(fā)送端接收到恢復(fù)應(yīng)答表明：經(jīng)過重傳，TCP發(fā)送端發(fā)送的所有報(bào)文都己經(jīng)被接收端正確接收，網(wǎng)絡(luò)已經(jīng)從擁塞中恢復(fù)。</p><p>　　經(jīng)過NewReno改進(jìn)的快速恢復(fù)算法可以描述為以下幾個(gè)步驟:</p><p>　　1. 重新定義“恢復(fù)階段

67、”，這里把從快速重傳算法發(fā)現(xiàn)丟失報(bào)文到TCP發(fā)送端接收到RACK報(bào)文的時(shí)段稱為恢復(fù)階段。</p><p>　　2. 進(jìn)入恢復(fù)階段后，TCP發(fā)送端重傳被認(rèn)定為丟失的報(bào)文，并分別設(shè)置ssthresh和cwnd如下：</p><p>　　ssthresh =max(cwnd/2，2) </p><p>　　cwnd = ssthresh + 3*SMSS</

68、p><p>　　3. 當(dāng)接收到dup ACK后，TCP發(fā)送端按照式子cwnd =ssthresh + ndup對(duì)cwnd進(jìn)行設(shè)定(與Reno TCP的設(shè)定方式相似)。</p><p>　　4. 當(dāng)接收到PACK后，TCP發(fā)送端立即重傳PACK所確認(rèn)報(bào)文的下一個(gè)報(bào)文，擁塞窗口不受影響。</p><p>　　5. 當(dāng)接收到RACK后，TCP發(fā)送端認(rèn)為擁塞中所有被丟棄的報(bào)文均

69、已被重傳，擁塞結(jié)束，設(shè)置cwnd為發(fā)生擁塞時(shí)的cwnd的一半，最后退出恢復(fù)階段，進(jìn)入擁塞避免階段。</p><p>　　快速恢復(fù)是基于“數(shù)據(jù)包守恒”原則(Conservation of Packets Principle) 的，即同一時(shí)刻在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)包數(shù)量是恒定的，只有當(dāng)“舊”數(shù)據(jù)包離開網(wǎng)絡(luò)后，才能發(fā)送“新”數(shù)據(jù)包進(jìn)入網(wǎng)絡(luò)。重傳丟失的數(shù)據(jù)包后，不從慢啟動(dòng)開始的原因是，一個(gè)dup ACK不僅意味著有一個(gè)包丟失

70、了，而且表示有一個(gè)被發(fā)送的數(shù)據(jù)包離開了網(wǎng)絡(luò)，己經(jīng)在接收端的緩沖區(qū)中，它不再占有網(wǎng)絡(luò)資源。</p><p>　　2.5.4 SACK</p><p>　　SACK TCP也是對(duì)Reno TCP的擴(kuò)展，在Reno TCP的基礎(chǔ)上增加了選擇確認(rèn)SACK (Selective Acknowledgments)和選擇重傳(Selective Retransmission)。當(dāng)一個(gè)窗口內(nèi)有多個(gè)數(shù)據(jù)包丟

71、失時(shí)，SACK TCP增加了SACK選項(xiàng)，允許接收端在ACK中報(bào)告其接收到的不連續(xù)(No-Sequential)的報(bào)文，這樣，發(fā)送端就能準(zhǔn)確地知道哪些數(shù)據(jù)包被接收端正確地接收。發(fā)送端使用選擇性重傳機(jī)制，可以在一個(gè)窗口中一次重傳所有從一個(gè)窗口中丟失的數(shù)據(jù)包，從而減少了時(shí)延，提高了網(wǎng)絡(luò)吞吐量，也使得TCP更快地從擁塞狀態(tài)恢復(fù)。</p><p>　　同樣是一個(gè)窗口丟多個(gè)包的情況，如果沒有SACK，發(fā)送端或者在每個(gè)RTT

72、的時(shí)間內(nèi)最多只能重傳一個(gè)丟失的包，或者連那些己經(jīng)被正確接收的報(bào)文一起重傳。Reno TCP和NewReno TCP采用的是第一種策略，而Tahoe TCP則采用了第二種。</p><p>　　為了詳細(xì)介紹SACK TCP，先引進(jìn)兩個(gè)概念：pipe變量和數(shù)據(jù)結(jié)構(gòu)scoreboard。pipe的值為TCP發(fā)送端發(fā)出的未被確認(rèn)的數(shù)據(jù)包數(shù)的估計(jì)值；數(shù)據(jù)結(jié)構(gòu)scoreboard被保存在發(fā)送端，用來記錄上一個(gè)SACK選項(xiàng)中記

73、錄的確認(rèn)報(bào)文。</p><p>　　經(jīng)過SACK TCP改進(jìn)的快速恢復(fù)算法如下:</p><p>　　1. 在快速恢復(fù)階段，只有當(dāng)pipe的值小于cwnd時(shí)，發(fā)送端才發(fā)送新數(shù)據(jù)包或重傳丟失的數(shù)據(jù)包。發(fā)送端發(fā)送或重傳一個(gè)數(shù)據(jù)包后，pipe值加1；收到一個(gè)包含有SACK選項(xiàng)用以報(bào)告新的數(shù)據(jù)被成功接收的dup ACK后，pipe值減1。</p><p>　　2. 當(dāng)發(fā)送端

74、可以發(fā)送數(shù)據(jù)包時(shí)，它根據(jù)scoreboard重傳丟失的數(shù)據(jù)包，如果沒有數(shù)據(jù)包丟失，則發(fā)送新的數(shù)據(jù)包。</p><p>　　3. 如果發(fā)送端收到PACK，pipe值減去2。因?yàn)镻ACK表示兩個(gè)數(shù)據(jù)包離開了網(wǎng)絡(luò)，一個(gè)是丟失的數(shù)據(jù)包，另一個(gè)是重傳的數(shù)據(jù)包。</p><p>　　4. 當(dāng)發(fā)送端收到RACK后退出快速恢復(fù)階段。</p><p>　　2.5.5 Vegas<

75、;/p><p>　　Vegas TCP與上述算法有很大不同，它根據(jù)TCP連接中的回路響應(yīng)時(shí)間RTT值的改變情況來控制cwnd的大小。如果發(fā)現(xiàn)RTT變大那么就認(rèn)為網(wǎng)絡(luò)發(fā)生擁塞，并開始減小cwnd；如果RTT變小，Vegas就認(rèn)為網(wǎng)絡(luò)擁塞正在解除，則相應(yīng)增加cwnd。Vegas的最大優(yōu)點(diǎn)在于擁塞機(jī)制的觸發(fā)只與RTT的改變有關(guān)，而與數(shù)據(jù)包的具體傳輸時(shí)延無關(guān)。</p><p>　　Vegas采用的重傳

76、策略也與Tahoe、Reno不同。Vegas能更加及時(shí)地重傳丟失的數(shù)據(jù)包，它不是等到連續(xù)收到3個(gè)dup ACK后才進(jìn)行重傳，而是當(dāng)收到第一個(gè)dup ACK后，比較數(shù)據(jù)包發(fā)出的時(shí)間和當(dāng)前時(shí)間，然后決定是否重發(fā)，這就明顯提高了響應(yīng)速度。當(dāng)達(dá)到均衡時(shí)，Vegas具有零丟包率、穩(wěn)定的窗口大小、滿負(fù)荷使用效率等優(yōu)點(diǎn)。</p><p>　　但是Vegas TCP并未能在互聯(lián)網(wǎng)上大規(guī)模使用，主要原因是使用Vegas TCP的流

77、在帶寬競爭能力方面不及未使用Vegas TCP的流，從而導(dǎo)致網(wǎng)絡(luò)資源使用不公平，而不是算法本身的問題。</p><p>　　2.6 TCP擁塞控制算法的特點(diǎn)</p><p>　　TCP算法最根本的特點(diǎn)是通過累積確認(rèn)(Cumulative Acknowledgement)的方式獲知已發(fā)送報(bào)文的傳輸情況，通過加增大乘減小(Additive Increase Multiplicative Dec

78、rease，即AIMD)的擁塞控制策略對(duì)發(fā)送流量進(jìn)行調(diào)節(jié)以避免擁塞的發(fā)生。</p><p>　　累積確認(rèn)方式使得TCP通信過程具有顯明的周期性：TCP發(fā)送端在發(fā)送窗口允許的范圍內(nèi)盡可能地發(fā)送報(bào)文，在發(fā)送窗口閉合后則暫停發(fā)送處于等待狀態(tài)，直至下一個(gè)輪次發(fā)送的開始。這種發(fā)送報(bào)文——等待確認(rèn)——再發(fā)送報(bào)文的過程被形象地稱為自時(shí)鐘(Self Clock)。</p><p>　　總之，TCP算法通過

79、窗口增長探測網(wǎng)絡(luò)可用的傳輸帶寬，當(dāng)傳輸出現(xiàn)報(bào)文丟失時(shí)，TCP算法即認(rèn)為發(fā)送速率己經(jīng)超過網(wǎng)絡(luò)可用帶寬，此時(shí)的發(fā)送速率將被作為以后速率調(diào)整的參考。TCP算法通過累積確認(rèn)發(fā)現(xiàn)報(bào)文丟失，一旦發(fā)現(xiàn)有報(bào)文被丟棄，TCP終端將下調(diào)發(fā)送速率，直到丟棄報(bào)文被成功傳輸為止。這樣的特性使得TCP的發(fā)送速率的變化具有周期性，同時(shí)也為TCP吞吐量的分析提供了便利。</p><p>　　2.7 TCP擁塞控制算法存在的主要問題</p&

80、gt;<p>　　TCP擁塞控制機(jī)制在互聯(lián)網(wǎng)中發(fā)揮了行之有效的作用，但TCP擁塞控制算法自身存在的問題也是不容忽視的:</p><p>　　(1)端系統(tǒng)從發(fā)生擁塞到實(shí)施控制之間有著明顯的時(shí)延，而且端系統(tǒng)缺乏對(duì)數(shù)據(jù)傳輸過程的動(dòng)態(tài)性了解，無法預(yù)知網(wǎng)絡(luò)資源的使用情況，目前主要是通過降低發(fā)送到網(wǎng)絡(luò)的數(shù)據(jù)流量來減小網(wǎng)絡(luò)負(fù)載，從而緩解擁塞。</p><p>　　(2)慢啟動(dòng)算法中存在的問

81、題尤為突出。首先，由于在慢啟動(dòng)階段發(fā)送端無法了解瓶頸鏈路帶寬，每個(gè)RTT內(nèi)都會(huì)將cwnd增加一倍，如果ssthresh較大，那么發(fā)送端窗口增加到足夠大時(shí)，會(huì)丟失接近一半的數(shù)據(jù)包；其次，慢啟動(dòng)是按照事先設(shè)定好的參數(shù)開始數(shù)據(jù)傳輸?shù)模琧wnd和 ssthresh一般分別取1個(gè)和64個(gè)數(shù)據(jù)包大小，TCP連接在經(jīng)歷擁塞后也使用慢啟動(dòng)算法重新開始通信，在網(wǎng)絡(luò)可用帶寬較大時(shí)，會(huì)造成網(wǎng)絡(luò)資源利用率降低及延遲增加；再次，TCP基于窗口的擁塞控制機(jī)制對(duì)于傳

82、輸大批量文件具有良好的適應(yīng)性，但是為www應(yīng)用等短小數(shù)據(jù)流服務(wù)時(shí)性能較差，往往需要幾個(gè)RTT時(shí)間探測合適的網(wǎng)絡(luò)帶寬，傳輸延遲較大。</p><p>　　(3)公平性問題。Internet采取的基于源端的擁塞控制策略是不公平的，TCP擁塞控制中的公平性問題主要表現(xiàn)在以下兩個(gè)方面:</p><p>　　1)TCP中擁塞窗口大小可以表示為RTT的函數(shù)，比如，慢啟動(dòng)階段cwnd隨RTT呈指數(shù)增長，

83、擁塞避免階段cwnd隨RTT線性增長，這樣對(duì)于長延遲的連接來講，由于其窗口增長速度慢，因而在同樣的條件下獲得的帶寬也就越少，特別是在慢啟動(dòng)過程中，RTT長的連接的劣勢就表現(xiàn)得更為明顯；</p><p>　　2)TCP提供端到端的可靠傳輸服務(wù)，在檢測到擁塞后會(huì)自覺地降低發(fā)送速率，隨著網(wǎng)絡(luò)中不遵守TCP協(xié)議的各種數(shù)據(jù)流的出現(xiàn)，TCP流在與這些數(shù)據(jù)流共存時(shí)，其競爭力較弱，往往會(huì)喪失應(yīng)有的帶寬，因此公平地共享帶寬也是一個(gè)

84、需要迫切關(guān)注的問題。</p><p>　　針對(duì)以上TCP擁塞控制中存在的問題，近年來，許多科研人員對(duì)這些問題進(jìn)行了方方面面的研究和改進(jìn)，以便更好地符合各種網(wǎng)絡(luò)應(yīng)用的需要，適應(yīng)網(wǎng)絡(luò)動(dòng)態(tài)變化的特性，使網(wǎng)絡(luò)運(yùn)行在最佳狀態(tài)。</p><p>　　2.8 TCP擁塞控制算法的改進(jìn)</p><p>　　對(duì)于TCP擁塞控制存在的問題，目前主要針對(duì)以下幾個(gè)方面進(jìn)行了改進(jìn):</

85、p><p>　　(1)針對(duì)不必要的超時(shí)重傳和快速重傳</p><p>　　當(dāng)前的TCP應(yīng)用主要有兩種重傳機(jī)制：快速重傳和超時(shí)重傳。當(dāng)TCP發(fā)送端收到3個(gè)ACK確認(rèn)信息時(shí)就會(huì)觸發(fā)快速重傳機(jī)制，此時(shí)發(fā)送端重傳丟失的數(shù)據(jù)包并且將cwnd減半。這種情況下，TCP流往往能夠很快從丟包中恢復(fù)過來，重新回到原先的發(fā)送速率。但如果TCP發(fā)送端沒有收到3個(gè)ACK信號(hào)，例如cwnd值小于4，那么TCP發(fā)送端則需要

86、等待相當(dāng)長時(shí)間，以便超時(shí)重傳。這樣，小窗口的TCP流就很容易陷入不必要的超時(shí)重傳，使其吞吐量大大下降。</p><p>　　為了避免這種不必要的超時(shí)重傳，一種改進(jìn)辦法就是只要TCP發(fā)送端收到一個(gè)或兩個(gè)ACK信號(hào)，并且如果通知窗口awnd允許，便繼續(xù)發(fā)送新的數(shù)據(jù)包。這是因?yàn)橹灰盏紸CK信號(hào)，就表明有數(shù)據(jù)包已經(jīng)離開網(wǎng)絡(luò)被接收端接收了，而此時(shí)發(fā)送端還無法判斷數(shù)據(jù)包是否被丟棄，根據(jù)“數(shù)據(jù)包守恒”原則，發(fā)送端就可以繼續(xù)發(fā)

87、送新的數(shù)據(jù)包。</p><p>　　(2)針對(duì)亂序包和延遲包引起的重傳</p><p>　　在不少情況下，TCP發(fā)送端推斷認(rèn)為數(shù)據(jù)包被丟棄了，例如超時(shí)計(jì)時(shí)器過早到時(shí)了(事實(shí)上數(shù)據(jù)包或者ACK并沒有丟失，只要再等待一會(huì)便可收到)，發(fā)送端便毫無必要地重傳了數(shù)據(jù)包，而實(shí)際上數(shù)據(jù)包并沒有被丟棄。類似地，如果由于數(shù)據(jù)包的亂序?qū)е掳l(fā)送端接收到3個(gè)ACK信號(hào)，便會(huì)觸發(fā)快速重傳，TCP源端也沒有必要地重發(fā)

88、了數(shù)據(jù)包，并減小了擁塞窗口，對(duì)于前者，雖然可以通過更為精確地調(diào)節(jié)超時(shí)時(shí)鐘來減少不必要的超時(shí)重傳，但要完全避免卻是不可能的。同樣，對(duì)于后者，雖然可以通過提高快速重傳算法的性能來減少不必要的快速重傳，但也不可能完全避免。</p><p>　　為了使得在不必要的超時(shí)重傳和快速重傳情況下，TCP性能更加具有魯棒性，一種方法就是出現(xiàn)這些情況時(shí)向TCP發(fā)送端反饋有關(guān)的信息。這個(gè)工作已經(jīng)由D-SACK擴(kuò)展(duplicate-

89、SACK extension)完成了。D-SACK擴(kuò)展允許TCP接收端利用SACK選項(xiàng)來通報(bào)已收到的重復(fù)的數(shù)據(jù)包，從而TCP發(fā)送端能夠正確地推斷出接收端是否收到了重復(fù)的數(shù)據(jù)包，以此來避免不必要的重傳。</p><p>　　由此可見，目前還沒有一種TCP擁塞控制算法的設(shè)計(jì)和實(shí)現(xiàn)在所有的環(huán)境中都是“最好的”?，F(xiàn)有擁塞控制的思路、方法和技術(shù)在不同環(huán)境中面臨著挑戰(zhàn)，它們還有許多需要改進(jìn)的地方。</p>&l

90、t;p>　　3．網(wǎng)絡(luò)仿真軟件NS-2 </p><p>　　由于網(wǎng)絡(luò)的復(fù)雜性，目前網(wǎng)絡(luò)技術(shù)的研究很大程度上僅限于理論研究，在實(shí)際上的應(yīng)用比較困難。隨著計(jì)算機(jī)技術(shù)的發(fā)展，仿真工具在分析和研究復(fù)雜網(wǎng)絡(luò)中發(fā)揮了很大的作用，所以尋求性能優(yōu)越的仿真工具對(duì)于網(wǎng)絡(luò)技術(shù)的研究有著非常重要的意義。</p><p>　　NS-2(Network Simulator)是由UC Berkely大學(xué)開發(fā)的一個(gè)

91、基于事件驅(qū)動(dòng)的仿真器。它能近乎真實(shí)地模擬網(wǎng)絡(luò)環(huán)境在各個(gè)層次上的運(yùn)行，為低成本的實(shí)驗(yàn)提供了一個(gè)良好的環(huán)境，能夠方便地對(duì)已有的協(xié)議行為進(jìn)行驗(yàn)證，比較使用不同的算法對(duì)網(wǎng)絡(luò)性能造成的影響。</p><p>　　3.1 NS-2簡介</p><p>　　NS-2是面向?qū)ο蟮?，基于離散事件驅(qū)動(dòng)的網(wǎng)絡(luò)環(huán)境模擬器。它實(shí)現(xiàn)了多種網(wǎng)絡(luò)協(xié)議的模擬，如傳輸層的TCP、UDP協(xié)議，應(yīng)用層的FTP、 Telnet、W

92、eb協(xié)議；實(shí)現(xiàn)了DropTail、RED等幾種路由器隊(duì)列管理機(jī)制以及Dijkstra、動(dòng)態(tài)路由、靜態(tài)路由、組播路由等路由算法。此外，NS-2還支持組播協(xié)議SRM及部分MAC層的協(xié)議。NS-2用C++和Otcl語言編寫而成。它的一個(gè)突出優(yōu)點(diǎn)就是它的源代碼全部公開，提供開放的用戶接口，并且容易擴(kuò)展、配置，用戶可以很方便地將自己開發(fā)的新協(xié)議模塊集成到NS-2環(huán)境中。</p><p>　　3.2 使用NS-2進(jìn)行網(wǎng)絡(luò)模擬

93、的方法和一般過程</p><p>　　進(jìn)行模擬前，首先要分析模擬涉及哪個(gè)層次。NS-2模擬分兩個(gè)層次：一個(gè)是基于Otcl編程的層次，利用NS-2己有的網(wǎng)絡(luò)元素實(shí)現(xiàn)模擬，無需對(duì)NS-2本身進(jìn)行任何修改，只要編寫Otcl腳本；另一個(gè)層次是基于C++和Otcl編程的層次，如果NS-2中沒有所需的網(wǎng)絡(luò)元素，就需要首先對(duì)NS-2擴(kuò)展，添加所需要的網(wǎng)絡(luò)元素。這就需要利用分裂對(duì)象模型，添加新的C++和Otcl類，然后再編寫Ot

94、cl腳本。這個(gè)模擬過程如圖3-1所示。</p><p>　　進(jìn)行一次模擬過程如下：</p><p>　　(1)編寫Otcl腳本，配置模擬網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，確定鏈路的基本特性。</p><p>　　(2)建立協(xié)議代理，包括端設(shè)備的協(xié)議綁定和通信業(yè)務(wù)量模型的建立。</p><p>　　(3)配置業(yè)務(wù)量模型的參數(shù)，從而確定網(wǎng)絡(luò)上業(yè)務(wù)量分布。</p

95、><p>　　(4)設(shè)置Trace對(duì)象。Trace對(duì)象能夠把模擬過程中發(fā)生的特定類型的事件記錄在trace文件中。NS-2通過trace文件來保存整個(gè)模擬過程。仿真完成后，用戶可以對(duì)trace文件進(jìn)行分析研究。</p><p>　　(5)編寫其他的輔助過程，設(shè)定模擬結(jié)束時(shí)間，至此Otcl腳本編寫完成。</p><p>　　(6)利用NS-2解釋執(zhí)行剛才編寫的Otcl腳本

96、。</p><p>　　(7)分析trace文件，得到有用的數(shù)據(jù)，也可以使用Nam等工具觀看網(wǎng)絡(luò)模擬運(yùn)行過程。</p><p>　　(8)調(diào)整配置拓?fù)浣Y(jié)構(gòu)和業(yè)務(wù)量模型，重新進(jìn)行上述模擬過程。</p><p><b>　　4．仿真</b></p><p>　　下面我們通過仿真來比較上文提到的Tahoe、 Reno、NewR

97、eno、SACK四種TCP擁塞控制算法，它們都是以丟包作為擁塞信號(hào)的。仿真分為四組，TCP分別丟失1、2、3、4個(gè)包；每一組仿真都分別運(yùn)行四種TCP擁塞控制算法。在仿真中它們丟棄相同固定序列號(hào)的數(shù)據(jù)包，以此來比較它們對(duì)擁塞響應(yīng)的情況。</p><p>　　仿真所使用的網(wǎng)絡(luò)模型如圖4-1所示，共有五個(gè)節(jié)點(diǎn)，四段鏈路，每段鏈路的帶寬和時(shí)延都在圖中得以注明，節(jié)點(diǎn)3相當(dāng)于一個(gè)網(wǎng)關(guān)(GateWay)，下文提到的網(wǎng)關(guān)都是指節(jié)

98、點(diǎn)3。圖中共建立了三條TCP連接，其中節(jié)點(diǎn)0到節(jié)點(diǎn)4的TCP連接是我們所要研究的，而另外兩條連接發(fā)送有限的數(shù)據(jù)，它們的建立只是為我們所研究的第一條TCP連接創(chuàng)造丟包的條件，以便我們觀察節(jié)點(diǎn)0對(duì)丟包現(xiàn)象的反應(yīng)，從而研究節(jié)點(diǎn)0所采用的擁塞控制機(jī)制。仿真數(shù)據(jù)以包為單位，而不是以字節(jié)為單位，且發(fā)送端發(fā)送的所有數(shù)據(jù)包大小一致(1000字節(jié))。數(shù)據(jù)包的序列號(hào)SN從0開始計(jì)數(shù)，發(fā)送端每發(fā)送一個(gè)新的數(shù)據(jù)包，SN增加1，接收端每收到一個(gè)數(shù)據(jù)包就返回一個(gè)確

99、認(rèn)報(bào)文ACK。在本仿真中，ACK不與發(fā)送數(shù)據(jù)包產(chǎn)生沖突，且ACK不丟失。</p><p>　　我們使用網(wǎng)絡(luò)仿真軟件NS進(jìn)行仿真，使用的版本為NS-2.27，安裝在Windows XP系統(tǒng)上。</p><p>　　在四組仿真結(jié)果圖形中，橫坐標(biāo)為時(shí)間，以秒為單位，代表了數(shù)據(jù)包到達(dá)或離開網(wǎng)關(guān)的時(shí)間；縱坐標(biāo)為數(shù)據(jù)包的序列號(hào)（對(duì)100取模，即以100為單位）。圖形中，方塊標(biāo)示丟失的數(shù)據(jù)包，小圓點(diǎn)標(biāo)示

100、被網(wǎng)關(guān)收到的ACK，正三角形標(biāo)示每一個(gè)到達(dá)或離開網(wǎng)關(guān)的數(shù)據(jù)包。如果數(shù)據(jù)包經(jīng)過網(wǎng)關(guān)時(shí)幾乎沒有經(jīng)歷排隊(duì)時(shí)延，那么在圖表中對(duì)應(yīng)產(chǎn)生的兩個(gè)正三角形看起來就像一個(gè)。沒有被丟棄的數(shù)據(jù)包在圖表中將產(chǎn)生兩個(gè)序列號(hào)相同，且共線的正三角形。它們之間的距離代表排隊(duì)時(shí)延。</p><p>　　4.1 丟一個(gè)包情況下TCP實(shí)現(xiàn)的比較</p><p>　　在第一組仿真中，四種TCP實(shí)現(xiàn)都分別丟了14號(hào)數(shù)據(jù)包。從圖4-

101、2中可以看出，丟包后，Tahoe TCP的恢復(fù)需要從慢啟動(dòng)開始，而Reno、 NewReno和SACK由于加入了快速恢復(fù)算法，則可以更平滑地從擁塞狀態(tài)恢復(fù)。下面，將根據(jù)圖4-2詳細(xì)分析四種TCP實(shí)現(xiàn)在從擁塞狀態(tài)恢復(fù)的過程中窗口的變化。</p><p>　　在Tahoe TCP的仿真結(jié)果圖中可以看到， 0到13號(hào)數(shù)據(jù)包成功被接收端接收，擁塞控制窗口cwnd根據(jù)慢啟動(dòng)算法從1指數(shù)式增大到15。在第四輪的數(shù)據(jù)發(fā)送中，T

102、CP發(fā)送端的cwnd為8，前7個(gè)數(shù)據(jù)包都被成功接收，接收端返回7個(gè)ACK，cwnd大小由8增加到了15；但第8個(gè)數(shù)據(jù)包(14號(hào))丟失，接收端無法收到確認(rèn)，但是它仍占用發(fā)送窗口的一個(gè)數(shù)據(jù)包大小，因此TCP發(fā)送端發(fā)送15到28號(hào)共14個(gè)數(shù)據(jù)包。接收端收到這些數(shù)據(jù)包后，返回13號(hào)數(shù)據(jù)包的dup ACK。發(fā)送端收到連續(xù)的3個(gè)dup ACK，觸發(fā)快速重傳和慢啟動(dòng)，將cwnd設(shè)置為1，并立刻重傳14號(hào)數(shù)據(jù)包，且將慢啟動(dòng)門限ssthresh減小為快速

103、重傳前cwnd大小的一半。</p><p>　　圖4-2中Reno TCP與Tahoe TCP的不同在于：收到3個(gè)dup ACK后，發(fā)送端的cwnd減半，不進(jìn)入慢啟動(dòng)，而是直接進(jìn)入擁塞避免階段。發(fā)送端收到13號(hào)數(shù)據(jù)包的3個(gè)dup ACK后啟動(dòng)快速重傳和快速恢復(fù)算法，將ssthresh減小到7，cwnd的值被設(shè)置為ssthresh加3。在快速恢復(fù)階段，接收端共收到14個(gè)dup ACK， 使得cwnd增大到21，其中

104、有15個(gè)數(shù)據(jù)包(14到28號(hào))沒有被確認(rèn)，發(fā)送端可以再發(fā)送29-34號(hào)共6個(gè)數(shù)據(jù)包。當(dāng)接收端收到被重傳的14號(hào)數(shù)據(jù)包后返回對(duì)28號(hào)數(shù)據(jù)包的確認(rèn)，發(fā)送端收到這個(gè)ACK后退出快速恢復(fù)階段，將TCP的擁塞窗口設(shè)置為7。</p><p>　　丟一個(gè)包的情況下，NewReno和SACK的恢復(fù)過程與Reno TCP是一致的。</p><p>　　4.2 丟兩個(gè)包情況下TCP實(shí)現(xiàn)的比較</p>

105、;<p>　　如圖4-3所示，與前一組仿真相似，在丟失14號(hào)和28號(hào)兩個(gè)數(shù)據(jù)包后，Tahoe TCP的恢復(fù)從慢啟動(dòng)開始，而Reno、 NewReno和SACK可以較平滑地從擁塞狀態(tài)恢復(fù)。下面，根據(jù)圖4-3詳細(xì)分析四種TCP實(shí)現(xiàn)的區(qū)別。</p><p>　　與丟失一個(gè)數(shù)據(jù)包的情況類似，Tahoe TCP收到3個(gè)13號(hào)數(shù)據(jù)包的dup ACK后，將cwnd設(shè)為1，開始進(jìn)入慢啟動(dòng)并重傳數(shù)據(jù)包14。接收端收到

106、后返回對(duì)27號(hào)數(shù)據(jù)包的ACK，發(fā)送端收到ACK后發(fā)送數(shù)據(jù)包28，29。接收端收到28號(hào)數(shù)據(jù)包后，返回一個(gè)28號(hào)數(shù)據(jù)包的ACK。由于對(duì)數(shù)據(jù)包28的確認(rèn)是對(duì)新的數(shù)據(jù)的確認(rèn)，因此cwnd 增加1，接收端收到確認(rèn)后繼續(xù)發(fā)送數(shù)據(jù)。</p><p>　　在圖4-3中利用快速重傳，Reno發(fā)送端不必等待重傳超時(shí)，而是連續(xù)兩次進(jìn)入快速重傳和快速恢復(fù)階段，在連續(xù)兩個(gè)RTT時(shí)間內(nèi)兩次將cwnd減半，然后才得以恢復(fù)。這個(gè)過程極大降低了

107、TCP連接的傳輸效率。</p><p>　　Reno的操作過程和丟失一個(gè)包的情形類似，只是由于28號(hào)包的丟失，發(fā)送端收到13個(gè)而不是14個(gè)對(duì)13號(hào)數(shù)據(jù)包的重復(fù)確認(rèn)。在接收到最后一個(gè)dup ACK后，發(fā)送端的cwnd增加到20，允許發(fā)送29-33號(hào)數(shù)據(jù)包。</p><p>　　由于被重傳的14號(hào)數(shù)據(jù)包成功地被接收端接收，發(fā)送端收到了第一個(gè)對(duì)27號(hào)數(shù)據(jù)包的確認(rèn)，退出快速恢復(fù)階段，同時(shí)設(shè)置cwn

108、d為7（由于14號(hào)數(shù)據(jù)包的丟失，cwnd從15降到了7），此時(shí)發(fā)送端可以發(fā)送34號(hào)數(shù)據(jù)包。一旦收到對(duì)27號(hào)數(shù)據(jù)包第三個(gè)重復(fù)確認(rèn)，發(fā)送端再一次進(jìn)入快速恢復(fù)階段，緊接著重傳28號(hào)數(shù)據(jù)包，并將cwnd設(shè)置為6（由于已經(jīng)收到3個(gè)dup ACK），此時(shí)有7個(gè)數(shù)據(jù)包（28-34號(hào)）還沒有得到確認(rèn)，發(fā)送端已不能發(fā)送任何其他的數(shù)據(jù)包。在收到第5個(gè)和第6個(gè)dup ACK時(shí)，發(fā)送端cwnd從8增加到9，允許發(fā)送35、36號(hào)兩個(gè)數(shù)據(jù)包。</p>