擁塞控制演算法

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

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

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

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

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

防止擁塞的方法

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

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

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

Ⅱ 擁塞控制演算法

做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的減少量。

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

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

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

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

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

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

源演算法和鏈路演算法

Ⅵ 現在linux系統中用的是什麼擁塞控制演算法

2擁塞（congestion）

般說通信網太組網路性能降低種情況叫擁塞

1本質：資源需求 >用資源——擁塞現表示荷載超資源承受能力

2、擁塞產原

主要原通信量往往突發

輸入應輸；

n慢速處理器；

n低帶寬線路

n3、解決辦

n針某素解決案能提高網路性能起點點處甚至能僅僅轉移影響性能瓶頸；
n需要全面考慮各素

1顯兩種克服：增加資源降低負荷（拒絕某些服務）

管理（盡能避免）擁塞：主機能恆定速率發送信息；通信量整形（強迫組某種更預見性速率傳送）

4、n擁塞控制與流量控制差別

n擁塞控制（congestion control）需要確保通信網能夠承載用戶提交通信量全局性問題涉及主機、路由器等素；

n流量控制（flow control）與點點通信量關主要解決快速發送與慢速接收問題局部問題般都基於反饋進行控制

二、擁塞控制基本原理

n根據控制論擁塞控制兩類

n1、環控制

n通設計解決問題避免擁塞發；

n擁塞控制考慮網路前狀態；

n2、閉環控制

n基於反饋機制；

n3、工作程

n監控系統發現何何發擁塞；

n發擁塞消息傳給能採取作站點；

n調整系統操作解決問題

n4、衡量網路否擁塞參數

n缺乏緩沖區造丟包率；

n平均隊列度；

n超重傳包數目；

n平均包延遲；

n包延遲變化（Jitter）

n5、反饋

n向負載發源發送告警包；

n包結構保留位或域用表示發擁塞旦發擁塞路由器所輸包置位向鄰居告警；

n主機或路由器主、周期性發送探報（probe）查詢否發擁塞

6、n擁塞預防策略——流量整形（Traffic Shaping）

n環控制

Ⅶ 組播擁塞控制的演算法

組播中的擁塞控制

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

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

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

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