計算機網路之TCP可靠傳輸

一、可靠傳輸的工作原理

由於計算機網路是分層的，TCP傳送的報文段是交給網路層的IP協議處理的。但是IP只能提供"最大努力服務"，也就是說下層的網路提供的是不可靠傳輸，因此TCP必須採取一些措施保證可靠傳輸。

當傳輸過程中分組出現差錯（檢驗和）時，應當讓傳送方重新傳送分組；當網路狀況不好或者接收方來不及接收分組時，應當適當降低傳送速率（流量控制和擁塞控制）。

1.1 停止等待協議

簡單的停止等待協議，即傳送方每傳送一個分組就等待確認，收到接收方的確認後在傳送下一個分組。




當傳輸的分組出現差錯，接收方就丟棄這個分組。或者分組在傳輸過程中丟失了，接收方同樣丟棄這個分組。傳送方在每傳送一個分組時需要設定一個超時計時器。如果經過一段時間還沒有收到確認，傳送方就認為分組丟失了，於是自動重傳分組。如果在超時時間收到了確認，那麼就撤銷計時器。

傳送方在傳送分組後，必須要保留分組的副本（便於重傳）；以及必須對分組進行編號，這樣才能明確傳送的是哪一個分組，確認又是對哪個分組的確認。

如果傳輸的分組是正確的，接收方就向傳送方傳送確認。如果確認在傳輸過程中丟失了，或者遲到了，這時由於傳送方沒有在超時時間內收到確認，會進行重傳。接收方在收到重複的分組需要採取的行動，丟棄分組但需要"重傳確認"。而如果確認在超時時間後到達了傳送方，也就是確認遲到了，那麼傳送方就可能收到多個確認，這時傳送方就簡單的丟棄重複的確認。




從傳送方和接收方分別觀察一下。傳送方執行的動作：收到確認時傳送下一個分組、超時重傳分組、收到重複確認就簡單丟棄。接收方執行的動作：接收分組錯誤就簡單丟棄、接收分組正確併傳送確認、收到重複分組就丟棄分組但傳送確認。

通常傳送方總是可以收到對所有分組的確認。如果傳送方遲遲收不到確認，那就說明通訊鏈路出現了問題。
上述的傳輸機制也稱為自動重傳請求（ARQ, Automatic Repeat reQuest)。傳送方自動重傳分組，而不需要接收方請求重傳。

停止等待協議的優點是簡單，但缺點是通道利用率太低。假定傳送方傳送分組的時間為Ts，接收方傳送確認的時間為Tr，一個分組的往返時間為RTT。那麼通道利用率為Ts/(Ts+RTT+Tr)。

為了提高效率，傳送方可以採用流水線方式連續傳送分組，這樣就可以提高通道利用率。

1.2 連續ARQ協議

簡單的滑動視窗協議。傳送方維持一個傳送視窗，傳送視窗裡的分組可以連續傳送出去，而不需要等待確認。




每收到一個確認時，就將傳送視窗向前移動。而接收方一般採用累積確認的方式，不必對每個分組都傳送確認，而是對按序到達的最後一個分組傳送確認，這樣就表示這個分組和之前的分組已經全部收到了。累積確認的優點是容易實現，減少了接收方傳送確認的數量。但缺點是不能正確反映已經收到的所有分組的資訊。如果接受方按序收到1，2，4，5四個分組，那麼只能對2進行確認。傳送方不知道後面三個分組的下落，只好重傳，也就是Go-back-N，需要回退回來重傳這N個分組。當通訊線路不好時，連續ARQ協議會帶來負面效果，使傳輸效率降低。

二、TCP報文段的首部格式

TCP的全部功能都表現在報文段的首部中。




TCP首部最大長度是60位元組，其中有20位元組固定的首部，以及40位元組的可選的選項。圖示按照4位元組為單位。

2.1 TCP報文段的固定首部

固定首部佔20位元組。

源埠和目的埠：各佔兩位元組。和UDP的分用相似，TCP分用也是通過埠實現。

序號：佔4位元組，32位。序號範圍是[0,2³²-1]，一共2³²=4294967296個序號。當序號達到最大值時，下一個序號又回到0也就是說序號採用mod2³²運算。TCP是面向位元組流的，序號也是對位元組的編號。序號指的是本報文段第一個位元組的編號。如果報文段序號是301，攜帶的資料100位元組，那麼下一個報文段序號就是401。

確認號：佔4位元組。期望收到的下一個位元組的序號。例如上面的場景，接收方收到了301-400位元組共100個位元組，確認號應該為401，即下一個報文段的序號應該是401。如果確認號=N，那麼表示到序號N-1為止的所有位元組已經正確收到。

資料偏移：佔4位。指出TCP報文段的資料部分距離起始位置的位元組數，實際上是指出首部的長度。有了首部長度就可以知道選項部分的長度。但資料偏移的單位是4位元組，即首部最大長度=15*4=60Byte。

保留：佔6位，置為0.

6個控制位：

• 緊急（URG）：當URG=1時，表示緊急指標欄位有效，即報文段中有緊急資料，需要儘快傳送。於是傳送方TCP就把緊急資料放到報文段的前面，需要與緊急指標配合使用。
• 確認（ACK）：當ACK=1時，表示確認號欄位有效。TCP規定連線建立後所有報文段都要置ACK=1。
• 推送（PSH）：互動式通訊時，有時希望在一端鍵入一個命令後立即收到對方的響應，就可以使用推送。傳送方把PSH置1，並立即建立一個報文段傳送出去。接收方收到PSH=1的報文段，就儘快的交付接收程式，而不是等到快取滿了才交付。
• 復位（RST）：當RST=1時，表示TCP連線出現嚴重差錯，必須釋放連線，然後再重新建立運輸連線。還可以用來拒絕開啟一個連線。
• 同步（SYN）：當SYN=1時，表示是一個連線請求報文或者連線接受報文段。當SYN=1&ACK=0時，表示是連線請求報文；當SYN=1&ACK=1時，表示是連線接受報文。
• 終止（FIN）：當FIN=1時，表示傳送方資料傳送完畢，要求釋放連線。

視窗：佔2位元組。視窗值表示的是傳送報文的一方的接收視窗，即接收方目前允許對方傳送的資料量。視窗作為傳送方設定傳送視窗的一個依據。

檢驗和：佔2位元組。計算檢驗和和UDP一樣，加上12位元組的偽首部，進行二進位制反碼求和。

緊急指標：佔2位元組，表示緊急資料的位元組數。

2.2 TCP報文段的選項和填充

選項長度可變，最大40位元組。填充欄位將首部填充到4位元組的整數倍。

最大報文段長度（MSS，Maximum Segment Size）：MSS是TCP報文段資料部分的最大長度。MSS和接收視窗值沒有關係。較小的MSS會使網路利用率降低，即資料部分佔整個報文段的比例比較低，傳送有效資料的能力降低；較大的MSS可能在IP層分解成多個短資料包片。在終點要把多個短資料包片組裝成原來的TCP報文段，這些都會使開銷增大。因此MSS應該儘可能大些，只要不在IP層分片即可。但由於IP資料包經歷的路徑是動態變化的，因此最佳的MSS是很難確定的。預設MSS=536，即網際網路上的主機都應能接受的報文段長度=536+20=556位元組。

視窗擴大選項：佔3位元組，用於擴大視窗。TCP固定首部中的視窗占2位元組，即16位，最大視窗大小=64KB。視窗擴大選項有一個位元組表示移位值S，允許使用的最大值是14.
新的視窗位數從16增大到16+S。即加上視窗擴大選項後最大的視窗值大小為2^(16+14)=2³⁰=1GB。當S=0時，視窗大小回到16位。

時間戳：佔10位元組，其中時間戳欄位4位元組，時間戳回送回答欄位4位元組，用於計算往返時間RTT。傳送方傳送報文段時把當前時間戳放到時間戳欄位，接收方確認時把時間戳欄位值複製到時間戳回送回答欄位，傳送方收到確認後就可以計算RTT。此外還用於處理序號繞回。由於序號只有32位，即2³²=4294967296B，當使用高速網路時更容易出現序號繞回現象，使用時間戳欄位來區分新的報文段和舊的報文段。

三、TCP可靠傳輸的實現

3.1 以位元組為單位的滑動視窗

TCP的滑動視窗是以位元組為單位的。包括髮送視窗和接收視窗。

傳送視窗表示，在沒有收到確認的情況下，視窗內的序號可以連續傳送；在收到確認之前，所有資料都應保留副本以備重傳。




傳送視窗越大，傳送方就可以連續傳送更多的資料，就可能獲得更高的傳輸效率。但是傳送視窗大小不能超過接收方在確認報文中返回的接收視窗的大小（超過了接收方的接受能力），也不能超過擁塞視窗的大小（超過了網路的承受能力）。

傳送視窗由前沿和後沿的位置共同確定。後沿的後面部分表示已傳送並且已收到確認。前沿的前面部分是不允許傳送的資料。後沿的變化有兩種情況，即不動和前移，收到確認前不動，收到確認時前移；後沿是不可能後移的。而前沿的變化通常是不斷向前移動，但也有可能不動。不動的情形包括兩種情況，即沒有收到確認，或者收到確認但是接收方返回的視窗變小了。前沿也可能向後收縮，但是TCP標準不建議這樣做。

描述一個傳送視窗的狀態需要三個指標，即P1,P2,P3。小於P1的部分表示已經傳送且已經確認，P1~P2之間的部分表示已經傳送還未收到確認，P2~p3的部分表示允許傳送但還沒有傳送，大於P3的部分表示不允許傳送。




再來看接收視窗。接收視窗內的序號都允許接收，按序接收、傳送確認並交付主機後，就可以丟棄資料。




只有按序接收資料、確認並交付主機後，接收視窗才可以向前滑動。如果不是按序收到的資料，只能先暫存在視窗中。

如果傳送方在一段時間內沒有收到確認，那麼就要對這些資料進行重傳，重設超時計時器。直到收到確認為止。



傳送快取和接收快取

TCP除了傳送視窗和接收視窗，還有傳送快取和接收快取。傳送方的應用程式把位元組流寫入TCP的傳送快取，接收方的應用程式從TCP的接收快取中讀取位元組流。




傳送快取用來存放：傳送應用程式傳送給TCP準備傳送的資料；已經傳送但是還未收到確認的資料。接收快取用來存放：按序到達的但未被應用程式讀取的資料；未按序到達的資料。

如果收到的分組有差錯，接收方就會丟棄分組。如果接收應用程式來不及讀取資料，接收快取就會被填滿，使視窗減小到0；如果接收應用程式能及時從接收快取中讀取資料，接收視窗就可以增大。但最大不能超過接收快取的大小。

• 雖然傳送視窗是根據接收方的接收視窗設定的，但是同一時刻兩個視窗大小並不總是一樣大，因為通過網路傳送視窗只需要一定的時間滯後。此外，傳送方還可能根據網路擁塞情況調整視窗大小。
• 對於不按序到達的資料，TCP並無明確規定。如果接收方直接丟棄，那麼對網路的利用不利。因此TCP通常會臨時儲存不按序到達的資料，等到缺少的位元組收到後，再按序交付上層應用程式。
• TCP要求接收方必須有累計確認功能。接收方不應過度推遲確認，TCP規定確認推遲的時間不超過0.5秒。如果收到一連串具有最大長度的報文段，那麼必須每隔一個報文段就傳送一個確認。

3.2 超時重傳時間的選擇

傳送方傳送分組後會設定超時計時器，超過時間則會進行重傳。超時重傳時間（RTO，Retransmission Time-Out）如果取得過大，則會降低傳輸效率；取得過小則會引起不必要的重傳。TCP採用自適應演算法來動態的更新超時重傳時間，即根據當前網路的狀況不斷修正超時重傳時間。一個報文段從發出到收到確認所經歷的時間，就是報文段的往返時間RTT。TCP保留了加權平均往返時間RTTs和加權平均往返時間偏差RTTd。第一次測量到RTT時，RTTs就取測量到的RTT樣本；此後RTTs的值根據公式更新：

RTTs=(1-α)*RTTs+α*RTT

TCP建議的α=1/8=0.125。用這種方法得到的加權平均往返時間就更加平滑。

超時計時器的超時重傳時間應該略大於上面的RTTs。因此用這個公式來計算RTO：

RTO=RTTs+4×RTTd

當第一次測量時，RTTd=1/2*RTT。後續RTTd的值根據公式更新：

RTTd=(1-β)*RTTd+β*|RTTs-RTT|

TCP建議的β=1/8=0.125。

對於往返時間的測量，正常情況下可以通過首部選項中的時間戳來完成。但如果發生了超時重傳，那麼如何確定接收方發來的確認是對原報文的確認，還是對重傳報文的確認。由於傳送方無法判斷，因此計算的RTTs值可能出錯。

根據Karn提出的演算法，計算加權平均往返時間RTTs時，如果出現了超時重傳，那麼就不計算往返時間。這樣計算的往返時間就比較準確。但在超時重傳情況下，如果網路確實變差了，那麼超時重傳時間實際上應該提高（多留一些時間用來接收確認）。因此修正Karn演算法，在每次重傳時，將超時重傳時間設定為2倍大小。當不再發生超時重傳時，再根據上述公式重新計算。

3.3 選擇確認SACK

選擇確認可以通過TCP首部的選項控制。當收到的報文無差錯，只是未按序到達時，可以通過選擇確認通知傳送方不必傳送這些重複資料。




如圖，由於接收的位元組塊不連續，使用選擇確認來通知傳送方。這時需要標記不連續位元組塊的邊界，即位元組塊的左邊界序號和右邊界序號。

要使用選擇確認，需要在建立TCP連線時，在選項欄位加上允許SACK的選項。由於首部選項長度最大40位元組，而指明一個邊界就需要4位元組。指明使用選擇確認還需要兩個位元組，一個位元組說明是SACK選項，另一個位元組說明SACK佔用多少位元組。因此一個TCP報文段使用選擇確認最多報告四個不連續位元組塊的資訊。

四、TCP流量控制

4.1 利用滑動視窗實現流量控制

流量控制是端到端的控制，即傳送方和接收方之間的流量控制，主要通過接收方返回的接收視窗來控制。如果傳送方傳送的速率過快，以至於接收方來不及接收（快取滿了，接收應用程式來不及接收），那麼就需要對傳送方傳送的速率進行控制。




在連線建立時，接收方在首部的視窗欄位中通知傳送方，接收視窗rwnd的大小。傳送方的傳送視窗不能超過接收方接收視窗的大小。隨後每一次接收方確認時都會把自己的接收視窗告知傳送方，因此接收視窗和傳送視窗都是可變的。但如果接收方通知的視窗大小為0，即不允許傳送方傳送。那麼當接收方恢復接收能力的時候，傳送方並不知道，也就不會傳輸資料，這條連線就相當於假死（不再傳輸資料）。因此TCP規定，當傳送方收到接收方的零視窗通知時，啟動持續計時器（Persistence Timer），計時器到期時就傳送一個零視窗探測報文段（僅攜帶1位元組資料）。接收方在確認時就給出了當前的視窗值，如果接收視窗大小變化，傳送方也就可以通過這種探測繼續傳送資料了。

4.2 TCP的傳輸效率（傳送資料和傳送確認的時機）

（個人感覺傳輸效率和流量控制沒什麼關係；另外這裡似乎只是一種理論上的討論，並不是真正的實現……不過還是先按書上的來）

可以使用不同的機制來控制傳送時機。第一種是當快取中的資料達到最大報文段長度MSS時，就立即建立一個報文段傳送出去。第二種是應用程式指明要求傳送報文段，即推送操作。第三種是計時器的時間到期就立即傳送。但在實際中廣泛使用的Nagle演算法：傳送應用程式把要傳送的資料逐個位元組寫入到TCP的傳送快取中，則傳送方就把第一個位元組先傳送出去，後面的資料先快取起來，等到收到接收方的確認後再傳送下一個報文段。此外，當到達的資料達到報文段的最大長度，或者已經達到傳送視窗的一半時，就立即傳送一個報文段。這樣可以有效提高網路的吞吐量。

另外一個問題是糊塗視窗綜合症（silly window syndrome）。如果接收方的快取已滿，應用程式一次只從接收快取讀取一個位元組，然後就向傳送方傳送確認，確認報文段中的視窗大小=1，那麼傳送方就只在報文段中方1位元組的資料，而TCP首部20位元組+IP首部20位元組卻有40位元組，這樣使有效資料傳輸效率大大降低。因此接收方應該控制傳送確認的時機。可以讓接收方等待一段時間，要麼接收快取能夠容納一個最長報文段，要麼接收快取已有一半的空閒空間，這時向傳送方傳送確認報文通知視窗大小。當然，接收方不應過度推遲確認。

五、TCP擁塞控制

5.1 擁塞控制的一般原理

如果一段時間內，網路內對資源的需求超過了該資源的總量，就會產生擁塞現象。如果網路中有許多資源同時供應不足，網路的效能就會大幅下降。網路內的資源包括：處理機處理的速率、處理機的快取容量、鏈路等。然而要解決擁塞問題，單純的增加資源供給是不一定能解決問題的，而且還可能使網路變壞。這是因為網路擁塞是一個複雜的問題。單純的增加某處的資源，往往會將瓶頸轉移到其他地方。因此擁塞問題的實質是整個系統的各個部分相互匹配，即網路的整體能力和節點的區域性能力匹配。

擁塞控制和流量控制是有區別的。流量控制是端對端的問題，是控制傳送方和接收方之間傳輸的流量，而不管網路情況如何。擁塞控制是為了避免大量的資料湧入網路，造成更嚴重的擁塞，使得網路能夠承受現有的網路負荷。擁塞控制是一個全域性性的過程，涉及到所有的主機、路由器以及與降低網路效能有關的所有因素。




如圖，橫座標是提供的負載，單位時間內輸入到網路中的分組數量。縱座標是網路的吞吐量，單位時間內輸出的分組數目。理想條件下，當負載沒有超過網路的最大能力時，吞吐量等於分組（45度斜線），當負載超過了網路的最大能力時，吞吐量就等於網路提供的最大能力。然而實際情況下在網路吞吐量明顯的小於理想的吞吐量時，網路久進入了輕度擁塞狀態。當提供的負載大到某一數值時，網路的吞吐量反而開始下降，甚至降低到0，使網路無法工作，進入死鎖狀態（deadlock）。在實際的擁塞控制下，當提供的負載還沒有達到網路的最大能力時，擁塞控制就已經開始發揮作用，使得吞吐量無限趨近理想的最大吞吐量。

從控制理論的角度來看，解決擁塞問題有開環控制和閉環控制兩種方法。開環控制即設計網路時就將各種因素考慮到，一旦執行起來就不再更改了。閉環控制基於反饋環路的概念，通過檢測網路系統的執行，及時採取行動來避免擁塞。用於反應擁塞問題的指標包括：快取缺少空間丟棄的分組數、平均佇列長度、超時重傳的分組數、平均分組時延等等。一般監測到擁塞發生時，要把擁塞的資訊傳送給傳送分組的源站。另一種方法是在路由器轉發的分組中保留一個位元或欄位，來表示網路發生了擁塞。也可以由一些主機或路由器週期性的探測網路情況。

實際上擁塞控制機制是很難設計的，有時候一個不好的擁塞控制機制恰恰會引發網路的擁塞。

5.2 TCP的擁塞控制方法

TCP進行擁塞控制的演算法有四種，慢開始（slow-start）、擁塞避免（congestion avoidance）、快重傳（fast retransmit）和快恢復（fast recovery）。

基於視窗的擁塞控制，傳送方維持一個擁塞視窗cwnd（congestion window）。擁塞視窗的大小隨網路擁塞程度變化而變化，傳送方根據擁塞視窗設定傳送視窗。只要網路沒有發生擁塞，擁塞視窗就可以增大一些；但只要網路出現擁塞，或者可能出現擁塞，擁塞視窗就必須減小。通訊線路的傳輸質量一般都很好，因為傳輸出現差錯而丟棄分組的概率是很小的。因此傳送方判斷網路出現擁塞的依據就是超時。上面提到的四種演算法都是用於擁塞情況下調整擁塞視窗以及快速處理可能引起誤判的3-ACK分組。

慢開始演算法：當主機開始傳送資料時，由於不清楚當前的網路情況，因此不應該立即向網路注入大量資料，所以應該從小到大增大擁塞視窗數值，通過慢開始探測網路情況。新的RFC5681把初始的cwnd設定為不超過2~4個SMSS（傳送方最大報文段長度，SMSS, Sender Maximum Segment Size）。注意，擁塞視窗的單位是位元組。慢開始演算法規定，每收到一個報文段的確認後，可以把擁塞視窗增加最多一個SMSS的數值。cwnd增加量=MIN(N,SMSS)，N為本次確認的位元組數。下面以報文段個數作為視窗大小的單位，即初始值為cwnd=1，以後每收到一個報文段的確認就增加1。



使用慢開始演算法，每經過一個傳輸輪次（transmission round），擁塞視窗就加倍，因此是指數增長。傳輸輪次是指將擁塞視窗允許傳送的報文段全部傳送，並收到對最後一個位元組的確認。在實際情況下，傳送方只要收到一個報文段的確認，就可以立即傳送下一個報文段，而不必等待傳輸輪次都傳輸完。

為了防止慢開始演算法使擁塞視窗增大過快，設定一個慢開始門限（ssthreshold，slow-start threshold）。（如何設定慢開始門限？）慢開始門限表示：當cwnd<ssthreshold時，就使用慢開始演算法；當cwnd>ssthreshold時，改用擁塞避免演算法。

擁塞避免演算法：讓擁塞視窗緩慢的增大，即每經過一個傳輸輪次RTT，擁塞視窗cwnd就加1，而不是像慢開始演算法加倍擴大。因此擁塞避免階段有"加法擴大"（Additive Increase）。這表明在擁塞避免階段，擁塞視窗按照線性規律增長。

如圖所示。擁塞避免階段中cwnd=24時，出現了超時重傳，傳送方判斷可能發生了網路擁塞，於是將cwnd置1，門限值ssthreshold=cwnd/2=12，再次進行慢開始演算法。當擁塞視窗cwnd=12時，又改為擁塞避免演算法。經過一段時間的增長，cwnd=16時，出現了3-ACK（傳送方連續三次收到對同一分組的確認）。3-ACK表示某一分組傳輸過程中很可能丟失了，導致接收方沒有收到，而實際上網路可能沒有發生擁塞，但由於發生超時，傳送方就會主動降低傳送速率。因此要採用快重傳和快恢復。

快重傳演算法：快重傳可以讓傳送方儘早知道丟失的分組。快重傳演算法要求接收方收到分組時要立即傳送確認，即使收到了失序的報文段也必須立即確認。這樣傳送方一旦發現某一分組出現3-ACK現象，說明該分組在傳輸過程中丟失了，應該立即重傳。如果在超時時間前收到了接收方的確認，那麼就可以避免重新進入慢開始。快重傳可以使網路的吞吐量提高20%。因此當cwnd=16時，傳送方知道有分組丟失了，於是不啟動慢開始，而是執行快恢復演算法。

快恢復演算法：這時ssthreshold=cwnd/2=8，cwnd=ssthreshold=8，並開始執行擁塞避免演算法。（這塊書有點坑啊，註釋說了門限值減半是簡化的說法，實際上TCP的計算公式ssthreshold=max(FlightSize/2, 2*SMSS)， 其中FlightSize就是正在網路中傳送的資料量，即已傳送還未收到確認的資料）
在擁塞避免階段，擁塞視窗是線性增大的，常稱為加法增大（Additive Increase）。而一旦出現超時或者3-ACK，就要把門限值設定為當前視窗的一半，常稱為乘法減小（Multiplicative Decrease）。二者合在一起就是所謂的AIMD演算法。

採用這樣的擁塞控制方法使得TCP效能得到明顯改進。




如圖為TCP擁塞控制整個的流程圖。不管當前處於什麼階段，只要發生重傳，就將門限值減半、擁塞視窗置1，並執行慢開始演算法；只要出現3—ACK，就將門限值減半，擁塞視窗置為門限值大小。

考慮到TCP首部中的接收視窗，傳送方的傳送視窗大小需要受到接收視窗和擁塞視窗的共同制約。即傳送方傳送視窗的上限=min(rwnd,cwnd)。

5.3 主動佇列管理

考慮網路層的策略對擁塞控制的影響。其中影響最大的就是路由器的分組丟棄策略。理想情況下路由器的佇列通常按照先進先出（FIFO）規則處理到來的分組；當佇列已滿時，就丟棄後續到達的分組，稱之為"尾部丟棄策略"。路由器的尾部丟棄往往會導致一系列分組的丟失，並使得TCP連線的傳送方出現超時重傳，突然把傳輸速率降低到很小。由於網路中有很多的TCP連線， 因此可能導致許多連線同時出現超時重傳並降低傳輸速率，稱之為"全域性同步"。全域性同步使得網路中的資料量突然降低到很小的水平。

為了避免發生網路中的全域性同步現象，提出了主動佇列管理（AQM，Active Queue Management）。不是在佇列已滿的時候才丟棄分組，而是在佇列長度到達某個值時就開始丟棄分組。AQM的一種實現是隨機早期檢測（Random Early Detection），或者隨機早期丟棄（Random Early Drop）。實現RED需要使路由器維持兩個引數，即佇列最小長度門限和最大長度門限。當分組到達時，如果平均佇列長度小於最小長度門限，就把分組加入佇列；如果平均佇列長度超過最小長度門限，小於最大長度門限，則以隨機概率p丟棄分組； 平均佇列長度超過最大長度門限，則丟棄分組。因此RED是在監測到網路擁塞的早期徵兆時就採取措施丟棄分組來避免擁塞。但由於隨機概率p不易選擇，RED的效果也不太理想，因此RED已經不再推薦使用，但替代演算法還處於實驗階段。

參考資料：《計算機網路第七版》謝希仁