tcp協(xié)議中的流量控制和擁塞控制研究畢業(yè)論文（含外文翻譯）

1、<p>　　畢業(yè)設(shè)計 (論文)</p><p>　　TCP協(xié)議中的流量控制和擁塞控制研究</p><p><b>　　年 月 日</b></p><p>　院 別數(shù)學(xué)與統(tǒng)計學(xué)院</p><p>　專業(yè)名稱信息與計算科學(xué)</p><p>　班級學(xué)號</p><

2、p>　學(xué)生姓名</p><p>　指導(dǎo)教師</p><p>　　TCP協(xié)議中的流量控制和擁塞控制研究</p><p><b>　　摘 要</b></p><p>　　計算機(jī)網(wǎng)絡(luò)技術(shù)是當(dāng)今發(fā)展最迅速的計算機(jī)技術(shù)之一，而保證網(wǎng)絡(luò)穩(wěn)定可靠運(yùn)行的關(guān)鍵是計算機(jī)網(wǎng)絡(luò)協(xié)議。TCP協(xié)議作為網(wǎng)絡(luò)協(xié)議中的核心協(xié)議之一，其重要性更

3、是不言而喻，因而對于該協(xié)議的研究與完善是促進(jìn)網(wǎng)絡(luò)發(fā)展的重要手段之一。</p><p>　　隨著互聯(lián)網(wǎng)規(guī)模和互聯(lián)網(wǎng)應(yīng)用的快速增長，網(wǎng)絡(luò)擁塞和數(shù)據(jù)沖突問題已引起人們密切的關(guān)注。擁塞控制與流量控制技術(shù)針對網(wǎng)絡(luò)中的擁塞和數(shù)據(jù)沖突而成為網(wǎng)絡(luò)領(lǐng)域的核心技術(shù)。其中流量控制的對象是接收端，目的是使發(fā)送端的發(fā)送速率不超過接收端的接收能力；擁塞控制的對象是網(wǎng)絡(luò)環(huán)境，目的是使負(fù)載不超過網(wǎng)絡(luò)的傳送能力。</p><p

4、>　　TCP的流量控制主要依賴于滑動窗口，通過流量約束，減少接收端出的數(shù)據(jù)流失，提高發(fā)送效率，充分利用接收端資源。</p><p>　　TCP的擁塞控制主要原理依賴于一個擁塞窗口(cwnd)來控制，窗口值的大小就代表能夠發(fā)送出去的但還沒有收到ACK的最大數(shù)據(jù)報文段，顯然窗口越大那么數(shù)據(jù)發(fā)送的速度也就越快，但是也就越可能使得網(wǎng)絡(luò)出現(xiàn)擁塞，如果窗口值為1，那么就簡化為一個停等協(xié)議，每發(fā)送一個數(shù)據(jù)，都要等到對方的

5、確認(rèn)才能發(fā)送第二個數(shù)據(jù)包，顯然數(shù)據(jù)傳輸效率低下。TCP擁塞控制算法就是要在這兩者之間權(quán)衡，選取最的cwnd值，從而使得網(wǎng)絡(luò)吞吐量最大化且不產(chǎn)生擁塞。</p><p>　　本文首先對TCP協(xié)議的發(fā)展做了簡要的概述，然后分析了TCP協(xié)議的報文段格式和結(jié)構(gòu)，TCP的數(shù)據(jù)傳輸過程，接著討論了TCP的流量控制機(jī)制，最后針對TCP的重點部分擁塞控制進(jìn)行了分析，討論了幾個TCP擁塞控制算法。</p><p&

6、gt;　　關(guān)鍵詞：TCP協(xié)議，流量控制，擁塞控制</p><p>　　The Flow Contral and Congestion Control in TCP Protocol</p><p>　　Author: Etvgbd </p><p>　　Tutor: Rtvghhh</p><p><b>　　Abstract<

7、;/b></p><p>　　Computer network technology is one of the most rapidly developing of computer technology today,and the computer network protocols is the key to ensure the network is stable and reliable oper

8、ation. TCP protocol, as one of the core protocols of the network protocol,is vary important, so to research and improve the protocol is one of the important means to promote the development of the network. </p>&l

9、t;p>　　With the rapid growth of Internet scale and the Internet application, network congestion and data conflict problem has aroused the concern of the people closely. Congestion control and flow control technology, a

10、ccording to the theory of network congestion and data conflict has become the core technology in the field of network. The flow control object is the receiver, the purpose is to make the sending rate does not exceed the

11、capacity at the receiving end. Congestion control object is the netwo</p><p>　　TCP flow control is mainly depended on the sliding window, by flow constraints, and reduce the loss of data at the receiving end

12、, to improve the transmission efficiency, make full use of the receiver.</p><p>　　The main principle of TCP congestion control relies on a congestion window (cwnd) to control the window size value represents

13、 the ability to send out but not yet received the maximum data packet ACK Duan, clear window, so the greater the speed of data sent the faster, but also more likely to make the network congestion occurs, if the window is

14、 1, then reduced to a stop such agreement, each sending a data, must wait for confirmation of the other party can send a second packet, the data clearly tr</p><p>　　Firstly, the development of the TCP protoc

15、ol a brief overview, and then analyzed the structure of TCP protocol, TCP data transfer process, followed by a discussion of the TCP flow control mechanism, the key part of the final for the TCP congestion control are an

16、alyzed, discussed Several TCP congestion control algorithm.</p><p>　　Key Words :TCP protocol, Flow control,Congestion control</p><p><b>　　目 錄</b></p><p><b>　　1

17、 緒論1</b></p><p>　　1.1 TCP的發(fā)展過程與設(shè)計目標(biāo)1</p><p>　　1.1.1 TCP的發(fā)展過程1</p><p>　　1.1.2 TCP的設(shè)計目標(biāo)1</p><p>　　1.2 論文結(jié)構(gòu)2</p><p>　　2 TCP協(xié)議3</p><

18、;p>　　2.1 TCP的報文段4</p><p>　　2.1.1 TCP的報文格式4</p><p>　　2.1.2 TCP報文封裝5</p><p>　　2.2 TCP的數(shù)據(jù)傳輸6</p><p>　　2.2.1 TCP連接的建立6</p><p>　　2.2.2 TCP連接的釋放7&

19、lt;/p><p>　　3 TCP協(xié)議中的流量控制8</p><p>　　3.1 滑動窗口8</p><p>　　3.2 可變窗口流量控制實例分析8</p><p>　　4 TCP的擁塞控制10</p><p>　　4.1 擁塞產(chǎn)生的原因10</p><p>　　4.2 重發(fā)定

20、時器管理11</p><p>　　4.2.1 RTT的估算12</p><p>　　4.2.2 RTO的計算12</p><p>　　4.3 TCP 擁塞控制所采用的機(jī)制13</p><p>　　5 TCP擁塞控制算法17</p><p>　　5.1 TCP 的早期實現(xiàn)17</p>

21、<p>　　5.2 TCP Tahoe17</p><p>　　5.3 TCP Reno算法17</p><p>　　5.4 TCP New-Reno18</p><p>　　5.5 TCP SACK19</p><p>　　5.6 TCP Vegas20</p><p><b>

22、;　　結(jié) 論22</b></p><p><b>　　致 謝23</b></p><p><b>　　參考文獻(xiàn)24</b></p><p><b>　　附 錄25</b></p><p><b>　　1 緒論</b>

23、</p><p>　　計算機(jī)網(wǎng)絡(luò)是計算機(jī)和通信密切結(jié)合的產(chǎn)物，近些年來得到了迅速的發(fā)展，已逐漸成為信息社會的基石。網(wǎng)絡(luò)協(xié)議是計算機(jī)中不可缺少的的一個重要組成部分，它是計算機(jī)和計算機(jī)之間以及計算機(jī)和其他設(shè)備之間進(jìn)行數(shù)據(jù)通信的必要條件。TCP協(xié)議作為重要的網(wǎng)絡(luò)協(xié)議也是有了很大的發(fā)展。</p><p>　　1.1 TCP的發(fā)展過程與設(shè)計目標(biāo)</p><p>　　認(rèn)識來源

24、于實踐，而認(rèn)識的最終目標(biāo)也正是服務(wù)于實踐。只有了解TCP的發(fā)展歷史以及相應(yīng)的設(shè)計目標(biāo)，我們才能對TCP擁有較為全面的認(rèn)識，從而更好地研究TCP技術(shù)，滿足越來越高的應(yīng)用需求。</p><p>　　1.1.1 TCP的發(fā)展過程</p><p>　　互聯(lián)網(wǎng)最初源于美國國防部的ARPANET計劃。上世紀(jì)60年代中期正是冷戰(zhàn)的高峰，美國國防部希望有一個命令和控制網(wǎng)絡(luò)，以確保在核戰(zhàn)爭的條件下幸免于難

25、，而傳統(tǒng)基于電路交換的電話網(wǎng)絡(luò)則過于脆弱。國防部指定其下屬的高級研究計劃局解決這個問題，從而誕生ARPANET，其最大特點是采用無連接的端到端報文交換服務(wù)。到了80年代中期，演變?yōu)榛ヂ?lián)網(wǎng)。TCP協(xié)議最初只是作為NSFNET的程序規(guī)范，即RFC 793，這也是最早的較為完整且齊全的TCP規(guī)范。這個規(guī)范簡單描述了如何進(jìn)行主機(jī)到主機(jī)的可靠傳輸，并描述了傳輸控制協(xié)議執(zhí)行的功能，相應(yīng)的實現(xiàn)程序及程序接口。TCP協(xié)議在設(shè)計之初就被賦予了很高的使命，

26、需要成為報文交換計算機(jī)網(wǎng)絡(luò)和這些網(wǎng)絡(luò)互聯(lián)系統(tǒng)中的高可靠性傳輸協(xié)議。需要明確的是，網(wǎng)絡(luò)中的可靠傳輸包括兩方面：首先是數(shù)據(jù)的正確，由于以前的傳輸介質(zhì)質(zhì)量很差，所以在傳輸層及以下各層協(xié)議中都實現(xiàn)了校驗和計算；其次是數(shù)據(jù)的完整保序，這個特性需要TCP執(zhí)行復(fù)雜的操作來實現(xiàn)，通常我們強(qiáng)調(diào)TCP的可靠傳輸時主要指后者。</p><p>　　1.1.2 TCP的設(shè)計目標(biāo)</p><p>　　在TCP設(shè)計

27、之初，網(wǎng)絡(luò)技術(shù)剛剛起步，相應(yīng)的硬件設(shè)施只能達(dá)到很低的水平，應(yīng)用需求也十分簡單，諸多因素導(dǎo)致TCP協(xié)議的設(shè)計目標(biāo)從開始就已經(jīng)先天不足。在設(shè)計TCP協(xié)議時，由于人們對網(wǎng)絡(luò)，尤其是對大型互聯(lián)網(wǎng)絡(luò)缺乏本質(zhì)的認(rèn)識，從而遺漏了許多TCP協(xié)議應(yīng)該具備的重要特征。例如，我們現(xiàn)在熟知的擁塞控制，在最初協(xié)議設(shè)計中就沒能得到體現(xiàn)。 TCP最初的設(shè)計目標(biāo)只是在進(jìn)程間提供可靠、安全的邏輯鏈路，并在此基礎(chǔ)之上提供可靠的傳輸服務(wù)。需要強(qiáng)調(diào)的是，TCP對網(wǎng)絡(luò)并不做任何

28、假設(shè)，它的主要功能就是提供可靠的邏輯鏈路。為了能夠在不可靠的網(wǎng)絡(luò)上進(jìn)行可靠的通信，協(xié)議必須提供如下功能：能夠進(jìn)行基本的數(shù)據(jù)傳輸、保證數(shù)據(jù)的可靠性、進(jìn)行適當(dāng)?shù)牧髁靠刂?、維護(hù)通信狀態(tài)的集合、使用并行多路技術(shù)以及保證通信的優(yōu)先級 和安全性。</p><p><b>　　1.2 論文結(jié)構(gòu)</b></p><p>　　本文主要圍繞下列問題展開研究：</p>&l

29、t;p>　　1．TCP的結(jié)構(gòu)和數(shù)據(jù)傳輸過程</p><p>　　2．TCP的流量控制機(jī)制</p><p>　　3．TCP的擁塞控制與擁塞控制算法</p><p><b>　　2 TCP協(xié)議</b></p><p>　　TCP 協(xié)議是目前互聯(lián)網(wǎng)上應(yīng)用最廣泛的傳輸層協(xié)議。它主要提供端到端可靠的字節(jié)流傳送服務(wù)。<

30、/p><p>　　TCP 是一個面向連接的協(xié)議，即在端系統(tǒng)進(jìn)行數(shù)據(jù)傳輸之前要建立連接，連接屬于全雙工方式(即數(shù)據(jù)可以在兩個方向上同時進(jìn)行傳輸)。TCP 在不可靠的IP 網(wǎng)絡(luò)層上提供可靠的數(shù)據(jù)傳輸服務(wù)，即所有被傳輸?shù)臄?shù)據(jù)最終都應(yīng)到達(dá)接收端。在TCP 中，接收端對其所接收的每一個分組都進(jìn)行確認(rèn)，在一定時間范圍內(nèi)沒有得到確認(rèn)的分組會被發(fā)送方重新進(jìn)行發(fā)送。接收端如果收到一個重復(fù)的分組，將會丟棄該分組，如果收到亂序的分組，則對

31、這個分組進(jìn)行重新排序。每個分組都會有自己對應(yīng)的序列號，發(fā)送方可以通過分組確認(rèn)報文獲得接收端所希望接收的下一個分組的序列號。當(dāng)通信雙方均有數(shù)據(jù)要發(fā)送時，TCP 可以將確認(rèn)信息放在數(shù)據(jù)分組中發(fā)送以減少控制信息帶來的額外流量。TCP協(xié)議對數(shù)據(jù)單元的傳輸及重傳策略，對于網(wǎng)絡(luò)的擁塞狀況有著深刻的影響。</p><p>　　概括來說，TCP 協(xié)議為應(yīng)用層提供了以下服務(wù)：</p><p>　　1．流交付

32、服務(wù):TCP 協(xié)議允許發(fā)送進(jìn)程以字節(jié)流的形式來傳遞數(shù)據(jù)，而接收進(jìn)程也把數(shù)據(jù)作為字節(jié)流來接收。這樣，TCP 協(xié)議使得兩個進(jìn)程好像在一個假想的“管道”中傳送兩個進(jìn)程的數(shù)據(jù)。</p><p>　　2．全雙工服務(wù):即數(shù)據(jù)可在同一時間雙向流動。每一個TCP 端系統(tǒng)都有發(fā)送緩存和接收緩存，而兩個方向都可以發(fā)送報文段。</p><p>　　3．面向連接服務(wù):TCP 通過一條虛擬連接來傳送數(shù)據(jù)。當(dāng)TCP

33、報文被封裝成IP 分組后，每一個分組可以走不同的路徑來到達(dá)目的端，因此收到的IP 分組可能會亂序，可能會丟失，或者受到損傷，并可能經(jīng)過重傳。但是TCP 創(chuàng)建了面向流的環(huán)境，它負(fù)責(zé)按順序?qū)⑼暾臄?shù)據(jù)交付給應(yīng)用程序。</p><p>　　4．流量控制:流量控制定義了發(fā)送端在收到從接收端發(fā)來的確認(rèn)之前可以發(fā)送的數(shù)據(jù)量。TCP 協(xié)議在緩存上定義了一個窗口，緩存是用來暫時存放從應(yīng)用程序傳遞來并準(zhǔn)備發(fā)送的數(shù)據(jù)，TCP 發(fā)送端

34、就根據(jù)這個窗口的大小來發(fā)送數(shù)據(jù)。這就是所謂的滑動窗口機(jī)制。</p><p>　　5．差錯控制:TCP 是可靠的傳輸層協(xié)議，這就表示，當(dāng)應(yīng)用程序把數(shù)據(jù)流交付給IP 層后，TCP協(xié)議應(yīng)當(dāng)把數(shù)據(jù)流按順序，沒有差錯，沒有損傷地交付給另一個應(yīng)用程序。為了實現(xiàn)差錯控制，TCP 協(xié)議采用了以下幾種機(jī)制：檢測受到損傷的、丟失的、失序的和重復(fù)的數(shù)據(jù)包；在檢測到差錯后，能夠糾正差錯。</p><p>　　6．

35、擁塞控制:互聯(lián)網(wǎng)由許多網(wǎng)絡(luò)和連接設(shè)備組成。發(fā)送端發(fā)送的分組要經(jīng)過多個路由器后才能到達(dá)最后的接收端。路由器為了保證鏈路的利用率，一般都會提供緩存來暫時存儲突發(fā)到達(dá)的分組，但是當(dāng)路由器接收過多的分組時，就可能導(dǎo)致路由器緩沖區(qū)溢出，即該路由器節(jié)點發(fā)生擁塞，部分分組就會被丟棄。當(dāng)發(fā)送端重傳這些分組時，會造成更加嚴(yán)重的擁塞，以致于使網(wǎng)絡(luò)癱瘓。因此我們必須在端系統(tǒng)采用一些擁塞控制機(jī)制來保證網(wǎng)絡(luò)不會發(fā)生擁塞，同時又能充分利用網(wǎng)絡(luò)的鏈路資源。TCP協(xié)議

36、采用了慢啟動，擁塞避免等算法來對網(wǎng)絡(luò)擁塞進(jìn)行控制，從而在一定程度上保證網(wǎng)絡(luò)的穩(wěn)定運(yùn)行。</p><p>　　2.1 TCP的報文段</p><p>　　2.1.1 TCP的報文格式</p><p>　　TCP 軟件在兩臺計算機(jī)之間傳輸?shù)臄?shù)據(jù)單元稱為報文段(segment)。通過報文段的交互來建立連接、傳輸數(shù)據(jù)、發(fā)出確認(rèn)、通告窗口大小及關(guān)閉連接。圖2.1表示出了T

37、CP 報文段的格式，每個報文段分為兩個部分：首部和數(shù)據(jù)。報文段既可以用來建立連接，也可以運(yùn)載數(shù)據(jù)和應(yīng)答。</p><p>　　圖2.1 TCP報文段格式</p><p>　　TCP報文段首部固定部分各字段的意義如下：</p><p>　　源端口和目的端口：各占2個字節(jié)，是傳輸層與高層的接口。</p><p>　　序列號：占4字節(jié)，是本報文段

38、所發(fā)送的數(shù)據(jù)部分第一個字節(jié)的序號。在TCP輸送的數(shù)據(jù)流中，每一個字節(jié)都有一個順序號。例如，在一個報文段中，序號為300，而報文中的數(shù)據(jù)為100字節(jié)，那么，在下一個報文段中，其順序號就是400。由此可見，TCP是面向數(shù)據(jù)流的。</p><p>　　確認(rèn)序列號：占4字節(jié)，是期望收到對方下次發(fā)送數(shù)據(jù)的第一個字節(jié)的序號。</p><p>　　首部長度：占4bit，它指出以32bit 為單位的TCP

39、 報文段首部的長度。在首部字段后面是6bit的保留字段，是為將來的應(yīng)用而保留的，目前置為0。</p><p>　　緊急比特URG：當(dāng)URG = 1時，表明此報文段應(yīng)該盡快發(fā)送，而不要按照原來的排隊順序發(fā)送。它通常與緊急指針(位于第5個32bit 字段中的后一半)配合使用，緊急指針指出在本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號。緊急指針使接收方可以知道緊急數(shù)據(jù)共有多長。需要注意的是，即使窗口大小為0時也可發(fā)送緊急數(shù)

40、據(jù)。</p><p>　　確認(rèn)比特ACK：只有當(dāng)ACK = 1時確認(rèn)序號字段才有意義。當(dāng)ACK = 0時，確認(rèn)序號無意義。</p><p>　　急迫比特PSH：當(dāng)PSH = 1時，表明請求遠(yuǎn)地TCP將本報文段立即傳送給其應(yīng)用層，而不要等整個緩沖區(qū)都填滿之后再向上交付。</p><p>　　復(fù)位比特RST：當(dāng)RST = 1時，表明出現(xiàn)嚴(yán)重差錯，必須釋放連接，然后再重新

41、建立連接。</p><p>　　同步比特SYN：在連接建立時使用。當(dāng)SYN = 1而ACK = 0時，表明這是一個連接請求報文段。對方若同意建立連接，則應(yīng)在發(fā)回的報文段中使SYN = 1和ACK = 1。因此SYN置為1，就表示這是一個連接請求或連接接受報文，而ACK 比特的值用來區(qū)分是哪一種報文。</p><p>　　終止比特FIN：用來釋放一個連接。當(dāng)FIN = 1時，表明欲發(fā)送的字節(jié)

42、串已經(jīng)發(fā)完，并請求釋放傳輸層連接。</p><p>　　窗口：占2字節(jié)。窗口字段提供端到端的流量控制，它表示在確認(rèn)了字節(jié)之后還可以發(fā)送多少個字節(jié)。此字段值為0是合法的，表示它已經(jīng)收到了包括確認(rèn)號減1(即己發(fā)送的所有報文段)在內(nèi)的所有報文段，但當(dāng)前接收方急需暫停。之后通過發(fā)送一個帶有相同確認(rèn)號和滑動窗口字段非零值的報文段來恢復(fù)原來的傳輸。</p><p>　　校驗和：占2字節(jié)。校驗和字段覆蓋

43、的范圍包括首部、數(shù)據(jù)和概念上的偽TCP首部之和。</p><p>　　選項和填充：占2字節(jié)。為可選部分，用于TCP具體選項。填充的作用是確保首部大小是一個32位的整倍數(shù)。</p><p>　　2.1.2 TCP報文封裝</p><p>　　如圖2.2所示，TCP報文段封裝在IP數(shù)據(jù)報中，然后再封裝成數(shù)據(jù)鏈路層中的幀，并通過物理層傳輸?shù)綌?shù)據(jù)的接收端，在接受端數(shù)據(jù)鏈路

44、層剝?nèi)氖撞?，然后送到接收端的網(wǎng)絡(luò)層，剝?nèi)P首部再發(fā)送到傳輸層，所剩下的就是發(fā)送段的TCP報文段。</p><p>　　圖2.2 報文段的封裝</p><p>　　2.2 TCP的數(shù)據(jù)傳輸</p><p>　　2.2.1 TCP連接的建立</p><p>　　TCP以全雙工的方式傳輸數(shù)據(jù)。當(dāng)兩個機(jī)器重的兩個TCP建立連接候，他們都能夠

45、同時向?qū)Ψ桨l(fā)送報文段。這就表示，在任何數(shù)據(jù)傳輸之前，每一方都必須對通信進(jìn)行初始化，并得到對方的認(rèn)可，即TCP的連接。TCP的連接建立稱為“三次握手"。1.客戶發(fā)送第一個報文段，SYN報文段，在這個報文段中只有SYN標(biāo)志置1。這個報文段的作用是使序號同步。客戶端選擇一個隨機(jī)數(shù)SEQ作為第一序號，并把這個序號發(fā)給服務(wù)器。2.服務(wù)器發(fā)送第二個報文段，即SYN+ACK報文段，其中有兩個標(biāo)志置為l。這個報文段有兩個目的，一個是使用SYN

46、同步初始序號，另一個是服務(wù)器使用ACK標(biāo)志確認(rèn)已經(jīng)從客戶端收到的SYN報文段，同時給出期望從客戶端收到的下一個序號。3.客戶端發(fā)送第三個報文段。這僅僅是一個ACK報文段。它使用ACK標(biāo)志和確認(rèn)號字段來確認(rèn)收到了第二個報文。</p><p><b>　　實例分析： </b></p><p>　　圖2.3 TCP連接的建立</p><p>　　下面

47、我們以主機(jī)A和主機(jī)B兩個應(yīng)用程序為例來分析。如圖2.3所示。這個過程從服務(wù)器開始。主機(jī)A告訴它的TCP，它已經(jīng)準(zhǔn)備好接受連接，這叫做被動打開。主機(jī)B發(fā)送請求叫做主動打開。A的TCP向B的TCP發(fā)出連接請求報文段，其首部中的同比特SYN應(yīng)置1，同時選擇一個序號X，我們選取X = 800，表明在后面?zhèn)鬏敂?shù)據(jù)的第一個數(shù)據(jù)字節(jié)的序號是X+1，即為801。B的TCP收到連接請求報文段后，如同意則發(fā)回確認(rèn)。在確認(rèn)報文段中將SYN和ACK都置1，確認(rèn)

48、號為X+1，即為801，同時為自己選擇一個序號Y，令Y = 1500。A的TCP收到B的確認(rèn)后，要向B給出確認(rèn)，其ACK置1，確認(rèn)號為Y+1，即為1501，自己的序號為X+1，為801。</p><p>　　2.2.2 TCP連接的釋放</p><p>　　參加交換數(shù)據(jù)的雙方的任何一方都可以關(guān)閉連接。當(dāng)一方向的連接被終止時，另一方還可以繼續(xù)向?qū)Ψ桨l(fā)送數(shù)據(jù)。建立一個連接需要三次握手，終止連

49、接要經(jīng)過四次握手。</p><p>　　圖2.4 TCP連接的釋放</p><p><b>　　實例分析：</b></p><p>　　如圖2.4所示，主機(jī)A的應(yīng)用進(jìn)程先向其TCP發(fā)送連接釋放請求，并且不再發(fā)送數(shù)據(jù)。TCP通知對方要釋放從A到B這個方向的連接，將發(fā)往主機(jī)B的TCP報文段首部的FIN置1，其序號X等于前面已傳送過的數(shù)據(jù)的最后一個字

50、節(jié)的序號加1，為X = 1001。主機(jī)B的TCP收到釋放鏈接通知后發(fā)出確認(rèn)，其序號為Y = 1700，確認(rèn)號為X+1，即1002，同時通知高層應(yīng)用進(jìn)程，應(yīng)用進(jìn)程通知TCP釋放連接。B發(fā)出的連接釋放報文段必需將FIN和ACK置1，并使其序號仍為Y，重復(fù)上次發(fā)送的ACK = X+1。A對此確認(rèn)，將ACK置1，ACK=Y+1 = 1701，自己的序號是X+1為1002。</p><p>　　3 TCP協(xié)議中的流量控制

51、</p><p>　　如果發(fā)送端發(fā)送的數(shù)據(jù)過多或者數(shù)據(jù)發(fā)送速率過快，致使接收端來不及處理，則會造成數(shù)據(jù)在接收端的丟棄。為了避免這種現(xiàn)象的發(fā)生，通常的處理辦法是采用流量控制，即控制發(fā)送端發(fā)送的數(shù)據(jù)量及數(shù)據(jù)發(fā)送速率。時期不超過接收端的承受能力，這個能力主要指接收端的緩存和數(shù)據(jù)處理速度。</p><p>　　流量控制是與點到點的通信量有關(guān)的，是針對端系統(tǒng)中資源受限而設(shè)置的。主要解決快速發(fā)送方與慢

52、速接收方的問題。流量控制的目的是在有限的接收端承受能力的情況下，通過流量約束，減少接收端出的數(shù)據(jù)丟失，提高數(shù)據(jù)發(fā)送效率，充分利用接收端資源。</p><p><b>　　3.1 滑動窗口</b></p><p>　　TCP的特點之一是提供體積可變的滑動窗口機(jī)制，支持端到端的流量控制。TCP的窗口以字節(jié)為單位進(jìn)行調(diào)整，以適應(yīng)接收方的處理能力。處理過程如下：首先，在TC

53、P連接階段，雙方協(xié)商窗口尺寸，同時接收方預(yù)留數(shù)據(jù)緩沖區(qū)；其次，發(fā)送方根據(jù)協(xié)商的結(jié)果，發(fā)送符合窗口尺寸的數(shù)據(jù)字節(jié)流，并等待對方的確認(rèn)；最后，發(fā)送方根據(jù)確認(rèn)信息，改變窗口的尺寸。</p><p><b>　　圖3.1 滑動窗口</b></p><p>　　圖3.1表示發(fā)送窗口為400字節(jié)，發(fā)送端已發(fā)送300字節(jié)的數(shù)據(jù)，但是只收到對前100字節(jié)的確認(rèn)，同時窗口的大小不變，現(xiàn)

54、在發(fā)送端還可以發(fā)送200字節(jié)。</p><p>　　3.2 可變窗口流量控制實例分析</p><p>　　設(shè)主機(jī)A向主機(jī)B發(fā)送數(shù)據(jù)，如圖3.2所示，雙方規(guī)定窗口值是400。再設(shè)每一個報文段是100字節(jié)長，序號的初始值為1。主機(jī)B進(jìn)行3次流量控制，第一次將窗口減少為300字節(jié)，第二次減為200字節(jié)，最后一次減為08字節(jié)，即不允許發(fā)送數(shù)據(jù)。</p><p>　　圖3.

55、2 可變窗口流量控制</p><p>　　4 TCP的擁塞控制</p><p>　　擁塞是一種持續(xù)過載的網(wǎng)絡(luò)狀態(tài)，此時用戶對網(wǎng)絡(luò)資源（緩存空間、鏈路帶寬容量和中間節(jié)點的處理能力等）的需求超過了其固有的容量。網(wǎng)絡(luò)的性能(功率、往返時間RTT、吞吐量)與負(fù)荷的關(guān)系可以用圖4.1來說明?？梢钥闯霎?dāng)負(fù)荷較小時，網(wǎng)絡(luò)吞吐量和資源功率（資源功率＝吞吐量/響應(yīng)時間）隨負(fù)荷的增長的以指數(shù)增長，RTT隨負(fù)

56、荷的增長略有上升，當(dāng)負(fù)荷到達(dá)膝點時，功率到達(dá)最大值，在此之后吞吐量的增長遠(yuǎn)遠(yuǎn)慢于負(fù)荷的增長，RTT迅速上升，功率快速下降，若繼續(xù)增長負(fù)荷，則存在丟包的可能。負(fù)荷到達(dá)崖點時，吞吐量達(dá)到最大值，功率到達(dá)最小值。RTT以指數(shù)增長，系統(tǒng)處于擁塞狀態(tài)。膝點指資源功率到達(dá)最大值的負(fù)荷量。崖點指資源功率下降到最小值且開始丟包時的負(fù)荷量。因此膝點是最為理想的工作點，擁塞控制就是采用某種策略或機(jī)制，保持網(wǎng)絡(luò)工作在正常的狀態(tài)下，也就是使網(wǎng)絡(luò)經(jīng)常工作在崖點左

57、側(cè)的區(qū)域內(nèi)。若一種控制機(jī)制使得網(wǎng)絡(luò)工作在膝點附近，該方法稱為擁塞避免；若一種控制機(jī)制使網(wǎng)絡(luò)工作在崖點或崖點以后的網(wǎng)絡(luò)回復(fù)至膝點前后，該方法稱為擁塞恢復(fù)。</p><p>　　圖4.1 網(wǎng)絡(luò)性能與負(fù)荷之間的關(guān)系</p><p>　　4.1 擁塞產(chǎn)生的原因</p><p>　　隨著通信和計算機(jī)技術(shù)的成熟和發(fā)展，互聯(lián)網(wǎng)規(guī)模的增長，網(wǎng)絡(luò)用戶和網(wǎng)絡(luò)應(yīng)用都在快速地增長，人們對

58、包括話音、文字、數(shù)據(jù)、圖像等多種媒體通信的需求不斷增大。在計算機(jī)網(wǎng)絡(luò)中有許多網(wǎng)絡(luò)資源，如鏈路的容量、交換節(jié)點中的緩沖區(qū)和處理機(jī)等，如果在某段時間，用戶(端系統(tǒng))加于網(wǎng)絡(luò)的負(fù)載大于網(wǎng)絡(luò)資源容量和處理能力，就會產(chǎn)生擁塞，網(wǎng)絡(luò)的性能就要變壞。若網(wǎng)絡(luò)中的許多資源同時產(chǎn)生擁塞，網(wǎng)絡(luò)的性能就要明顯變差，整個網(wǎng)絡(luò)的吞吐量將隨輸入負(fù)載的增大而下降，表現(xiàn)為數(shù)據(jù)包時延增加、丟棄概率增大、上層應(yīng)用系統(tǒng)性能下降等。</p><p>　　

59、總的來說，資源緊缺和資源的不合理利用時產(chǎn)生擁塞控制的直接原因，具體表現(xiàn)在：</p><p>　　1．存儲空間不足：幾個輸入數(shù)據(jù)流共同需要同一個輸出端口，在這個端口就會建立排隊。如果沒有足夠的存儲空間存儲，數(shù)據(jù)包就會被丟棄。對突發(fā)數(shù)據(jù)流更是如此。增加存儲空間在某種程度上可以緩解這一矛盾，但如果路由器有無限存儲量時，擁塞只會交得更壞，而不是更好，因為在網(wǎng)絡(luò)里數(shù)據(jù)包經(jīng)過長時間排隊完成轉(zhuǎn)發(fā)時，它們早己超時，源端認(rèn)為它們已

60、經(jīng)被丟棄，而這些數(shù)據(jù)包還會繼續(xù)向下一個路由器轉(zhuǎn)發(fā)，從而浪費網(wǎng)絡(luò)資源，加重網(wǎng)絡(luò)擁塞。</p><p>　　2．帶寬容量不足：低速鏈路對高速數(shù)據(jù)流的輸入也會產(chǎn)生擁塞。根據(jù)香農(nóng)信息理論，任何信道帶寬最大值即信道容量 (N為信道白噪聲的平均功率，S為信源的平均功率，B為信道帶寬)。所有信源發(fā)送的速率R必須小于或等于信道容量C。如果R>C，則在理論上無差錯傳輸就是不可能的，所以在網(wǎng)絡(luò)低速鏈路處就會形成帶寬瓶頸，當(dāng)其滿

61、足不了通過它的所有源端帶寬要求時，網(wǎng)絡(luò)就會發(fā)生擁塞。</p><p>　　3．處理器處理能力弱、速度慢也能引起擁塞：避免擁塞的發(fā)生，對以上原因需綜臺考慮。擁塞雖然是由于網(wǎng)絡(luò)資源的稀缺引起的，但單純增加資源并不能避免擁塞的發(fā)生。定程度時，只會加重?fù)砣?，而不是減輕擁塞，是因為當(dāng)報文段經(jīng)過長時間排隊完成轉(zhuǎn)發(fā)時，它們很可能早己超時。從而引起源端超時重發(fā)，而這些報文段還會繼續(xù)傳輸?shù)较乱宦酚善?，從而浪費網(wǎng)絡(luò)資源，加重網(wǎng)絡(luò)擁塞

62、。事實上，緩存空間不足導(dǎo)致的丟包更多的是擁塞的“癥狀”而非原因。另外，增加鏈路帶寬及提高處理能力也不能解決擁塞問題。</p><p>　　單純地增加網(wǎng)絡(luò)資源之所以不能解決擁塞問題，是因為擁塞本身是一個動態(tài)問題，它不可能只靠靜態(tài)的方案來解決，而需要網(wǎng)絡(luò)協(xié)議在網(wǎng)絡(luò)出現(xiàn)擁塞時保護(hù)網(wǎng)絡(luò)的正常運(yùn)行，即需要對網(wǎng)絡(luò)的可能擁塞進(jìn)行控制。</p><p>　　擁塞一旦發(fā)生往往會形成一個不斷加重的過程，如不加

63、控制，就會影響網(wǎng)絡(luò)的性能，嚴(yán)重的情況甚至?xí)拐麄€網(wǎng)絡(luò)發(fā)生癱瘓。所以，擁塞控制是網(wǎng)絡(luò)中必不可少的機(jī)制。</p><p>　　4.2 重發(fā)定時器管理</p><p>　　重發(fā)定時器管理是TCP擁塞控制中的一個關(guān)鍵技術(shù)。</p><p>　　TCP每發(fā)送一個報文段，就設(shè)置一次計數(shù)器。只要計時器設(shè)置重傳時間到而還沒有收到確認(rèn)，就要重傳這一報文段。重傳時間間隔的取值(RTO

64、)直接影響到發(fā)送端對網(wǎng)絡(luò)的反應(yīng)情況。取值太小，會造成不必要的重傳，從而浪費網(wǎng)絡(luò)資源：取值太大，對報文段丟失的反應(yīng)就會很遲緩。RTO的值與RTT(Round Trip Time)有很大的關(guān)系。所以，正確估算RTT的值并合理地選擇RTO的值對TCP的性能有重要影響。</p><p>　　4.2.1 RTT的估算</p><p>　　整個端到端路徑的往返時間RTT(Round Trip Tim

65、e)指從源端發(fā)出一個報文段到收到相應(yīng)的確認(rèn)之間的時間間隔。RTT 包括正向和反向路徑中各跳的鏈路時延(傳輸時延和物理傳播時延)和中間結(jié)點的處理時延(排隊、路由查找、轉(zhuǎn)發(fā))。RTT 隨著各個中間結(jié)點的排隊情況不同，表現(xiàn)出一定的隨機(jī)性。如果中間結(jié)點使用較長的隊列，RTT 的變化會很大。一種計算RTT 的方法就是對觀察到的一些報文段的往返時間簡單地取平均，但是，通常我們希望對更近期的采樣值給予更大的權(quán)值，因為它們更可能反映將來的行為，因此，常

66、用的_種技術(shù)為指數(shù)平均法。其平滑RTT 的值的計算如下：</p><p>　　其中SRTT(K)是前K個報文段的平滑往返時間估值：α是指數(shù)平均的權(quán)值(0<α<1)，α 越小，給予更迸的觀察值的權(quán)值就越大，通常α的取值為7/8，此時，將幾乎所有的權(quán)重都給了最近10個左右的觀察值。</p><p>　　4.2.2 RTO的計算</p><p>　　對RTO

67、的計算主要有三種方法；RTT方差估計(Jacobson算法)、指數(shù)RTO退避和Karn算法。</p><p>　　1．RTT方差估計： 最初的TCP規(guī)約試圖通過對RTT估值乘以一個常數(shù)因子B(通常取B=2)的方法確定RTO的值，但在穩(wěn)定環(huán)境中RTT的方差很低，用上述方法得到的RTO就不必要的取得太高；而在不穩(wěn)定的環(huán)境中，p取值為2可能并不足以防止不必要的重傳。RTT方差估計是通過平滑RTT方差的倍數(shù)與平滑往返時間

68、之和來確定定時器的取值，它可以更有效的計算RTO的值。完整的算法表達(dá)如下：</p><p><b>　　采樣平滑偏差：</b></p><p><b>　　平滑偏差：</b></p><p><b>　　重發(fā)定時器：</b></p><p>　　一般情況h的取值為1/4，?的取

69、值為4。</p><p>　　經(jīng)驗證明，此算法可以顯著提高TCP的性能。</p><p>　　2．指數(shù)RTO 退避：如果TCP的發(fā)送端在一個報文段上發(fā)生超時，它就必須重傳這個報文段?？紤]到超時可能是由于網(wǎng)絡(luò)擁塞引起的，為了給網(wǎng)絡(luò)足夠的時間從擁塞中恢復(fù)，一個更明智的策略是TCP源端在同一報文段重傳時增加其RTO，這被稱為退避過程(backoff process)。實現(xiàn)RTO退避的一種簡單的方

70、法是對一個報文段的每次重傳都將RTO乘以一個常數(shù)值，即: 。這就使得RTO隨每次重傳而指數(shù)增長。q通常取2，此時稱之為二進(jìn)制指數(shù)退避(binary exponential backoff)。</p><p>　　3．Karn 算法：假定一個報文段發(fā)生超時而必須重傳，如果隨后收到了—個確認(rèn)，那么就有兩種可能：</p><p>　　1）報文段第一次傳輸?shù)腁CK。這種情況下，RTT 僅比期望的更

71、長一些，但卻是網(wǎng)絡(luò)狀況的精確反映。</p><p>　　2）是第二次傳輸?shù)腁CK。</p><p>　　TCP源端并沒有辦法區(qū)分這兩種情況。如果發(fā)生的是第二種情況而TCP實體只是簡單地將RTT算成是從第一次傳輸?shù)绞盏紸CK這段時間，那么這個時間就比實際的RTT要長得多。將這個錯誤的RTT輸入到Jacobson算法中會產(chǎn)生太高的SRTT和RTO。另外，這個效果會向前傳播許多次迭代，因為一次迭

72、代產(chǎn)生的SRTT值是下一次迭代的輸入值。</p><p>　　一種更糟的方法是將RTT算成從第二次傳輸?shù)绞盏紸CK這段時間。如果這個ACK實際上是對第一次傳輸?shù)腁CK，那么我們測得的RTT值就比實際值小許多。從而導(dǎo)致SRTT和RTO值太小。這可能產(chǎn)生正反饋效應(yīng)，引起更多的重傳和更多的錯誤測量。</p><p>　　Karn算法采用以下規(guī)則解決了這個問題：</p><p&

73、gt;　　1）要使用對重傳報文段測得的RTT更新SRTT和SDEV。</p><p>　　2）在重傳時使用等式計算退避RTO。</p><p>　　3）后續(xù)各報文段使用退避RTO值，直到收到了一個對未被重傳報文段的確認(rèn)為止。當(dāng)一個對未被重傳報文段的確認(rèn)收到以后，Jacobson算法又被激活，用來計算將來的RTO值。</p><p>　　4.3 TCP 擁塞控制所采

74、用的機(jī)制</p><p>　　為了更好的進(jìn)行擁塞控制，TCP主要采用以下四種機(jī)制：慢啟動、擁塞避免、快速重傳和快速恢復(fù)。</p><p><b>　　1．慢啟動：</b></p><p>　　當(dāng)連接剛建立或超時時，進(jìn)入慢啟動階段。當(dāng)新建TCP連接時，擁塞窗口被初始化為一個數(shù)據(jù)包大小。源端按cwnd大小發(fā)送數(shù)據(jù)，每收到一個ACK確認(rèn)，就增加一個數(shù)

75、據(jù)包發(fā)送量，這樣慢啟動階段cwnd隨RTT呈指數(shù)級增長。</p><p>　　慢啟動采用逐漸增大cwnd的方法，可以防止TCP在啟動一個連接時向網(wǎng)絡(luò)發(fā)送過多的數(shù)據(jù)包而造成不必要的數(shù)據(jù)丟失和網(wǎng)絡(luò)擁塞，并且它還能夠避免采用單純的AIMD算法造成的吞吐量增加過慢的問題。</p><p>　　為了防止cwnd的無限制增長引起網(wǎng)絡(luò)擁塞，引入一個狀態(tài)變量：慢啟動門限值ssthresh。</p&g

76、t;<p>　　當(dāng)cwnd<ssthresh時，使用上述的慢啟動算法，cwnd隨RTT呈指數(shù)增長。</p><p>　　當(dāng)cwnd>ssthresh時，使用擁塞避免算法，減緩cwnd的增長速度。</p><p>　　當(dāng)cwnd=ssthresh時，既可使用慢啟動算法也可使用擁塞避免算法。</p><p><b>　　2．擁塞避免：

77、</b></p><p>　　當(dāng)發(fā)現(xiàn)超時或收到3個相同ACK確認(rèn)幀時，網(wǎng)絡(luò)發(fā)生了擁塞(主要因為由傳輸引起的數(shù)據(jù)包損壞和丟失的概率很小(<l％))。此時就進(jìn)入擁塞避免階段。慢啟動門限值(ssthresh)被設(shè)置為當(dāng)前擁塞窗口大小的一半；如果超時，擁塞窗口被置1。如果此時cwnd<=ssthresh，TCP就重新進(jìn)入慢啟動過程；如果cwnd>ssthresh，TCP就執(zhí)行擁塞避免算法，此

78、時，cwnd在每次收到一個ACK時只增加1／cwnd個數(shù)據(jù)包，這樣，在一個RTT內(nèi)，cwnd將增加1，所以在擁塞避免階段，cwnd不是呈指數(shù)增長，而是線性增長。</p><p>　　3．快速重傳和快恢復(fù)階段：</p><p>　　在擁塞避免階段，當(dāng)數(shù)據(jù)包超時時，cwnd被置為1，重新進(jìn)入慢啟動階段，這會導(dǎo)致過大地減小發(fā)送窗口尺寸，降低TCP連接的吞吐量。因此，引入了快速重傳和快速恢復(fù)機(jī)制。

79、</p><p>　　在快速重傳階段，當(dāng)源端收到3個或3個以上重復(fù)的ACK時，就判定隨后的數(shù)據(jù)包丟失，應(yīng)該立刻重傳，進(jìn)入快速恢復(fù)階段。</p><p>　　在快速恢復(fù)階段，設(shè)置為ssthresh=cwnd/2；重傳丟失的報文段；設(shè)置cwnd=ssthersh+n（n為已經(jīng)收到的重復(fù)報文段的個數(shù)）；收到非重復(fù)ACK時，置cwnd＝ssthresh，轉(zhuǎn)入擁塞避免階段；如果發(fā)生超時重傳，則置ss

80、thresh為當(dāng)前cwnd的一半，cwnd＝1，重新進(jìn)入慢啟動階段。這種方法避免了數(shù)據(jù)包超時后就重新進(jìn)入慢啟動階段，提高了TCP連接的吞吐量。</p><p><b>　　實例分析：</b></p><p>　　下面通過幾個實例分析一下TCP擁塞控制的幾個階段。</p><p>　　1．慢啟動和擁塞避免的實例</p><p&

81、gt;　　先假設(shè)窗口的單位為報文段，當(dāng)TCP連接進(jìn)行初始化時，將擁塞窗口置為1，即cwnd=1。慢開始門限的初始值設(shè)置為8，即ssthresh=8。發(fā)送端的發(fā)送窗口win不能超過擁塞窗口cwnd和通告窗口awin中的最小值。假定通告窗口awin足夠大，因此發(fā)送窗口win的數(shù)值等于擁塞窗口cwnd的數(shù)值。在執(zhí)行慢啟動算法時，擁塞窗口cwnd=1。以后發(fā)送端每收到一個對新報文段的確認(rèn)ACK，就將cwnd+1，開始下一次傳輸。當(dāng)cwnd增長到

82、慢開始門限值ssthresh時，即cwnd=8時，改為擁塞避免算法。假定擁塞窗口的數(shù)值增長到了12時，網(wǎng)絡(luò)出現(xiàn)超時，則更新ssthresh=6，擁塞控制窗口cwnd=1，執(zhí)行慢啟動算法。當(dāng)cwnd=6時改為擁塞避免算法。</p><p>　　圖4.2慢啟動和擁塞控制的實例</p><p>　　上圖4.2中發(fā)送了3次收到3個ACK后控制窗口cwnd達(dá)到了慢開始門限值ssthresh=8，進(jìn)入

83、了擁塞避免階段，又傳輸了4次，當(dāng)cwnd=12時，網(wǎng)絡(luò)發(fā)生擁塞，執(zhí)行擁塞避免算法。使cwnd=1，ssthresh=6再開始慢啟動階段，當(dāng)cwnd=6時進(jìn)入擁塞避免階段。</p><p>　　2．快重傳和快恢復(fù)的實例</p><p>　　假定發(fā)送端發(fā)送了A1—A4，4個報文段，當(dāng)接收端收到A1，A2，A3后就發(fā)出確認(rèn)ACK2，ACK3，ACK4。由于網(wǎng)絡(luò)擁塞使A4丟失了，接收端收到下個A5

84、發(fā)現(xiàn)序號不對，但仍收下放在緩存中，同時發(fā)出確認(rèn)ACK4。發(fā)送端接著發(fā)送A5，A6，接收端收到后還要分別發(fā)送重復(fù)的ACK4。這樣發(fā)送端收到了4個ACK4，其中3個是重復(fù)的，發(fā)送端就斷定有分組丟失了立即重傳A4，同時進(jìn)入快恢復(fù)階段。設(shè)置ssthresh=ssthresh/2，cwnd=ssthresh+3，如果還可以發(fā)送就繼續(xù)發(fā)送A7，若收到新的報文段的ACK8，則將設(shè)置cwnd=ssthresh。</p><p>

85、　　圖4.3 快重傳和快恢復(fù)的實例</p><p>　　上圖4.3在cwnd=12時收到了3個重復(fù)的ACK，發(fā)送方斷定有分組丟失開始重傳，進(jìn)入快速恢復(fù)階段，使ssthresh=cwnd/2=6，cwnd=ssthresh+3=9。再經(jīng)過一次傳輸收到新報文段的確認(rèn)ACK，將cwnd設(shè)置為cwnd=ssthresh，進(jìn)入擁塞避免階段。</p><p>　　5 TCP擁塞控制算法</p

86、><p>　　TCP協(xié)議經(jīng)過多年的發(fā)展，有了多種具體的實現(xiàn)。TCP從第一個實現(xiàn)到現(xiàn)在，不斷得到改進(jìn)?，F(xiàn)有的TCP擁塞控制算法主要有Tahoe、Reno、New--Reno、SACK和Vegas。其中，Tahoe、Reno、New-Reno和SACK是基于AIMD(Additive Increase Multiplicative Decrease)機(jī)制來改變擁塞窗口cwnd的大小，而Vegas是通過觀察以前TCP連接中

87、RTT值的改變情況來控制cwnd的大小。</p><p>　　5.1 TCP 的早期實現(xiàn)</p><p>　　早期TCP使用簡單的停止等待協(xié)議，每發(fā)送一個報文，都要等待確認(rèn)后，才能順序發(fā)送下一報文，因此效率很低，且在等待確認(rèn)后，網(wǎng)絡(luò)資源也不能得到充分的利用。另外，還必須等重傳計時器超時，才能重新發(fā)送丟失的報文，對網(wǎng)絡(luò)擁塞未采取有效的措施。</p><p>　　5.

88、2 TCP Tahoe</p><p>　　1988年，Jacobsen改進(jìn)了原來的TCP機(jī)制，提出了Tahoe算法。在早期實現(xiàn)的基礎(chǔ)上，Tahoe加入了慢啟動、擁塞避免和快速重傳機(jī)制。對重發(fā)定時器的取值也進(jìn)行了改進(jìn)。并具有RTT估計和差錯恢復(fù)的功能。Tahoe的基本思想是探測網(wǎng)絡(luò)的可用帶寬，在擁塞時急劇降低數(shù)據(jù)發(fā)送速率 (即：在丟失報文段重傳之后，將cwnd的值降為1，將ssthresh置為cwnd/2后，重

89、新進(jìn)入慢啟動階段)。</p><p>　　Tahoe算法存在著不足之處：在收到3個重復(fù)ACK或在超時的情況下，Tahoe置cwnd為1，然后進(jìn)入慢啟動階段。這一方面會引起網(wǎng)絡(luò)的激烈振蕩，另一方面大大降低了網(wǎng)絡(luò)的利用率。</p><p>　　5.3 TCP Reno算法</p><p>　　針對Tahoe算法的不足之處，1990年Jacobson在Tahoe的基礎(chǔ)上

90、提出了改進(jìn)算法Reno。改進(jìn)主要有兩個方面：一是對于收到連續(xù)3個重復(fù)ACK，算法不經(jīng)過慢啟動，而直接進(jìn)入擁塞避免階段；二是增加了快速重傳/快速恢復(fù)機(jī)制。具體實現(xiàn)過程為：</p><p>　　1．收到三個重復(fù)的ACK，進(jìn)入快速重傳/快速恢復(fù)，此時ssthresh設(shè)置為當(dāng)前擁塞窗口的一半。</p><p>　　2．重傳丟失的數(shù)據(jù)包，并置cwnd＝cwnd＋n (n為收到的重復(fù)ACK數(shù))。<

91、;/p><p>　　3．發(fā)送新的數(shù)據(jù)包。</p><p>　　4．當(dāng)收到非重復(fù)的ACK時，cwnd＝ssthresh。</p><p>　　5．進(jìn)入擁塞避免階段。</p><p>　　從上面的過程可以看出，Reno在收到3個重復(fù)ACK后，就轉(zhuǎn)入快速重傳/快速恢復(fù)階段；而遇到超時時，Reno和Tahoe一樣進(jìn)入慢啟動階段。</p>&

92、lt;p>　　但是如果在一個發(fā)送窗口內(nèi)有多個包丟失時，該算法不能有效恢復(fù)出來。</p><p>　　5.4 TCP New-Reno</p><p>　　1996年在Reno的基礎(chǔ)上提出了New-Reno算法。對Reno的快速恢復(fù)機(jī)制進(jìn)行了改進(jìn)，以避免一個窗口內(nèi)發(fā)生多個報文段丟失的情況下傳輸性能的下降。在Reno中，發(fā)送端只要收到對重傳報文段的確認(rèn)就結(jié)束快速恢復(fù)過程；New-Ren

93、o則是在收到對該窗口所有報文段確認(rèn)之后才退出快速恢復(fù)過程，從而避免出現(xiàn)多個丟失造成的cwnd連續(xù)減小。因此，New--Reno比Reno能更好的保證網(wǎng)絡(luò)的穩(wěn)定性。</p><p>　　New-Reno與Reno的不同僅在于步驟1(下面所述)中變量“recover”的引入，以及步驟5中收到部分或新的確認(rèn)ACK后的處理方式。New-Reno中定義了一個“快速恢復(fù)過程”，其快速重傳和快速恢復(fù)機(jī)制可以概括為如下五步：&l

94、t;/p><p>　　1．當(dāng)TCP發(fā)送端收到第三個重復(fù)的ACK并且發(fā)送端還沒有處于快速恢復(fù)階段時，用下式設(shè)置ssthresh的值。然后用變量“recover”記錄此時傳送的最大序列號。</p><p>　　2． TCP發(fā)送端重傳丟失的報文段并設(shè)置cwnd的值為：cwnd=ssthresh+3×MSS。這將人為的按已經(jīng)離開網(wǎng)絡(luò)的報文段數(shù)目和接收端已經(jīng)緩沖的數(shù)據(jù)量來擴(kuò)充擁塞窗口。<

95、/p><p>　　3．對每次接收到的額外的重復(fù)ACK，將cwnd增大MSS字節(jié)。這將人為的擴(kuò)充擁塞窗口以反映其它已經(jīng)離開網(wǎng)絡(luò)的報文段。</p><p>　　4．如果cwnd和接收端的通告窗口的值允許的話，TCP發(fā)送端發(fā)送下一個報文段。</p><p>　　5．當(dāng)下一個確認(rèn)新報文段的ACK到達(dá)時(此ACK可能是由步驟2中的重傳引發(fā)的確認(rèn)，或者是稍后的一次重傳引起的)：&l

96、t;/p><p>　　如果這個ACK確認(rèn)了直到并包含序列號為“recover”的報文段，那么這個ACK確認(rèn)了TCP發(fā)送端在丟失報文段的第一次傳送和第三個重復(fù)ACK接收之間發(fā)送的所有報文段。TCP發(fā)送方可以設(shè)置cwnd的值為：</p><p>　　此處ssthresh是步驟1中的值(步驟l中的發(fā)送窗口是TCP進(jìn)入快速恢復(fù)階段時的值：而步驟5中的發(fā)送窗口是TCP退出快速恢復(fù)階段時的值)。</

97、p><p>　　如果這個ACK不是對所有并包含到序列號為“recover”報文段的確認(rèn)，那么這個ACK就是一個部分確認(rèn)。在這種情況下，TCP發(fā)送端并不退出快速恢復(fù)過程，而是立即重傳部分確認(rèn)ACK中指示的第一個沒有確認(rèn)的報文段。這和Reno處理部分確認(rèn)的方式不同，Reno在收到一個部分確認(rèn)ACK后立即退出快速恢復(fù)過程。如果還有任何其他重復(fù)ACK隨后到達(dá)，New-Reno發(fā)送端重復(fù)執(zhí)行上面的步驟3和4。于是，當(dāng)一個發(fā)送窗

98、口中有多個報文段丟失時，New-Reno不需等到超時重發(fā)定時器超時就能從多個報文段的丟失中恢復(fù)。TCP發(fā)送端在每個往返時間內(nèi)重發(fā)一個丟失的報文段，直至重發(fā)了所有丟失的報文段為止。New-Reno一直處于快速恢復(fù)階段直到發(fā)送端在進(jìn)入快速恢復(fù)之前發(fā)出的所有報文段都被確認(rèn)為止。</p><p>　　5.5 TCP SACK</p><p>　　1996年還提出了Reno的另一改進(jìn)SACK算法。

99、它利用SACK報文段中的選項對接收報文進(jìn)行確認(rèn)。根據(jù)SACK選項的確認(rèn)信息，發(fā)送端可以確知哪些報文段已被接收，從而只重傳那些實際丟失的報文段，這就有利于發(fā)送端從單個窗口內(nèi)丟失多個報文段的環(huán)境中快速的恢復(fù)。</p><p>　　SACK用到兩種TCP選項：授權(quán)選項和SACK選項。</p><p>　　授權(quán)選項只在連接建立時使用。此選項包含在SYN報文中被發(fā)送，表示此連接可以用SACK 選項。

100、它占兩個字節(jié)，其格式為：</p><p>　　典型的SACK算法是對Reno算法的一種簡單改進(jìn)，它們在擴(kuò)大和減小擁塞窗口上使用的都是相同的機(jī)制。在TCP中增加SACK并不改變擁塞控制的基本機(jī)制，SACK不但實現(xiàn)了Tahoe和Reno在報文段失序時的健壯性，而且必要時仍然使用重發(fā)定時器的超時重發(fā)機(jī)制來進(jìn)行恢復(fù)。</p><p>　　SACK和Reno的主要差別在于，當(dāng)多個報文段從一個數(shù)據(jù)發(fā)送

101、窗口丟失時采取的對策。SACK和Reno一樣，一般當(dāng)TCP發(fā)送端收到3個重復(fù)的ACK時就進(jìn)入快速恢復(fù)階段，發(fā)送端重發(fā)在傳輸過程重丟失了的報文段，并把擁塞窗口減小一半。在SACK的快速恢復(fù)算法中，SACK保持了一個變量pipe用來表示當(dāng)前在傳輸路徑上的報文段的估計數(shù)量。在這一點上SACK與Reno的實現(xiàn)機(jī)制不同。當(dāng)pipe小于擁塞窗口大小時，發(fā)送端只發(fā)送新的或已重發(fā)過的數(shù)據(jù)。當(dāng)發(fā)送端發(fā)送一個新報文段或重發(fā)一個老報文段時，pipe值增l；而

102、當(dāng)發(fā)送端接收了一個帶SACK選項的重復(fù)AEK時，表明新數(shù)據(jù)己被接收者接收，pipe值減1。用pipe變量可將何時發(fā)送報文段和發(fā)送哪個報文段分離開來。</p><p>　　如果有一個重發(fā)的報文段丟失，SACK可以在重發(fā)定時器超時后察覺，從而重發(fā)丟失的報文段，然后再進(jìn)入慢啟動階段。而在收到一個“恢復(fù)ACK”，確認(rèn)了再進(jìn)入快速恢復(fù)時出現(xiàn)的所有數(shù)據(jù)后，發(fā)送端就退出快速恢復(fù)階段。另外，SACK發(fā)送端對在快速恢復(fù)階段收到的“

103、恢復(fù)ACK”還使用了特殊的處理方法：對這些ACK，發(fā)送端對pipe變量值每次減2，而不是減l。</p><p>　　5.6 TCP Vegas</p><p>　　1994年提出了Vegas算法。與前幾種算法不同，Vegas是一種通過檢測網(wǎng)絡(luò)流量來避免擁塞的擁塞控制算法。Vegas的策略是調(diào)整信源的發(fā)送速率使得傳輸路徑上的路由器中緩存少量的分組。它主要從三個方面對TEP擁塞控制基本機(jī)制進(jìn)

104、行了改進(jìn)；重傳機(jī)制、擁塞避免機(jī)制和慢啟動機(jī)制。</p><p><b>　　1．新的重傳機(jī)制：</b></p><p>　　Vegas對Reno的重傳機(jī)制做了以下擴(kuò)充：首先，Vegas讀取并記錄每次報文段發(fā)送時的系統(tǒng)時鐘。當(dāng)一個ACK到達(dá)時Vegas再次讀取時鐘，并用此時間與相應(yīng)報文段記錄的時間戳來計算RTT值。然后，Vegas用這個更精確的RTT估值來決定在下面兩種

105、情況下的重傳：當(dāng)收到一個重復(fù)的ACK時，Vegas就檢測“當(dāng)前時間一相應(yīng)報文段的發(fā)送時間”的差值是否大于超時值，若大于超時值，發(fā)送端重傳此報文而不需要等收到三個重復(fù)的ACK后才做出反應(yīng)，所以能更及時的做出反應(yīng)。同時也避免進(jìn)入這樣一種狀態(tài)：發(fā)送端永遠(yuǎn)收不到三個重復(fù)的ACK。從而不得不依賴定時器的超時而進(jìn)行重發(fā)。</p><p>　　當(dāng)收到一個非重復(fù)的ACK時，如果這是重傳之后收到的第一或第二個確認(rèn)，Vegas就再次

106、檢測報文段發(fā)送后的時間間隔是否大于超時值，若大于超時值就重傳此報文段，這樣就會知道在早先重傳之前可能丟失的其它的報文段，而不需要等待第一個重復(fù)的ACK到達(dá)才覺察。</p><p>　　2．改進(jìn)的擁塞避免機(jī)制：</p><p>　　Vegas的目標(biāo)是保持網(wǎng)絡(luò)中恰當(dāng)數(shù)量的額外數(shù)據(jù)。顯然，如果一個連接發(fā)送過多額外數(shù)據(jù)會就導(dǎo)致?lián)砣?，如果一個連接發(fā)送過少的額外數(shù)據(jù)，它就不能在有可用帶寬的條件下快速的