擁塞控制機制是什么意思

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

在數據分組交換網絡中，數據分組在通過網絡時，在交換設備的緩沖區和隊列中移入和移出。實際上，數據分組交換網絡通常稱作“隊列網絡”。數據分組交換網絡的特征是數據分組可能從一個或多個源成群到達。緩沖區幫助路由器吸收突發數據分組，直到它們可以自己解決這些數據分組為止。如果業務流量過大，則緩沖區被占滿并且新來的數據分組被丟棄。增加緩沖區的大小不是解決辦法，因為過大的緩沖區會導致過大的延遲。

擁塞通常發生在多個鏈路向單個鏈路填入數據分組時，如內部LAN被連接到WAN鏈路時。擁塞也發生在核心網絡的路由器上，其中節點承受的業務流量超過其設計所能處理的業務流量。TCP/IP網絡(如因特網)尤其易于發生擁塞，因為其具有基本的無連接的性質，虛電路的帶寬沒有保證。數據分組在任意時間由任意主機發送，并且這些數據分組大小可變，這就使得預測業務流量模式和提供有保證的服務變得不太可能。而無連接網絡也有優點，除了服務質量以外。

下列基本技術用于管理擁塞。

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

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

基于網絡的擁塞避免 在本方案中，路由器檢測可能發生的擁塞并嘗試在隊列變滿之前減慢發送方的發送。

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

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

隊列和擁塞

任何關于擁塞的討論都要涉及到隊列。網絡上的緩沖區使用不同的隊列技術來管理。適當的管理隊列可以使丟失數據分組和網絡擁塞最小化，并改進網絡性能。

最基本的技術是FIFO(先進先出)，即按報文到達接口的先后順序讓報文進入隊列，在隊列的出口讓報文按進隊的順序出隊，先進的報文將先出隊，后進的報文將后出隊。此外，優先級隊列方案使用具有不同優先級的多個隊列，以便可以首先發送最重要的數據分組。

一項重要的隊列技術是將數據流分配到它們自己的隊列中。這樣區分數據流的目的是分配不同的優先級。同樣重要的是，每個數據流負責確保它不會溢出自己的隊列。這樣分離的隊列確保每個隊列只包含來自單個源的數據分組。

幀中繼中的擁塞控制

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

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

BECN(反向顯式擁塞通知) 幀中繼網絡在與數據幀遇到擁塞路徑的反方向傳輸的數據幀中設置的位。交換機開始發生擁塞(如緩沖區/隊列已滿)時，它可以用BECN位組將一個幀反向發送回發送方，以通知發送方減速。

FECN(正向顯式擁塞通知) 是由來源（發送）終端傳輸的要求目的地（接收）終端減緩數據要求的請求的首位。交換機開始擁塞時，它可以用FECN位組將一個幀正向發送到接收節點。這就通知接收節點：應該通知發送方減速。

發送方或接收方不必響應BECN或FECN，但最終網絡交換機將由于擁塞繼續增長而丟失幀。

TCP中的擁塞控制和避免

直到20世紀80年代中期，因特網有出現“擁塞崩潰”的傾向。發生這種現象是因為對于管理大量的網絡負載缺乏控制。個別連接在發送方和接收方之間使用數據流控制，以防止發送方發送太多以至接收方無法處理。

但是這些早期的數據流控制的設計，是為防止接收方的緩沖區溢出而不是網絡節點的緩沖區的溢出。然而，早期的因特網包含大量相對較慢的鏈路，所以擁塞問題不象現今這樣嚴重。

在20世紀80年代末期，Van Jacobson提出了擁塞控制機制，使TCP響應網絡中的擁塞。基本“信號”是丟棄的數據分組，它使主機停止或減速。

通常，當主機接收一個數據分組(或一組數據分組)時，它發送ACK(確認)給發送方。窗口機制允許主機發送多個數據分組，而只有單個ACK。接收ACK失敗表明，接收主機溢出或者網絡擁塞。在任一種情況下，發送方都減少或停止發送。

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

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

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

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

擁塞恢復 當需求超過容量時，恢復網絡的操作狀態。

擁塞避免 預見擁塞并避免它，從而永遠不發生擁塞。

RFC 1254指出，若沒有擁塞恢復，因特網將停止操作，但沒有擁塞避免，它卻已經工作了很長時間。現今，擁塞避免是改進因特網的性能和服務質量的重要方法。

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

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

突發數據會破壞多臺主機。如果單個主機填充正由多個主機使用的隊列，則所有主機將需要后退。這導致網絡在一段時期內未充分使用，因為主機正在以較低的速率發送數據分組。但是最終，出于重新傳輸丟棄的數據分組的需要，它們開始建立備份。然后發生的是，已經后退的所有主機試圖在大約同一時間重新發送，這將再次導致擁塞狀態。這被稱為“全局同步”問題。

應當記住，TCP處理擁塞控制。UDP通常用于實時音頻和視頻流，因為不需要恢復丟失的數據分組。UDP是不可靠的傳輸協議，不能將ACK信號發送回數據源。由于沒有ACK，因此無法用傳統的TCP擁塞控制來控制UDP流。

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

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

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

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

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

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

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

在快速重發算法發送了看來已經丟失的數據段之后，“快速恢復”算法支配了新數據的傳送，直到一個非重復ACK到達。不進行慢啟動的原因是收到重復ACK不僅意味著一個數據段已經丟失，而且意味著數據段非常可能從網絡丟失（盡管網絡產生大量的重復數據段可以保證不丟失）。換句話說，因為接收端只有在當一個數據段已經到達時才產生一個重復ACK，由此我們可以知道，已經脫離網絡，存儲在接收端的緩沖區里的數據段不會再消耗網絡資源。另外，因為ACK"clock"保存起來了，TCP發送端可以繼續發送新的數據段（盡管傳送必須繼續使用一個減小的cwnd）。

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

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

主動隊列管理是這樣一項技術，路由器主動從隊列中丟失數據分組，作為通知發送方應該減速的信號。RFC 2309列出了主動隊列管理的下列優點:

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

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

從多個丟失的數據分組中恢復要比從單個丟失的數據分組中恢復更困難。

大隊列可能導致延遲。主動隊列管理允許隊列比較小，這將提高吞吐量。

當主機填滿隊列并且防止其他主機使用該隊列時，發生封鎖。主動隊列管理可以防止這種情況發生。

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

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

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

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

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

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

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

計算概率P的方法如下：

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

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

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

RFC 2309論述到因特網上的主動隊列管理機制具有大量的性能優點并且使用RED算法似乎沒有缺點。

WRED(加權RED)是基于通信類型、通信目的地或其他因素決定丟棄數據分組的技術。WRED也根據網絡外數據分組的標記丟棄數據分組。

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

ECN是采用了這項技術的端對端擁塞避免機制。正如其名稱所暗示的那樣，ECN提供直接的擁塞通知，而不是通過丟棄數據分組間接發送擁塞信號。ECN在中等程度的擁塞時起作用。當擁塞過分嚴重時，就采用數據分組丟棄技術。

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

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

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

TCP速率控制 TCP速率控制是這樣一項技術，端點可以根據那些執行速率控制的網絡設備的反饋來調整自己的傳輸。

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

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

在端系統間的網絡內執行速率控制進程。PacketShaper截獲來自接收方的ACK并保留一段時間，這段時間經過精確計算，以便發送方可以用消除突發的方式傳輸它的下一個數據分組。

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

結果是，來自源的數據分組穩定流動，并改進了資源管理。不利方面是路由器必須主動跟蹤每個數據流。此外，更改傳輸中的數據分組的內容不是個好方法，這取決于網絡。通信量管理和QoS設備執行TCP速率控制。

其他方案

上面描述的大多數方案是隊列管理方案。如果希望使用這些方案之外的解決方法來管理網絡業務流量，則需要考慮優先權方案、數據分組標記方案、虛電路方案和QoS方案。

擁塞管理資源

SallyFloyd的Web站點是有關擁塞控制，尤其是擁塞避免的信息的最佳來源之一。IETF端點擁塞管理(ecm)工作組具有有關新擁塞控制方案的信息和評價當前的擁塞控制方案的文檔。SallyFloyd撰寫了RFC 2914 ( Congestion Control Principles， September2000)。IETF Transport Area (傳輸區域)工作組(tsvwg)正在制訂新的傳輸規范。