擁塞控制演算法

1. 在TCP的擁塞控制中,什麼是慢開始、擁塞避免、快重傳和快恢復演算法

慢開始：在主機剛剛開始發送報文段時可先將擁塞窗口cwnd設置為一個最大報文段MSS的數值。在每收到一個對新的報文段的確認後，將擁塞窗口增加至多一個MSS的數值。

擁塞避免：當擁塞窗口值大於慢開始門限時，停止使用慢開始演算法而改用擁塞避免演算法。

快重傳演算法：發送端只要一連收到三個重復的ACK即可斷定有分組丟失了，就應該立即重傳丟手的報文段而不必繼續等待為該報文段設置的重傳計時器的超時。

接下來執行的不是慢啟動演算法而是擁塞避免演算法。這就是快速恢復演算法。.

防止擁塞的方法

（1）在傳輸層可採用：重傳策略、亂序緩存策略、確認策略、流控制策略和確定超時策略。

（2）在網路層可採用：子網內部的虛電路與數據報策略、分組排隊和服務策略、分組丟棄策略、路由演算法和分組生存管理。

（3）在數據鏈路層可採用：重傳策略、亂序緩存策略、確認策略和流控制策略。

2. 擁塞控制演算法

做QoS嗎？你還是找論文吧，關於這方面的論文還是比較多的，這里有一個演算法，你先看一下吧

BLUE。BLUE的隊列管理方式直接基於丟包率和鏈路利用率,而非瞬時的或平均隊列長度。即它記錄過去的丟包和鏈路利用狀態,以此來對BLUE設定概率Pm 來標記(或丟棄)隊列中的包。如果由於緩存溢出而造成隊列連續丟包, BLUE將增大標記概率Pm ,使返回源端的擁塞通知的速率增加。
相反,如果隊列變空了或鏈路處於空閑狀態,則減小標記概率,從而降低丟包率,提高鏈路利用率。以下是
BLUE演算法:
Upon packet loss (or Qlen >L ) event:
if ( ( now2last update) > freeze time)
then Pm = Pm + d1
last update = now
Upon link idle event:
if ( ( now2last update) > freeze time)
then Pm = Pm + d1
last update = now
其中: freeze time決定兩個Pm 之間的時間間隔; d1 和d2 決定當隊列溢出時Pm 的增加量或當鏈路空閑時Pm的減少量。

你是學生嗎？如果是直接上中國期刊網，不是的話可能要花錢了，書上一般不會給你具體演算法。

3. 組播擁塞控制的演算法

組播中的擁塞控制

概念
通過網路進行的數據和信息傳輸已經成為現代商業社會重要而又不可缺少的組成部分和賴以生存的基礎。近年來，隨著信息技術的迅猛發展，網路應用大量增加，使得原來已經存在的龐大的數據傳輸量成倍地增長。

在已經被Internet普遍採用的工作方式中，數據傳輸一般通過單路廣播和廣播兩種方式進行。其中，單路廣播方式是傳統的點對點數據傳輸，在發送方和每一接收方需要單獨的數據通道，從一台伺服器送出的每個數據包只能傳送給一個客戶機，現已為絕大部分數據傳輸業務所採用。廣播方式則允許一個主機將同樣的信息發送到同一網路內的所有其他主機。

面對已經龐大而且還在不斷增加的數據傳輸業務，這兩種方式越來越凸顯出自身的缺陷。依照原有的單路廣播方式，如果Internet中有1000個用戶希望獲得同一個數據包的拷貝，那麼每個用戶必須分別對信息源節點伺服器發送單獨的請求，而信息源節點伺服器必須向每個用戶發送它們自己申請的數據包拷貝。這種巨大的冗餘代價首先是負擔過於沉重的伺服器的響應時間很長；其次是管理人員被迫購買不必要的硬體和帶寬，來保證一定的服務質量，資源和成本極大浪費。在目前的情況下，無論如何改善硬體基礎條件，單路廣播也無法完成將數據分發給分布在Internet上的數十萬台計算機的傳輸業務。而囿於自身獨有的性質，單路廣播難以滿足現今靈活而多樣的業務要求，企業網路規模的擴大也使得單路廣播方式應用的空間更為狹窄。

基於以上情況，人們一直在尋找一種更符合商業運作模式、更為靈活的數據傳輸方式。由於從一個主機向多個主機或者從多個主機向多個主機發送同一信息的業務已經在現有的業務總量中占據了相當大的比例，因此人們提出了組播的概念。在最初提出的對組播的要求和設想中包括：組播應該把網路納入信息傳輸過程；組播在完成多點到多點或一點到多點的數據傳輸業務時的性能應比傳統傳輸方式有較大的提高；組播應該具有較廣的業務范圍。

1988年，斯坦福大學就是依照上述的一些設想實現了第一次多路通話。1989年，組播的詳細說明問世。這份說明雖在至今的十餘年中經過多次修改，但一部分根本的原則始終得以堅持和完善。其中最根本的一點在於:組播依託於IP協議完成;IP組播強制網路在數據傳遞樹的分叉處進行信息包復制，而不是由信息源節點多次重復地發送同樣的信息包。這也正是組播的精髓所在。1992年，IETF定義和發布了一個組播的網路標准，用於建立組播主幹網 (MBONE),即在Internet上運行的單路廣播和組播綜合網路。兩年後，這個主幹網就已經初具規模。這個平台構建在原有的Internet設備上，由支持IP組播的子網和路由器組成，同時允許組播通信量通過無組播能力的Internet部分，從而在整個Internet范圍內對組播開放。1995年，Cisco和Lucent開始銷售支持組播的路由器和交換機。一年後，依賴組播的應用產品開始上市。在十餘年的開發和研究中，組播已經成為人們關注的一個焦點。

基本認識

組播擁塞控制問題的重要性隨著組播日益廣泛的應用需求而變得越來越重要。發生在組播中的擁塞既對擁塞控制協議的設計提出了新挑戰，同時也提供了一個對已經存在的控制方法與觀點進行重新認識的機會。組播雖然是應用在Internet上的，但其擁塞控制仍然依賴於TCP/IP協議。傳統的TCP擁塞控制和IP擁塞控制對組播的擁塞控制仍然具有較大的參考價值,傳統演算法和理念也是組播擁塞控制的出發點和技術基礎。

發生在不同環境中的組播對服務的要求千差萬別，單獨的某一個擁塞控制演算法根本不能完全適應其需求。

大多數進行擁塞控制研究的專家都是沿著這樣的方向前進的：在源節點端採用基於速率的擁塞處理機制；在公平性標准方面則盡量實現與TCP擁塞控制的兼容，從而適應TCP擁塞控制演算法。不過，將基於速率控制的演算法用於源節點端已經遇到了很大的阻力。按照這種方法，為了響應擁塞發生，源節點端需要立即接收到所有接收者狀態的反饋信息。然而，由於組播涉及大量的接收者，所以從接收者直接發往源節點端更新信息的過程會非常復雜,而且代價非常昂貴。

端對端數據傳輸業務的擁塞控制

端對端的數據傳輸與單路廣播是完全不同的兩個概念。端對端的數據傳輸是所有數據傳輸業務的基礎。

在端對端業務的擁塞控制中發揮重要作用的兩個因素是控制參數和控制演算法。控制參數指的是對流入網路的數據流進行管制的指標。例如，如果選定窗口的大小為控制參數，那麼控制策略就是將待發的數據量保持在允許的窗口范圍之內。控制演算法則是確定控制參數的演算法。在TCP擁塞控制中，控制參數是窗口的大小，控制演算法則由慢啟動和擁塞避免兩個演算法組成。

從擁塞控制的角度看，在一個組播過程中，其接收者資格既可以是固定的，也可以是變化的。當一個組播過程的接收者資格完全固定時，無論網路的擁塞狀況如何，所有的接收者都必須自始至終地保留在組播接收組中。在這種情況下，擁塞控制的核心就在於源節點端的流量控制規則。源節點遵照這一規則對所有的接收路徑作出相同的反應，這就意味著，流量控制參數由所有接收者中最慢的一個決定。

當一個組播的接收者資格可變時，擁塞控制由流量控制策略和接收者資格確定聯合完成。一方面，某些特殊的應用提出了特定的數據要求;另一方面，接收者的數量要盡量多，在這兩方面要求之間應建立一個盡量好的平衡。最原始的方法就是將接受速率最慢的接收者的資格取消，但這種方法顯然會帶來網路的不穩定，沒有從根本上解決問題。還有一種相對好一些的方法，就是把組播接收者按照接收速率分成若干個子群，每個子群依照各自的、不同的速率接收數據：速度比較慢的那些子群將花費更多的時間完成數據接收；如果是實時通信，那麼這些子群接收到的數據質量將降低。使用這種方法時，數據文件或數據流必須依照適當的編碼和封裝技術組織起來，以適應不同接收速率子群的需要。

在端對端的業務中，差錯控制與擁塞控制關系密切。這是由於對數據包丟失的探測和報告對兩者都是有用的。另外，差錯控制的方法會影響數據的編碼和組織方法。基於這些原因，在端對端業務中的差錯控制與擁塞控制往往集成設計在同一個協議中。

上述的擁塞控制策略可以由組播的源節點和接收者分擔，而且確定每一方承擔的任務的標准和方法也是多樣的。在單路廣播中，源節點與接收者之間的任務分割不是很重要。不過，將一些已經被大量採用的策略進行改進，增加接收者在擁塞控制中承擔的任務，可以提高這些策略的適應性和生命力。

在組播中，不同業務在各自的源節點和接收者之間分布和組織數據的方式非常重要。協議的魯棒性依賴於進程內部控制信息的准確交換，而當接收方的數量增加時，協議的可擴展性很大程度也依賴於此。組播所特有的一些性質可以確定進程間業務組織的一部分特性，如接收方資格是否固定、源節點是否對每個接收端的進程都進行記錄等。

組播控制演算法有一個非常重要的性能指標——可擴展能力。它是指在控制演算法的性能開始退化之前，接收群能容納的最大的規模。這個指標是有限的，原因有兩個:大的接收群會增大擁塞控制的復雜度，擁塞控制採用的演算法也對接收群中接收方的數量提出了要求。從更深的層次來看，可擴展能力與控制演算法的公平性以及擁塞避免屬性有著密切的關系。

組播擁塞控制的焦點問題

1．控制參數的選擇

可供選擇的參數包括傳輸速率和窗口容量。

（1）基於傳輸速率的控制策略。最簡單的形式就是保持源節點以低於設定值的恆定的速率向網路發出數據流。而另一種策略是保持數據發送的平均速率低於設定值，同時增加第二個參數,對突發的數據流進行控制。對於單路廣播和組播，基於速率的擁塞控制的含義與實施過程是完全相同的。

（2）基於窗口的控制策略 在單路廣播中，基於窗口的控制策略將未確認的數據包的總長度控制在設定的窗口容量以下。對於組播，窗口的含義以及這種控制策略的實施在很大程度上將變得更為復雜。然而，這種復雜性也為基於窗口的策略作出針對組播的改進提供了機會。

在一個源節點對多個接收者的組播過程中，源節點的發送速率是相同的，而不同的接收者窗口的容量卻是不同的。依據控制論的觀點，相對於同一個系統和過程，控制參數越多，控制效果就越好。基於此，在組播的過程中，一般都選擇窗口容量作為控制參數。

在基於窗口的組播控制策略中，為避免發生不必要的資源節點浪費，得到盡可能好的傳輸效果，每個接收者的窗口容量要分別設定;廣播過程中，控制演算法必須對每個接收方未確認的數據包數量分別進行監視和控制。這正是這種控制策略的代價所在。

基於窗口的組播擁塞控制策略的復雜度隨著接收者數量的增加呈線性增長。它引發了比較嚴重的擴展性的問題。

2．控制參數的公平性

擁塞控制的參數選定之後，需要採用某個特定的演算法，求出網路擁塞狀態相應的參數取值。當控制策略的公平性主要體現為控制演算法時，它就會受到參數選擇的影響。

如果某一控制策略在每個進程中達到平衡時待確認數據包的平均數量與其迴路響應時間無關，而僅僅依賴於數據丟失率，那麼稱這種策略具有與窗口相關的公平性。相應地，如果某一控制策略具有與速率相關的公平性，那麼進程中待確認的數據包平均數量由迴路響應時間決定。

這里定義的公平性與控制參數的選擇沒有必然的聯系。不論是基於窗口的控制策略還是基於速率的，這兩種公平性都可以通過選擇不同的控制演算法達到。這里定義的兩種公平性並不是對一種演算法公平性的完美概括。此外，定義上述公平性的依據是演算法達到平衡時的性能，並不是演算法在進程中的平均性能。

通過分析基於窗口與基於速率兩種控制策略的控制過程，人們發現，在控制參數、演算法迴路響應時間以及演算法的公平性指標三者之間存在著特定的聯系:要通過基於速率的控制策略達到基於窗口的公平性，或者要通過基於窗口的控制策略達到基於速率的公平性，都必須知道迴路響應時間。

3．由接收者驅動的擁塞控制

相對於單路廣播，組播有4個主要的特點：

(1)當接收者的數量增加時，對系統進行擁塞控制的復雜度會隨之增加。如果擁塞控制一部分特定的工作由源節點來完成，那麼源節點有限的處理能力將限制控制演算法的擴展性。

(2)並不是所有的擁塞控制措施都是針對源節點的。如果控制策略要求某一個接收者退出接收群，那麼這些措施只能由接收方自身來完成。

(3)在大規模的組播系統中，重發丟失的數據包並不總由源節點來完成。

(4)在很多組播應用中，接收方的數量和身份並不為源節點所知。

由以上分析可以得出這樣的結論:組播中擁塞控制的任務應該盡可能地向接收方一側轉移。也就是說，每個接收者自主地確定自己的控制參數閾值,這就是對「接收者驅動的擁塞控制」的通俗理解。顯然，根據這種方法，每個接收者都必須探測自己路徑上的數據丟失,以確定自身控制參數閾值。此外，如果控制演算法需要使用迴路響應時間，那麼探測和記錄這個時間的工作也要由接收者自己來完成。

一旦接收者確定了各自的參數閾值，那麼必要的反饋必須馬上提交給源節點。在基於速率的控制策略中，由接收者發送回源節點的反饋就是它的閾值速率，這樣，整個系統的傳輸速率可以用加法求出。如果採用的是基於窗口的控制策略，那麼源節點的窗口容量也可以通過一定的優化演算法從各接收者提供的反饋中更精確地確定出來。

1999年，貝爾實驗室的3名研究人員提出了一種主要由接收方執行的擁塞控制策略。他們對組播的環境進行了一定的限制和規定，然後得到結論:這種策略的可擴展性可以在很大范圍內得到保證。這項成果把可擴展性與控制參數以及演算法公平性聯系起來，已經成為近來組播擁塞控制的出發點。

組播面臨的挑戰

組播擁塞控制面臨的最大挑戰仍然是擴展性問題。在組播樹中，為了響應擁塞發生，源節點需要立即接收到所有接收者狀態的反饋信息。然而，由於組播涉及大量的接收者，因此從接收者直接發往源節點更新信息的過程會非常復雜且昂貴。

組播中擁塞控制的另一挑戰是持續擁塞效應的隔離問題。由於TCP擁塞控制在樹的任意一部分接到擁塞指示時都會減少發送速率，因此一個組播樹會影響Internet中許多不同的部分。雖然這種方式在不同數據流之間有一定公平性，但會在同一個Multicast組中的不同接收者之間導致不公平，特別是對那些實際上並沒有擁塞的接收者來說降低傳輸速率不公平。對可擴展的可靠Multicast來講，解決以上挑戰的主要思路在於建立合理分層的來自接收者的反饋信息的發布方式;克服估計Multicast Tree中閾值確定困難的問題;建立重傳窗口規范,恢復數據流，防止恢復階段又發生擁塞等。

針對這些問題，有人提出了一種在Multicast上的MTCP(Multicast TCP)擁塞控制，其擴展性和公平性試驗的模擬結果較好，為解決這一問題提供了可參考的方向。但是，無論如何，源節點只有一個，它不可能滿足所有接收方的相同的業務要求。重要指標的選擇和保證措施便成為這種情況下最重要的一項工作

4. 如何在運行的內核中選擇tcp擁塞控制演算法

先查看本機支持的擁賽控制演算法，命令：
cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
如果支持，再以root帳號運行命令：
echo "vegas" >/proc/sys/net/ipv4/tcp_congestion_control

5. 網路課程設計源代碼：慢開始和擁塞控制演算法

TCP採用慢開始和擁塞避免的方法控制發送
慢開始的思路是，先測試一下，在由小到大的增大發送窗口
具體的：預先設置一個慢開始門限，ssthresh(用於控制擁塞）
先設擁塞窗口cwnd=1，發送第一個報文，收到確認後把cwnd設為2，在發送，收到回復後，再把cwnd增加2個，即，收到回復後就把cwnd增加一倍，這就是慢開始演算法
當cwnd>ssthresh就停止上述的慢開始演算法而使用擁塞避免演算法
擁塞避免演算法就是每收到一個回復後就把cwnd加1，直到出現擁塞
無論在慢開始還是擁塞避免時只要出現擁塞就把ssthresh設為原值的一半（這就是乘法減小)並把cwnd設為1，在執行慢開始演算法，重復上述過程

6. 常見的tcp擁塞控制有哪幾種演算法

慢啟動：最初的TCP在連接建立成功後會向網路中發送大量的數據包，這樣很容易導致網路中路由器緩存空間耗盡，從而發生擁塞。因此新建立的連接不能夠一開始就大量發送數據包，而只能根據網路情況逐步增加每次發送的數據量，以避免上述現象的發生。具體來說，當新建連接時，cwnd初始化為1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增加1個MSS大小。這樣cwnd的值就隨著網路往返時間(Round Trip Time,RTT)呈指數級增長，事實上，慢啟動的速度一點也不慢，只是它的起點比較低一點而已。我們可以簡單計算下：
開始 ---> cwnd = 1
經過1個RTT後 ---> cwnd = 2*1 = 2
經過2個RTT後 ---> cwnd = 2*2= 4
經過3個RTT後 ---> cwnd = 4*2 = 8
如果帶寬為W，那麼經過RTT*log2W時間就可以占滿帶寬。
擁塞避免：從慢啟動可以看到，cwnd可以很快的增長上來，從而最大程度利用網路帶寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制。TCP使用了一個叫慢啟動門限(ssthresh)的變數，當cwnd超過該值後，慢啟動過程結束，進入擁塞避免階段。對於大多數TCP實現來說，ssthresh的值是65536(同樣以位元組計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值不再指數級往上升，開始加法增加。此時當窗口中所有的報文段都被確認時，cwnd的大小加1，cwnd的值就隨著RTT開始線性增加，這樣就可以避免增長過快導致網路擁塞，慢慢的增加調整到網路的最佳值。
上面討論的兩個機制都是沒有檢測到擁塞的情況下的行為，那麼當發現擁塞了cwnd又該怎樣去調整呢？
首先來看TCP是如何確定網路進入了擁塞狀態的，TCP認為網路擁塞的主要依據是它重傳了一個報文段。上面提到過，TCP對每一個報文段都有一個定時器，稱為重傳定時器(RTO)，當RTO超時且還沒有得到數據確認，那麼TCP就會對該報文段進行重傳，當發生超時時，那麼出現擁塞的可能性就很大，某個報文段可能在網路中某處丟失，並且後續的報文段也沒有了消息，在這種情況下，TCP反應比較「強烈」：
1.把ssthresh降低為cwnd值的一半
2.把cwnd重新設置為1
3.重新進入慢啟動過程。
從整體上來講，TCP擁塞控制窗口變化的原則是AIMD原則，即加法增大、乘法減小。可以看出TCP的該原則可以較好地保證流之間的公平性，因為一旦出現丟包，那麼立即減半退避，可以給其他新建的流留有足夠的空間，從而保證整個的公平性。
其實TCP還有一種情況會進行重傳：那就是收到3個相同的ACK。TCP在收到亂序到達包時就會立即發送ACK，TCP利用3個相同的ACK來判定數據包的丟失，此時進行快速重傳，快速重傳做的事情有：
1.把ssthresh設置為cwnd的一半
2.把cwnd再設置為ssthresh的值(具體實現有些為ssthresh+3)
3.重新進入擁塞避免階段。
後來的「快速恢復」演算法是在上述的「快速重傳」演算法後添加的，當收到3個重復ACK時，TCP最後進入的不是擁塞避免階段，而是快速恢復階段。快速重傳和快速恢復演算法一般同時使用。快速恢復的思想是「數據包守恆」原則，即同一個時刻在網路中的數據包數量是恆定的，只有當「老」數據包離開了網路後，才能向網路中發送一個「新」的數據包，如果發送方收到一個重復的ACK，那麼根據TCP的ACK機制就表明有一個數據包離開了網路，於是cwnd加1。如果能夠嚴格按照該原則那麼網路中很少會發生擁塞，事實上擁塞控制的目的也就在修正違反該原則的地方。
具體來說快速恢復的主要步驟是：
1.當收到3個重復ACK時，把ssthresh設置為cwnd的一半，把cwnd設置為ssthresh的值加3，然後重傳丟失的報文段，加3的原因是因為收到3個重復的ACK，表明有3個「老」的數據包離開了網路。
2.再收到重復的ACK時，擁塞窗口增加1。
3.當收到新的數據包的ACK時，把cwnd設置為第一步中的ssthresh的值。原因是因為該ACK確認了新的數據，說明從重復ACK時的數據都已收到，該恢復過程已經結束，可以回到恢復之前的狀態了，也即再次進入擁塞避免狀態。
快速重傳演算法首次出現在4.3BSD的Tahoe版本，快速恢復首次出現在4.3BSD的Reno版本，也稱之為Reno版的TCP擁塞控制演算法。
可以看出Reno的快速重傳演算法是針對一個包的重傳情況的，然而在實際中，一個重傳超時可能導致許多的數據包的重傳，因此當多個數據包從一個數據窗口中丟失時並且觸發快速重傳和快速恢復演算法時，問題就產生了。因此NewReno出現了，它在Reno快速恢復的基礎上稍加了修改，可以恢復一個窗口內多個包丟失的情況。具體來講就是：Reno在收到一個新的數據的ACK時就退出了快速恢復狀態了，而NewReno需要收到該窗口內所有數據包的確認後才會退出快速恢復狀態，從而更一步提高吞吐量。
SACK就是改變TCP的確認機制，最初的TCP只確認當前已連續收到的數據，SACK則把亂序等信息會全部告訴對方，從而減少數據發送方重傳的盲目性。比如說序號1，2，3，5，7的數據收到了，那麼普通的ACK只會確認序列號4，而SACK會把當前的5，7已經收到的信息在SACK選項裡面告知對端，從而提高性能，當使用SACK的時候，NewReno演算法可以不使用，因為SACK本身攜帶的信息就可以使得發送方有足夠的信息來知道需要重傳哪些包，而不需要重傳哪些包。

7. TCP的擁塞控制演算法中,請簡述慢開始演算法和擁塞避免演算法的基本思想

慢開始演算法:
cwnd每收到一個acknowledge增加1
擁塞避免演算法
當cwnd達到或者超過當前設定的threshold後，cwnd每個RTT增加1。
如果發生timeout, cwnd = 1，threshold=cwnd/2. 重新進入慢開始。
如果收到3個重復的acknowledgement, cwnd = threshold = cwnd/2.

8. 根據演算法的實現位置分類，擁塞控制演算法可以分為----和----

源演算法和鏈路演算法

9. 簡述擁塞控制的四種基本演算法

慢開始,擁塞避免,快重傳,快恢復.
首先要明白什麼TCP協議可靠傳輸,還有什麼是擁塞窗口:表示當前發送數據的上限,但是它會根據網路好壞狀況動態改變.
慢開始:簡單的說,開始傳輸時,傳輸的數據由小到大遞增到一個值(即發送窗口由小到大(指數增長)逐漸增大到擁塞窗口的數值).
擁塞避免:數據發送出去,並發到接收方發回來的確認收到,擁塞窗口每次值加1地線性增大.
快重傳:數據傳輸時(數據被分成報文,每個報文都有個序號),中間的一部分丟失接收方沒收到,接收方連續接到後面的數據,則發回對丟失前的數據的重復確認,這樣發送方就知道有部分數據丟失了,於是從丟失出重傳數據.
快恢復:快恢復是與快重傳配合的演算法,在發生數據丟失時,發送方收到接收方發回的三個重復確認信息時,就把每次傳輸的數據量減為原來的一半,擁塞窗口也修改為這個值,然後又開始擁塞避免的演算法.

10. tcp如何實現擁塞控制

TCP擁塞控制是傳輸控制協議（英語：Transmission Control Protocol，縮寫TCP）避免網路擁塞的演算法，是互聯網上主要的一個擁塞控制措施。它使用一套基於線增積減模式的多樣化網路擁塞控制方法（包括慢啟動和擁塞窗口等模式）來控制擁塞。在互聯網上應用中有相當多的具體實現演算法。

在TCP中，擁塞窗口（congestion window）是任何時刻內確定能被發送出去的位元組數的控制因素之一，是阻止發送方至接收方之間的鏈路變得擁塞的手段。他是由發送方維護，通過估計鏈路的擁塞程度計算出來的，與由接收方維護的接收窗口大小並不沖突。

1、慢開始演算法：

簡單的說，開始傳輸時，傳輸的數據由小到大遞增到一個值(即發送窗口由小到大(指數增長)逐漸增大到擁塞窗口的數值)。

2、擁塞避免演算法：

數據發送出去，並發到接收方發回來的確認收到，擁塞窗口每次值加1地線性增大。

3、快重傳演算法：

數據傳輸時(數據被分成報文，每個報文都有個序號)，中間的一部分丟失接收方沒收到，接收方連續接到後面的數據，則發回對丟失前的數據的重復確認，這樣發送方就知道有部分數據丟失了，於是從丟失出重傳數據。

4、快恢復演算法：

快恢復是與快重傳配合的演算法，在發生數據丟失時，發送方收到接收方發回的三個重復確認信息時，就把每次傳輸的數據量減為原來的一半，擁塞窗口也修改為這個值,然後又開始擁塞避免的演算法。