擁塞控制機(jī)制是什么意思

擁塞是當(dāng)多個用戶競爭訪問相同的資源(帶寬、緩沖區(qū)和隊(duì)列)時(shí)發(fā)生在共享網(wǎng)絡(luò)上的問題。就像高速公路發(fā)生的擁塞，很多車輛進(jìn)入高速公路而不考慮即將發(fā)生或已經(jīng)發(fā)生的擁塞，隨著越來越多的車輛進(jìn)入高速公路，擁塞會變得越來越嚴(yán)重。最后，斜坡上的車輛可能后退下滑，從根本上阻止車輛上去。

在數(shù)據(jù)分組交換網(wǎng)絡(luò)中，數(shù)據(jù)分組在通過網(wǎng)絡(luò)時(shí)，在交換設(shè)備的緩沖區(qū)和隊(duì)列中移入和移出。實(shí)際上，數(shù)據(jù)分組交換網(wǎng)絡(luò)通常稱作“隊(duì)列網(wǎng)絡(luò)”。數(shù)據(jù)分組交換網(wǎng)絡(luò)的特征是數(shù)據(jù)分組可能從一個或多個源成群到達(dá)。緩沖區(qū)幫助路由器吸收突發(fā)數(shù)據(jù)分組，直到它們可以自己解決這些數(shù)據(jù)分組為止。如果業(yè)務(wù)流量過大，則緩沖區(qū)被占滿并且新來的數(shù)據(jù)分組被丟棄。增加緩沖區(qū)的大小不是解決辦法，因?yàn)檫^大的緩沖區(qū)會導(dǎo)致過大的延遲。

擁塞通常發(fā)生在多個鏈路向單個鏈路填入數(shù)據(jù)分組時(shí)，如內(nèi)部LAN被連接到WAN鏈路時(shí)。擁塞也發(fā)生在核心網(wǎng)絡(luò)的路由器上，其中節(jié)點(diǎn)承受的業(yè)務(wù)流量超過其設(shè)計(jì)所能處理的業(yè)務(wù)流量。TCP/IP網(wǎng)絡(luò)(如因特網(wǎng))尤其易于發(fā)生擁塞，因?yàn)槠渚哂谢镜臒o連接的性質(zhì)，虛電路的帶寬沒有保證。數(shù)據(jù)分組在任意時(shí)間由任意主機(jī)發(fā)送，并且這些數(shù)據(jù)分組大小可變，這就使得預(yù)測業(yè)務(wù)流量模式和提供有保證的服務(wù)變得不太可能。而無連接網(wǎng)絡(luò)也有優(yōu)點(diǎn)，除了服務(wù)質(zhì)量以外。

下列基本技術(shù)用于管理擁塞。

端系統(tǒng)流控制 這不是一個擁塞控制方案，而是一個阻止發(fā)送方使接收方緩沖區(qū)溢出的方法。流控制是由接收實(shí)體執(zhí)行的一種功能，用以限制傳輸實(shí)體所發(fā)送的數(shù)據(jù)量或速率。最簡單的流控制就是停止等待過程，此時(shí)在下一個PDU發(fā)送之前，所有PDU必須被確認(rèn)。效率更高的協(xié)議則涉及到向發(fā)送器提供的某種形式的信用關(guān)系，就是說在沒有收到確認(rèn)之前能夠發(fā)送的數(shù)據(jù)量。HDLC滑動窗口技術(shù)就是這種機(jī)制的一個例子。

網(wǎng)絡(luò)擁塞控制 網(wǎng)絡(luò)擁塞指的是在包交換網(wǎng)絡(luò)中由于傳送的包數(shù)目太多，而存貯轉(zhuǎn)發(fā)節(jié)點(diǎn)的資源有限而造成網(wǎng)絡(luò)傳輸性能下降的情況。擁塞的一種極端情況是死鎖（Deadlock），退出死鎖往往需要網(wǎng)絡(luò)復(fù)位操作。在本方案中，端系統(tǒng)減小流量以避免網(wǎng)絡(luò)擁塞。該機(jī)制類似于端對端流控制，但目的是減少網(wǎng)絡(luò)中而不是接收方的擁塞。

基于網(wǎng)絡(luò)的擁塞避免 在本方案中，路由器檢測可能發(fā)生的擁塞并嘗試在隊(duì)列變滿之前減慢發(fā)送方的發(fā)送。

資源分配 本技術(shù)包括安排物理電路或其他資源的使用，或許是對于某特定時(shí)間段。建立虛電路，以有保證的帶寬通過一系列交換機(jī)，是資源分配的一種形式。這種難度技術(shù)很大，但是可以通過阻止超過網(wǎng)絡(luò)容量的通信量來消除網(wǎng)絡(luò)擁塞。相關(guān)主題的列表在本主題結(jié)尾處給出。

高速緩存可能是最終的擁塞控制方案。通過將內(nèi)容移近用戶，大量的通信可以從本地獲得，而不必沿著可能發(fā)生擁塞的路由路徑從遠(yuǎn)程服務(wù)器上獲得。高速緩存成為因特網(wǎng)上的重要事務(wù)。

隊(duì)列和擁塞

任何關(guān)于擁塞的討論都要涉及到隊(duì)列。網(wǎng)絡(luò)上的緩沖區(qū)使用不同的隊(duì)列技術(shù)來管理。適當(dāng)?shù)墓芾黻?duì)列可以使丟失數(shù)據(jù)分組和網(wǎng)絡(luò)擁塞最小化，并改進(jìn)網(wǎng)絡(luò)性能。

最基本的技術(shù)是FIFO(先進(jìn)先出)，即按報(bào)文到達(dá)接口的先后順序讓報(bào)文進(jìn)入隊(duì)列，在隊(duì)列的出口讓報(bào)文按進(jìn)隊(duì)的順序出隊(duì)，先進(jìn)的報(bào)文將先出隊(duì)，后進(jìn)的報(bào)文將后出隊(duì)。此外，優(yōu)先級隊(duì)列方案使用具有不同優(yōu)先級的多個隊(duì)列，以便可以首先發(fā)送最重要的數(shù)據(jù)分組。

一項(xiàng)重要的隊(duì)列技術(shù)是將數(shù)據(jù)流分配到它們自己的隊(duì)列中。這樣區(qū)分?jǐn)?shù)據(jù)流的目的是分配不同的優(yōu)先級。同樣重要的是，每個數(shù)據(jù)流負(fù)責(zé)確保它不會溢出自己的隊(duì)列。這樣分離的隊(duì)列確保每個隊(duì)列只包含來自單個源的數(shù)據(jù)分組。

幀中繼中的擁塞控制

幀中繼用戶與服務(wù)提供商協(xié)商CIR(保證信息速率)。CIR是保證的服務(wù)級別，但如果網(wǎng)絡(luò)容量允許，則提供商通常允許用戶超出這一級別的突發(fā)數(shù)據(jù)。然而，超出CIR的幀被標(biāo)記為可丟棄的。如果網(wǎng)絡(luò)上的交換機(jī)發(fā)生擁塞，則它將丟失可丟棄的幀。這就確保服務(wù)提供商可以滿足與用戶協(xié)商的CIR級別。

丟棄幀決不是個好辦法，所以有兩個擁塞避免機(jī)制可用:

BECN(反向顯式擁塞通知) 幀中繼網(wǎng)絡(luò)在與數(shù)據(jù)幀遇到擁塞路徑的反方向傳輸?shù)臄?shù)據(jù)幀中設(shè)置的位。交換機(jī)開始發(fā)生擁塞(如緩沖區(qū)/隊(duì)列已滿)時(shí)，它可以用BECN位組將一個幀反向發(fā)送回發(fā)送方，以通知發(fā)送方減速。

FECN(正向顯式擁塞通知) 是由來源（發(fā)送）終端傳輸?shù)囊竽康牡兀ń邮眨┙K端減緩數(shù)據(jù)要求的請求的首位。交換機(jī)開始擁塞時(shí)，它可以用FECN位組將一個幀正向發(fā)送到接收節(jié)點(diǎn)。這就通知接收節(jié)點(diǎn)：應(yīng)該通知發(fā)送方減速。

發(fā)送方或接收方不必響應(yīng)BECN或FECN，但最終網(wǎng)絡(luò)交換機(jī)將由于擁塞繼續(xù)增長而丟失幀。

TCP中的擁塞控制和避免

直到20世紀(jì)80年代中期，因特網(wǎng)有出現(xiàn)“擁塞崩潰”的傾向。發(fā)生這種現(xiàn)象是因?yàn)閷τ诠芾泶罅康木W(wǎng)絡(luò)負(fù)載缺乏控制。個別連接在發(fā)送方和接收方之間使用數(shù)據(jù)流控制，以防止發(fā)送方發(fā)送太多以至接收方無法處理。

但是這些早期的數(shù)據(jù)流控制的設(shè)計(jì)，是為防止接收方的緩沖區(qū)溢出而不是網(wǎng)絡(luò)節(jié)點(diǎn)的緩沖區(qū)的溢出。然而，早期的因特網(wǎng)包含大量相對較慢的鏈路，所以擁塞問題不象現(xiàn)今這樣嚴(yán)重。

在20世紀(jì)80年代末期，Van Jacobson提出了擁塞控制機(jī)制，使TCP響應(yīng)網(wǎng)絡(luò)中的擁塞。基本“信號”是丟棄的數(shù)據(jù)分組，它使主機(jī)停止或減速。

通常，當(dāng)主機(jī)接收一個數(shù)據(jù)分組(或一組數(shù)據(jù)分組)時(shí)，它發(fā)送ACK(確認(rèn))給發(fā)送方。窗口機(jī)制允許主機(jī)發(fā)送多個數(shù)據(jù)分組，而只有單個ACK。接收ACK失敗表明，接收主機(jī)溢出或者網(wǎng)絡(luò)擁塞。在任一種情況下，發(fā)送方都減少或停止發(fā)送。

一個稱為加法增加/乘法減少的策略管理一次發(fā)送的數(shù)據(jù)分組的數(shù)目。如果將數(shù)據(jù)流繪成圖表，將可看到鋸齒狀形式，其中，數(shù)據(jù)分組數(shù)目增加(加法增加)，直到擁塞發(fā)生為止，然后當(dāng)開始丟棄數(shù)據(jù)分組時(shí)減少(乘法減少)。窗口大小通常在擁塞信號出現(xiàn)時(shí)減半。

主機(jī)所做的是通過不斷以某個較高的速率測試網(wǎng)絡(luò)，以找到最佳傳輸速率。有時(shí)，允許較高的傳輸速率，但是如果網(wǎng)絡(luò)正忙，開始丟失數(shù)據(jù)分組，則主機(jī)相應(yīng)的降低速率。這一方案將網(wǎng)絡(luò)看成是發(fā)生擁塞時(shí)丟棄數(shù)據(jù)分組的“黑盒子”。因此，擁塞控制由端系統(tǒng)運(yùn)行，端系統(tǒng)將丟失數(shù)據(jù)分組看成是惟一的網(wǎng)絡(luò)擁塞表示。

正在傳輸大文件的發(fā)送方將盡量爭取更高的速率，直到最后它占用全部帶寬。其他主機(jī)的數(shù)據(jù)分組在通過時(shí)可能遇到麻煩。經(jīng)常是，已占用帶寬的主機(jī)正在進(jìn)行最不重要的通信。這樣的后果對于話音之類的實(shí)時(shí)通信尤其具有破壞性。即使一個鏈路具有足夠的帶寬處理它的負(fù)載，但性能不良的主機(jī)還是會使該鏈路飽和(盡管是暫時(shí)的)，以至于破壞話音通信，使用戶無法通話。

當(dāng)然，在管理擁塞時(shí)網(wǎng)絡(luò)會起到積極的作用，那就是“主動式隊(duì)列管理”和擁塞避免開始發(fā)揮作用。RFC l254(Gateway Congestion Control Survey， August l991)描述了IETF性能和擁塞控制工作組審查的擁塞控制和避免機(jī)制。該工作組將擁塞處理分成下列：

擁塞恢復(fù) 當(dāng)需求超過容量時(shí)，恢復(fù)網(wǎng)絡(luò)的操作狀態(tài)。

擁塞避免 預(yù)見擁塞并避免它，從而永遠(yuǎn)不發(fā)生擁塞。

RFC 1254指出，若沒有擁塞恢復(fù)，因特網(wǎng)將停止操作，但沒有擁塞避免，它卻已經(jīng)工作了很長時(shí)間。現(xiàn)今，擁塞避免是改進(jìn)因特網(wǎng)的性能和服務(wù)質(zhì)量的重要方法。

RFC 2309(Recommendations on Queue Management and Congestion Avoidance in the Internet ，April 1998)指出，用于控制擁塞的基于路由器的機(jī)制可以劃分為“隊(duì)列管理”算法和“調(diào)度”算法。有關(guān)擁塞控制、擁塞避免方案和隊(duì)列調(diào)度技術(shù)的有用信息，請參閱本RFC。

一個重要的目標(biāo)是使丟失數(shù)據(jù)分組的數(shù)目最小化。如果主機(jī)正在以高速傳輸并且網(wǎng)絡(luò)發(fā)生擁塞，則將丟失大量的數(shù)據(jù)分組。擁塞避免試圖在不限制網(wǎng)絡(luò)吞吐量的情況下防止數(shù)據(jù)丟失。RFC 2309指出，最好接受突發(fā)使隊(duì)列溢出這一事實(shí)，而不是試圖將隊(duì)列維持在未滿狀態(tài)。這將從根本上變得有利于高吞吐量時(shí)較低的端對端延遲。RFC還給出這樣的注釋:網(wǎng)絡(luò)中的緩沖區(qū)吸收數(shù)據(jù)突發(fā)，并在隨后有希望出現(xiàn)的突發(fā)空閑期間傳輸它們。這是允許傳輸突發(fā)數(shù)據(jù)的本質(zhì)所在。我們希望路由器中含有正常的小隊(duì)列的原因很清楚：希望有吸收突發(fā)數(shù)據(jù)的隊(duì)列容量。與直覺相反的結(jié)果是，維持正常的小隊(duì)列會導(dǎo)致較高的吞吐量，以及較低的端對端延遲。總之，隊(duì)列限制不應(yīng)該反映我們希望在網(wǎng)絡(luò)中維持的穩(wěn)定狀態(tài)的隊(duì)列，相反，它們應(yīng)該反映我們要吸收的突發(fā)數(shù)據(jù)的多少。

突發(fā)數(shù)據(jù)會破壞多臺主機(jī)。如果單個主機(jī)填充正由多個主機(jī)使用的隊(duì)列，則所有主機(jī)將需要后退。這導(dǎo)致網(wǎng)絡(luò)在一段時(shí)期內(nèi)未充分使用，因?yàn)橹鳈C(jī)正在以較低的速率發(fā)送數(shù)據(jù)分組。但是最終，出于重新傳輸丟棄的數(shù)據(jù)分組的需要，它們開始建立備份。然后發(fā)生的是，已經(jīng)后退的所有主機(jī)試圖在大約同一時(shí)間重新發(fā)送，這將再次導(dǎo)致?lián)砣麪顟B(tài)。這被稱為“全局同步”問題。

應(yīng)當(dāng)記住，TCP處理擁塞控制。UDP通常用于實(shí)時(shí)音頻和視頻流，因?yàn)椴恍枰謴?fù)丟失的數(shù)據(jù)分組。UDP是不可靠的傳輸協(xié)議，不能將ACK信號發(fā)送回?cái)?shù)據(jù)源。由于沒有ACK，因此無法用傳統(tǒng)的TCP擁塞控制來控制UDP流。

Lawrence G. Roberts，這位因特網(wǎng)的早期創(chuàng)建者，在1997年發(fā)表的名為《Explicit Rate Flow Control，A100 Fold Improvement over TCP》的論文中，對TCP和它的擁塞控制方案進(jìn)行了有趣的評論。他認(rèn)為：只要TCP僅在終端站中運(yùn)行，就無法從本質(zhì)上改進(jìn)它的操作。如果不取代TCP，在像因特網(wǎng)這樣的長距離網(wǎng)絡(luò)上，TCP將導(dǎo)致重大的超載和中斷。TCP固有的慢啟動速度和高延遲變差會嚴(yán)重影響用戶。IETF甚至沒有考慮修訂TCP，實(shí)際上，IETF沒有進(jìn)行關(guān)于流控制的任何研究，因?yàn)樗坪趺總€人都相信“如果它在過去能工作，則它將能繼續(xù)工作”。必須盡可能快地用與顯式速率流控制一樣好的新的流控制來代替TCP。

RFC 2581(TCP Congestion Control，APnll999)定義了TCP的四個相關(guān)的擁塞控制算法：慢速啟動、擁塞避免、快速重發(fā)和快速恢復(fù)。下面介紹每個算法。

慢速啟動和擁塞避免算法必須被TCP發(fā)送端用來控制正在向網(wǎng)絡(luò)傳送的數(shù)據(jù)量。為了實(shí)現(xiàn)這些算法，必須向TCP每個連接狀態(tài)加入兩個參量。擁塞窗口（cwnd）是對發(fā)送端收到確認(rèn)（ACK）之前能向網(wǎng)絡(luò)傳送的最大數(shù)據(jù)量的一個發(fā)送端限制，接收端通知窗口（rwnd）是對未完成數(shù)據(jù)量的接收端限制。Cwnd和rwnd的最小值決定了數(shù)據(jù)傳送。另一個狀態(tài)參量是慢啟動閥值（ssthresh），被用來確定是用慢速啟動還是用擁塞避免算法來控制數(shù)據(jù)傳送。

慢速啟動擁塞控制當(dāng)主機(jī)首次傳輸時(shí)，慢啟動可減少突發(fā)影響。它要求主機(jī)緩慢的開始傳輸，然后增大到擁塞開始發(fā)生。主機(jī)最初并不知道它可以發(fā)送的數(shù)據(jù)分組的數(shù)目，所以它使用慢速啟動的方式測量網(wǎng)絡(luò)容量。主機(jī)通過將兩個數(shù)據(jù)分組發(fā)送到接收方開始傳輸。當(dāng)接收方接收到該段數(shù)據(jù)，它返回ACK(確認(rèn))作為確認(rèn)。發(fā)送方將窗口增加到兩個并發(fā)送四個數(shù)據(jù)分組。隨著發(fā)送方加倍發(fā)送數(shù)據(jù)分組，發(fā)送量繼續(xù)增加，直到接收不到ACK為止，這表明數(shù)據(jù)流到達(dá)了網(wǎng)絡(luò)處理通信的能力極限或者接收方處理接收通信的能力極限。

慢速啟動并不防止擁塞，它只是阻止主機(jī)立即進(jìn)入擁塞狀態(tài)。如果主機(jī)正在發(fā)送一個大文件，最終它將到達(dá)使網(wǎng)絡(luò)超載并開始丟失數(shù)據(jù)分組的狀態(tài)。慢速啟動在避免擁塞崩潰問題上很關(guān)鍵。但新的應(yīng)用程序，如IP上的話音，不能容忍慢速啟動導(dǎo)致的延遲，某些情況下，禁用慢速啟動，所以用戶可以“搶占”帶寬。這種趨勢只會導(dǎo)致問題的出現(xiàn)。

快速重發(fā)和快速恢復(fù)(Reno) 快速重發(fā)和快速恢復(fù)是為丟失數(shù)據(jù)分組對網(wǎng)絡(luò)吞吐量所造成的影響最小化而設(shè)計(jì)的算法。快速重發(fā)機(jī)制從另一個TCP機(jī)制推斷信息，接收方使用該機(jī)制將其已經(jīng)收到失序數(shù)據(jù)分組的信號發(fā)送到發(fā)送方。該技術(shù)是將幾個重復(fù)的ACK發(fā)送到發(fā)送方。

快速重發(fā)通過假設(shè)重復(fù)的ACK表示丟失數(shù)據(jù)分組來利用這一功能。這種方法不是等待ACK直到計(jì)時(shí)器終止，而是如果收到三個這樣的重復(fù)ACK，數(shù)據(jù)源將重新發(fā)送數(shù)據(jù)分組。這發(fā)生在超時(shí)之前，從而提高了網(wǎng)絡(luò)吞吐量。例如，如果主機(jī)接收到數(shù)據(jù)分組5和7，但沒有6，它將在它收到數(shù)據(jù)分組7(但沒有數(shù)據(jù)分組6)時(shí)發(fā)送對于數(shù)據(jù)分組5的重復(fù)ACK。

在快速重發(fā)算法發(fā)送了看來已經(jīng)丟失的數(shù)據(jù)段之后，“快速恢復(fù)”算法支配了新數(shù)據(jù)的傳送，直到一個非重復(fù)ACK到達(dá)。不進(jìn)行慢啟動的原因是收到重復(fù)ACK不僅意味著一個數(shù)據(jù)段已經(jīng)丟失，而且意味著數(shù)據(jù)段非常可能從網(wǎng)絡(luò)丟失（盡管網(wǎng)絡(luò)產(chǎn)生大量的重復(fù)數(shù)據(jù)段可以保證不丟失）。換句話說，因?yàn)榻邮斩酥挥性诋?dāng)一個數(shù)據(jù)段已經(jīng)到達(dá)時(shí)才產(chǎn)生一個重復(fù)ACK，由此我們可以知道，已經(jīng)脫離網(wǎng)絡(luò)，存儲在接收端的緩沖區(qū)里的數(shù)據(jù)段不會再消耗網(wǎng)絡(luò)資源。另外，因?yàn)锳CK"clock"保存起來了，TCP發(fā)送端可以繼續(xù)發(fā)送新的數(shù)據(jù)段（盡管傳送必須繼續(xù)使用一個減小的cwnd）。

快速恢復(fù)是當(dāng)使用快速重發(fā)時(shí)代替慢速啟動的機(jī)制。注意，盡管重復(fù)ACK表示已經(jīng)丟失一段數(shù)據(jù)，但它也表示既然數(shù)據(jù)源收到序列號高于丟失的數(shù)據(jù)分組的數(shù)據(jù)分組，則數(shù)據(jù)分組仍在流動。在這種情況下，假設(shè)單個數(shù)據(jù)分組已經(jīng)丟失，網(wǎng)絡(luò)沒有完全擁塞，因此，發(fā)送方不需要完全降低到慢速啟動模式，而是降低到先前速度的一半。

注意，上述機(jī)制稱為Reno。RFC 258 (The NewReno Modification to TCP’s Fast Recovery Algorithm，April 1999)描述了對Reno的修改，使其可以覆蓋這種情況，即ACK在檢測到數(shù)據(jù)丟失時(shí)不能覆蓋全部未解決的數(shù)據(jù)的情況。主動隊(duì)列管理和擁塞避免丟失數(shù)據(jù)分組使效率降低。如果主機(jī)遇到突發(fā)傳輸和擁塞，將丟失大量數(shù)據(jù)分組。因此，檢測即將發(fā)生的擁塞情況并在擁塞失控之前積極進(jìn)行管理是很有用的。

主動隊(duì)列管理是這樣一項(xiàng)技術(shù)，路由器主動從隊(duì)列中丟失數(shù)據(jù)分組，作為通知發(fā)送方應(yīng)該減速的信號。RFC 2309列出了主動隊(duì)列管理的下列優(yōu)點(diǎn):

突發(fā)是不可避免的。保留較小的隊(duì)列并主動管理隊(duì)列提高了路由器吸收突發(fā)數(shù)據(jù)分組和不丟失過多數(shù)據(jù)分組的能力。

如果數(shù)據(jù)源使共享隊(duì)列溢出，則共享該隊(duì)列的所有設(shè)備將減速(“全局同步”問題)。

從多個丟失的數(shù)據(jù)分組中恢復(fù)要比從單個丟失的數(shù)據(jù)分組中恢復(fù)更困難。

大隊(duì)列可能導(dǎo)致延遲。主動隊(duì)列管理允許隊(duì)列比較小，這將提高吞吐量。

當(dāng)主機(jī)填滿隊(duì)列并且防止其他主機(jī)使用該隊(duì)列時(shí)，發(fā)生封鎖。主動隊(duì)列管理可以防止這種情況發(fā)生。

下面描述幾個擁塞避免方案。超越這些技術(shù)的下一步包括業(yè)務(wù)流量調(diào)整、資源預(yù)留、虛電路和QoS技術(shù)。后面還將做更多討論。

RED(隨機(jī)早期丟棄) RED是主動隊(duì)列管理方案，為擁塞避免提供一種機(jī)制。

與丟失已滿隊(duì)列末尾的數(shù)據(jù)分組的傳統(tǒng)擁塞控制方案不同，RED使用統(tǒng)計(jì)方法，在隊(duì)列溢出之前以“隨機(jī)”方式丟棄數(shù)據(jù)分組。以這種方式丟棄數(shù)據(jù)分組會將數(shù)據(jù)源的速度降到足夠低，以至于當(dāng)隊(duì)列溢出以及主機(jī)正以高速率傳輸時(shí)，可以保持隊(duì)列穩(wěn)定并減少丟失的數(shù)據(jù)分組數(shù)。

RED作出了兩個重要決定。它決定何時(shí)丟棄數(shù)據(jù)分組和丟棄哪些數(shù)據(jù)分組。RED跟蹤平均隊(duì)列大小，并且當(dāng)平均隊(duì)列大小超過已定義的極限值時(shí)丟棄數(shù)據(jù)分組。每當(dāng)新數(shù)據(jù)分組到達(dá)隊(duì)列時(shí)，重新計(jì)算隊(duì)列的平均值。RED有兩個和隊(duì)列長度相關(guān)的閾值：minth和maxth。RED根據(jù)minth和maxth作出丟棄數(shù)據(jù)分組的決定：

最小極限值(minth) 規(guī)定一個在該值以下將不丟棄任何數(shù)據(jù)分組的平均隊(duì)列大小。

最大極限值(maxth) 規(guī)定一個在該值以上將丟棄所有數(shù)據(jù)分組的平均隊(duì)列大小。

當(dāng)有包達(dá)到路由器時(shí)，RED計(jì)算出平均隊(duì)長avgQ。若avgQ小于minth，則沒有包需要丟棄；當(dāng)minth≤avgQ≤maxth時(shí)，計(jì)算出概率P，并以此概率丟棄包；當(dāng)avgQ>maxth時(shí)，所有的包都被丟棄。由于RED使用的是基于時(shí)間的平均隊(duì)長，就有可能會發(fā)生實(shí)際隊(duì)長大于平均隊(duì)長的情況，如果隊(duì)列已滿，則到達(dá)的包只能被丟棄。

計(jì)算概率P的方法如下：

　　Pb = maxp×(avgQ-minth) / (maxth-minth) 　　P = Pb / (1-count×Pb)

P不僅和avgQ有關(guān)，而且還和從上一次丟包開始到現(xiàn)在進(jìn)入隊(duì)列的包的數(shù)量count有關(guān)。隨著count的增加，下一個包被丟棄的可能性也在緩慢增加。這主要是為了在到來的包之間均勻間隔地丟包，避免連續(xù)丟包，從而避免對突發(fā)流的偏見和產(chǎn)生全局同步現(xiàn)象。

RED使用時(shí)間平均法，即如果最近隊(duì)列通常是空的，則RED將不會像對主要擁塞事件那樣對付意外突發(fā)。然而，如果隊(duì)列保持接近全滿的狀態(tài)，則RED將假設(shè)擁塞并開始以較高的速率丟棄數(shù)據(jù)分組。

RFC 2309論述到因特網(wǎng)上的主動隊(duì)列管理機(jī)制具有大量的性能優(yōu)點(diǎn)并且使用RED算法似乎沒有缺點(diǎn)。

WRED(加權(quán)RED)是基于通信類型、通信目的地或其他因素決定丟棄數(shù)據(jù)分組的技術(shù)。WRED也根據(jù)網(wǎng)絡(luò)外數(shù)據(jù)分組的標(biāo)記丟棄數(shù)據(jù)分組。

ECN(顯式擁塞通知) 在RED機(jī)制中，當(dāng)平均隊(duì)長超過一定的閾值時(shí)便開始丟包了，也就是說RED是在隊(duì)列未滿的情況下丟包的，并不是由于隊(duì)列溢出而被迫丟包的。在這種情況下丟包，雖然使得RED有效地管理了平均隊(duì)長，但也浪費(fèi)了網(wǎng)絡(luò)資源，并且對時(shí)延有一定要求地多媒體應(yīng)用不是很理想。更有效的技術(shù)是路由器在數(shù)據(jù)分組中設(shè)置擁塞通知位，再將該數(shù)據(jù)分組發(fā)送到接收方。然后，接收方可以通過ACK中的消息通知發(fā)送方減速。這樣接收方將一直收到它的數(shù)據(jù)分組，而且可以避免使用數(shù)據(jù)分組丟棄的方法來發(fā)送擁塞信號。

ECN是采用了這項(xiàng)技術(shù)的端對端擁塞避免機(jī)制。正如其名稱所暗示的那樣，ECN提供直接的擁塞通知，而不是通過丟棄數(shù)據(jù)分組間接發(fā)送擁塞信號。ECN在中等程度的擁塞時(shí)起作用。當(dāng)擁塞過分嚴(yán)重時(shí)，就采用數(shù)據(jù)分組丟棄技術(shù)。

　ECN需要在IP包頭設(shè)置一個兩位（bit）的ECN域，一個是ECT（ECN-Capable Transport）位，由源端設(shè)置以顯示源端節(jié)點(diǎn)的傳輸協(xié)議是支持ECN的；另一個是CE（ Congestion Experienced ）位，由路由器設(shè)置，以顯示是否發(fā)生了擁塞。

當(dāng)隊(duì)列長度超過某個極限值時(shí)，啟用ECN的路由器在來自可用ECN的主機(jī)的數(shù)據(jù)分組的包頭中設(shè)置CD(遭遇擁塞)位。數(shù)據(jù)分組轉(zhuǎn)發(fā)給接收方，然后接收方向發(fā)送方發(fā)送一個包含擁塞指示符的ACK。這個ACK稱為ECN-Echo。當(dāng)發(fā)送方收到這個顯式信號時(shí)，它將發(fā)送數(shù)據(jù)分組的速率降低到原來的一半。

注意，ECN要求修改TCP。在RFC 2481(Aproposal ADD Explicit Congestion Notification to IP，January 1999)中描述ECN。

TCP速率控制 TCP速率控制是這樣一項(xiàng)技術(shù)，端點(diǎn)可以根據(jù)那些執(zhí)行速率控制的網(wǎng)絡(luò)設(shè)備的反饋來調(diào)整自己的傳輸。

TCP速率控制也稱為ERC(顯式速率控制)。ERC的一種形式在ATM網(wǎng)絡(luò)中使用。

Packeteer公司的PacketShaper保存關(guān)于各個TCP連接的狀態(tài)信息。這允許它將反饋發(fā)送到控制其性能的數(shù)據(jù)源。主要目的是通過平滑數(shù)據(jù)源的傳輸速率控制突發(fā)。隨著突發(fā)的減少，業(yè)務(wù)流量管理變得更容易。

在端系統(tǒng)間的網(wǎng)絡(luò)內(nèi)執(zhí)行速率控制進(jìn)程。PacketShaper截獲來自接收方的ACK并保留一段時(shí)間，這段時(shí)間經(jīng)過精確計(jì)算，以便發(fā)送方可以用消除突發(fā)的方式傳輸它的下一個數(shù)據(jù)分組。

例如，數(shù)據(jù)源將數(shù)據(jù)分組發(fā)送到接收方。接收方將ACK返回到發(fā)送方。PacketShaper截獲ACK并更改某些內(nèi)部設(shè)置，如TCP窗口的大小。恰好這時(shí)，PacketShaper發(fā)送數(shù)據(jù)分組和數(shù)據(jù)分組的內(nèi)容(ACK序號加上窗口大小)并通知發(fā)送方該傳輸另一個數(shù)據(jù)分組了。

結(jié)果是，來自源的數(shù)據(jù)分組穩(wěn)定流動，并改進(jìn)了資源管理。不利方面是路由器必須主動跟蹤每個數(shù)據(jù)流。此外，更改傳輸中的數(shù)據(jù)分組的內(nèi)容不是個好方法，這取決于網(wǎng)絡(luò)。通信量管理和QoS設(shè)備執(zhí)行TCP速率控制。

其他方案

上面描述的大多數(shù)方案是隊(duì)列管理方案。如果希望使用這些方案之外的解決方法來管理網(wǎng)絡(luò)業(yè)務(wù)流量，則需要考慮優(yōu)先權(quán)方案、數(shù)據(jù)分組標(biāo)記方案、虛電路方案和QoS方案。

擁塞管理資源

SallyFloyd的Web站點(diǎn)是有關(guān)擁塞控制，尤其是擁塞避免的信息的最佳來源之一。IETF端點(diǎn)擁塞管理(ecm)工作組具有有關(guān)新?lián)砣刂品桨傅男畔⒑驮u價(jià)當(dāng)前的擁塞控制方案的文檔。SallyFloyd撰寫了RFC 2914 ( Congestion Control Principles， September2000)。IETF Transport Area (傳輸區(qū)域)工作組(tsvwg)正在制訂新的傳輸規(guī)范。