tcp的擁塞控制有哪幾種演算法

Ⅰ TCP協議採取了哪些機制來進行擁塞控制

最初的TCP協議只有基於窗口的流控制（flow control）機制而沒有擁塞控制機制，流控制是一種局部控制機制，其參與者僅僅是發送方和接收方，它只考慮了接收端的接收能力，而沒有考慮到網路的傳輸能力；而擁塞控制則注重於整體，其考慮的是整個網路的傳輸能力，是一種全局控制機制。 擁塞控制機制使得TCP連接在網路發生擁塞時回退（back off），也就是說TCP源端會對網路發出的擁塞指示（congestion notification）（例如丟包、重復的ACK等）作出響應。 針對TCP在控制網路擁塞方面的不足，後來又提出了「慢啟動」（Slow Start）和「擁塞避免」（Congestion Avoidance）演算法。 TCP Reno版本增加了「快速重傳 」（Fast Retransmit）、「快速恢復」（Fast Recovery）演算法，避免了網路擁塞不嚴重時採用「慢啟動」演算法而造成過大地減小發送窗口尺寸的現象，這樣TCP的擁塞控制就由這4個核心部分組成。 近幾年又出現TCP的改進版本如NewReno和選擇性應答（selective acknowledgement，SACK）等。

Ⅱ tcp擁塞控制常用演算法

tcp擁塞控制常用演算法方法如下
TCP協議有兩個比較重要的控制演算法，一個是流量控制，另一個就是阻塞控制。TCP協議通過滑動窗口來進行流量控制，它是控制發送方的發送速度從而使接受者來得及接收並處理。而擁塞控制是作用於網路，它是防止過多的包被發送到網路中，避免出現網路負載過大，網路擁塞的情況。擁塞演算法需要掌握其狀態機和四種演算法。擁塞控制狀態機的狀態有五種，分別是Open，Disorder，CWR，Recovery和Loss狀態。四個演算法為慢啟動，擁塞避免，擁塞發生時演算法和快速恢復。和TCP一樣，擁塞控制演算法也有其狀態機。當發送方收到一個Ack時，LinuxTCP通過狀態機(state)來決定其接下來的行為，是應該降低擁塞窗口cwnd大小，或者保持cwnd不變，還是繼續增加cwnd。

Ⅲ 淺談TCP（2）：流量控制與擁塞控制

上文 淺談TCP（1）：狀態機與重傳機制 介紹了TCP的狀態機與重傳機制。本文介紹 流量控制 （Flow Control，簡稱流控）與 擁塞控制 （Congestion Control）。TCP依此保障網路的 QOS （Quality of Service）。

根據前文對TCP超時重傳機制的介紹，我們知道Timeout的設置對於重傳非常重要：

而且，這個超時時間在不同的網路環境下不同，必須動態設置。為此，TCP引入了 RTT （Round Trip Time，環回時間）：一個數據包從發出去到回來的時間。這樣，發送端就大約知道正常傳輸需要多少時間，據此計算 RTO （Retransmission TimeOut，超時重傳時間）。 聽起來似乎很簡單：在發送方發包時記下t0，收到接收方的Ack時記一個t1，於是RTT = t1 – t0。然而，這只是一個采樣，不能代表網路環境的普遍情況。

RFC793 中定義了一個 經典演算法 ：

經典演算法描述了RTO計算的基本思路，但還有一個重要問題：RTT的采樣取「 第一次 發Seq+收Ack的時間」，還是「 重傳 Seq+收Ack的時間」？

如圖：

問題的本質是： 發送方無法區分收到的Ack對應第一次發的Seq還是重傳的Seq （進入網路就都一樣了）。針對該問題， Karn / Partridge 演算法選擇迴避重傳的問題： 忽略重傳的樣本，RTT的采樣只取未產生重傳的樣本 。

簡單的忽略重傳樣本也有問題：假設當前的RTO很小，突然發生網路抖動，延時劇增導致要重傳所有的包；由於忽略重傳樣本，RTO不會被更新，於是繼續重傳使網路更加擁堵；擁堵導致更多的重傳，惡性循環直至網路癱瘓。Karn / Partridge演算法用了一個取巧的辦法： 只要一發生重傳，就將現有的RTO值翻倍（指數回退策略），待網路恢復後再仿照經典演算法逐漸平滑以降低RTO 。

該演算法已經做到可用，然而網路抖動對性能的影響比較大。

前面兩種演算法均使用加權移動平均演算法做平滑，這種方法的最大問題是：很難發現RTT值上的較大波動，因為被平滑掉了（1 - a比較小，即最新RTT的權重小）。針對該問題， Jacobson / Karels 演算法引入了最新采樣的RTT值和平滑過的SRTT值的差距做因子，即 DevRTT （Deviation RTT，RTT的偏離度），同時考慮SRTT帶來的慣性和DevRTT帶來的波動：

Linux 2.6採用該演算法計算RTO，默認取α = 0.125, β = 0.25, μ = 1, ∂ = 4（玄學調參，你懂的）。

TCP使用 滑動窗口 （Sliding Window）做流量控制與 亂序重排 。亂序重排在TCP的重傳機制中已經介紹，下面介紹流量控制。

TCP頭里有一個欄位叫Window（或Advertised Window）， 用於接收方通知發送方自己還有多少緩沖區可以接收數據 。 發送方根據接收方的處理能力來發送數據，不會導致接收方處理不過來，是謂流量控制 。暫且把Advertised Window當做滑動窗口，更容易理解滑動窗口如何完成流量控制，後面介紹擁塞控制時再說明二者的區別。

觀察TCP協議的發送緩沖區和接收緩沖區：

假設位置序號從左向右增長（常見的讀、寫緩沖區設計），解釋一下：

據此在接收方計算 AdvertisedWindow ，在發送方計算 EffectiveWindow ：

AdvertisedWindow衡量接收方還能接收的數據量，發送方要根據AdvertisedWindow決定接下來發送的數據量上限，即EffectiveWindow（可能為0）。

由於亂序問題的存在，LastByteRcvd可能指向Seq(LastByteSent)，而Seq(LastByteAcked + 1)至Seq(LastByteSent - 1)都還在路上 ，即將到達接收方，最好的情況是不丟包（丟包後會重傳）， 則LastByteRcvd之後、接收緩沖區邊界之前的空間就是發送方下一次發送數據的長度上限 （重傳不屬於下一次發送），因此， AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead) 。

LastByteRcvd還可能指向Seq(LastByteAcked)（一個新包都沒有收到） ，顯然AdvertisedWindow的公式不變， 而Seq(LastByteAcked + 1)至Seq(LastByteSent)都還在路上 ，未來將到達接收方，進入接收緩沖區，則「還在路上的Seq(LastByteAcked + 1)至Seq(LastByteSent)」不應超過接收緩沖區的剩餘空間AdvertisedWindow（目前等於MaxRcvBuffer），這要求的是上一次發送滿足LastByteSent - LastByteAcked ≤ AdvertisedWindow， 那麼LastByteSent之後、接收緩沖區剩餘空間邊界之前的空間就是發送方窗口內剩餘可發送數據的長度上限 ，因此， EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) 。

以下是一個發送緩沖區的滑動窗口：

上圖分為4個部分：

其中， #2 + #3 組成了滑動窗口，總大小不超過AdvertisedWindow，二者比例受到接收方的處理速度與網路情況的影響（如果丟包嚴重或處理速度慢於發送速度，則 #2:#3 會越來越大）。

以下是一個AdvertisedWindow的調整過程，EffectiveWindow隨之變化：

上圖，我們可以看到一個處理緩慢的Server（接收端）是怎麼把Client（發送端）的發送窗口size給降成0的。對於接收方來說，此時接收緩沖區確實已經滿了，因此令發送方的發送窗口size降為0以暫時禁止發送是合理的。那麼，等接收方的接收緩沖區再空出來，怎麼通知發送方新的window size呢？

針對這個問題，為TCP設計了ZWP技術（Zero Window Probe，零窗通告）：發送方在窗口變成0後，會發ZWP的包給接收方，讓接收方來Ack他的Window尺寸；ZWP的重傳也遵循指數回退策略，默認重試3次；如果3次後window size還是0，則認為接收方出現異常，發RST重置連接（<font color="red"> 部分文章寫的是重試到window size正常？？？ </font>）。

注意：只要有等待的地方都可能出現DDoS攻擊，Zero Window也不例外。一些攻擊者會在和服務端建好連接發完GET請求後，就把Window設置為0，於是服務端就只能等待進行ZWP；然後攻擊者再大量並發發送ZWP，把伺服器端的資源耗盡。（<font color="red"> 客戶端等待怎麼耗服務端？？？ </font>）

為什麼要進行擁塞控制？假設網路已經出現擁塞，如果不處理擁塞，那麼延時增加，出現更多丟包，觸發發送方重傳數據，加劇擁塞情況，繼續惡性循環直至網路癱瘓。可知，擁塞控制與流量控制的適應場景和目的均不同。

擁塞發生前，可避免流量過快增長拖垮網路；擁塞發生時，唯一的選擇就是降低流量 。主要使用4種演算法完成擁塞控制：

演算法1、2適用於擁塞發生前，演算法3適用於擁塞發生時，演算法4適用於擁塞解決後（相當於擁塞發生前）。

在正式介紹上述演算法之前，先補充下 rwnd （Receiver Window，接收者窗口）與 cwnd （Congestion Window，擁塞窗口）的概念：

介紹流量控制時，我們沒有考慮cwnd，認為發送方的滑動窗口最大即為rwnd。實際上， 需要同時考慮流量控制與擁塞處理，則發送方窗口的大小不超過 min{rwnd, cwnd} 。下述4種擁塞控制演算法只涉及對cwnd的調整，同介紹流量控制時一樣，暫且不考慮rwnd，假定滑動窗口最大為cwnd；但讀者應明確rwnd、cwnd與發送方窗口大小的關系。

慢啟動演算法 （Slow Start）作用在擁塞產生之前： 對於剛剛加入網路的連接，要一點一點的提速，不要妄圖一步到位 。如下：

因此，如果網速很快的話，Ack返回快，RTT短，那麼，這個慢啟動就一點也不慢。下圖說明了這個過程：

前面說過，當cwnd >= ssthresh（通常ssthresh = 65535）時，就會進入 擁塞避免演算法 （Congestion Avoidance）： 緩慢增長，小心翼翼的找到最優值 。如下：

慢啟動演算法主要呈指數增長，粗獷型，速度快（「慢」是相對於一步到位而言的）；而擁塞避免演算法主要呈線性增長，精細型，速度慢，但更容易在不導致擁塞的情況下，找到網路環境的cwnd最優值。

慢啟動與擁塞避免演算法作用在擁塞發生前，採取不同的策略增大cwnd；如果已經發生擁塞，則需要採取策略減小cwnd。那麼，TCP如何判斷當前網路擁塞了呢？很簡單， 如果發送方發現有Seq發送失敗（表現為「丟包」），就認為網路擁塞了 。

丟包後，有兩種重傳方式，對應不同的網路情況，也就對應著兩種擁塞發生時的控制演算法：

可以看到，不管是哪種重傳方式，ssthresh都會變成cwnd的一半，仍然是 指數回退，待擁塞消失後再逐漸增長回到新的最優值 ，總體上在最優值（動態）附近震盪。

回退後，根據不同的網路情況，可以選擇不同的恢復演算法。慢啟動已經介紹過了，下面介紹快速恢復演算法。

如果觸發了快速重傳，即發送方收到至少3次相同的Ack，那麼TCP認為網路情況不那麼糟，也就沒必要提心吊膽的，可以適當大膽的恢復。為此設計 快速恢復演算法 （Fast Recovery），下面介紹TCP Reno中的實現。

回顧一下，進入快速恢復之前，cwnd和sshthresh已被更新：

然後，進入快速恢復演算法：

下面看一個簡單的圖示，感受擁塞控制過程中的cwnd變化：

Ⅳ TCP擁塞控制

  在計算機網路中的鏈路容量（即帶寬）、交換節點（如路由器）中的緩存和處理機等，都是網路的資源。在某段時間內，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的性能就要變壞，從而導致吞吐量將隨著輸入負荷增大而降低。這種情況就叫做 擁塞 。通俗來說，就跟交通擁堵性質一樣。

  網路擁塞的原因有很多，如交換節點的 緩存容量太小、輸出鏈路的容量和處理機的速度 。

   擁塞控制就是防止過多的數據注入網路中，這樣可以使網路中的路由器或鏈路不致於過載 。擁塞控制是一個 全局性的過程 。涉及網路中所有的主機、所有的路由器，以及與降低網路傳輸性能有關的所有因素。

  擁塞控制和流量控制的關系密切，但是 流量控制往往是指點對點的通信量控制 ，是個 端對端 的問題。流量控制所要做的就是抑制發送方發送數據的速率，以便使接收端來得及接收。

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

  為了討論問題方便，提出以下假定：

  擁塞控制也叫做 基於窗口 的擁塞控制。為此，發送方維持一個叫作 擁塞窗口cwnd （congestion window）的狀態變數。 擁塞窗口的大小取決於網路的用誰程度，並且動態的變化。發送方讓自己的發送窗口等於擁塞窗口 。

  接收方窗口值rwnd和擁塞窗口值cwnd的區別：

  發送方控制擁塞窗口的原則是：只要網路沒有出現擁塞，擁塞窗口就可以再擴大一些，以便讓更多的分組發送出去，如果網路出現了擁塞，就必須將擁塞窗口減小一些，以減少分組的發送。 判斷網路擁塞的依據就是出現了超時 。

  慢開始演算法的思路：剛開始發送數據時，不一下向網路中注入大量數據，而是先探測一下，即 由小到大逐漸增大發送窗口 ，也就是說， 由小到大逐漸增大擁塞窗口數值 。

  慢開始演算法具體規定：剛開始發送數據時，先把擁塞窗口cwnd根據 發送方的最大報文段SMSS （Sender Maximum Segment Size）數值的大小設置為不超過2-4個SMSS的數值。在 每收到一個對新的報文段的確認後，可以把擁塞窗口增加最多一個SMSS的數值 。用這樣的方法逐步增大發送方的擁塞窗口rwnd，可以使分組注入到網路中的速率更加合理。

  下面舉例說明一下，雖然實際上TCP是用位元組數作為窗口大小的單位，但為了方便描述，下面使用報文段的個數來作為窗口的大小的單位，並且假設所有的報文段大小相等。

  所以， 慢開始演算法每經過一個傳輸輪次（transmission round），擁塞窗口cwnd就加倍 。

  註：在TCP實際運行時，發送方只有收到一個確認就可以將cwnd加1並發送新的分組，並不需要等一個輪次所有的確認都收到後再發送新的分組。

  從上面可以看出，慢開始演算法雖然起始的窗口很小，但是每過一個輪次，窗口大小翻倍，呈指數爆炸增長，所以必須要對其進行一個限制，防止其增長過大引起網路擁塞。這個限制就是 慢開始門限ssthresh 狀態變數。慢開始門限ssthresh的用法如下：

  擁塞避免演算法的思路是讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是像慢開始階段那樣加倍增長。因此在擁塞避免階段就有 「加法增大」AI （Additive Increase）的特點。這表明在擁塞避免階段，擁塞窗口cwnd 按線性規律增長 ，比慢開始演算法的擁塞窗口增長速率緩慢得多。

  下面用一個具體的例子來說明擁塞控制的過程，下圖假設TCP發送窗口等於擁塞窗口，慢開始初始門限設置為16個報文段，即ssthresh = 16。

  在擁塞避免階段，擁塞窗口是按照線性規律增大的，這常稱為 加法增大AI 。無論在慢開始階段還是擁塞避免階段，只要出現一次超時（即出現一次網路擁塞），就把慢開始門限值 ssthresh 設置為當前擁塞窗口的一半，這叫做 乘法減小 MD （Multiplication Decrease）。

  當網路頻繁出現擁塞時，ssthresh 值就下降的很快，以大大減少注入網路中的分組數。

   快恢復演算法 ，如果發送方連續接收到3個冗餘ACK，發送方知道現在只是丟失了個別的報文段，此時調整門限值 ssthresh為當前擁塞窗口的一半，同時設置擁塞窗口 cwnd為新的門限值（發生報文段丟失時擁塞窗口的一半），而不是從1開始。

   TCP對這種丟包事件的行為，相比於超時指示的丟包，不那麼劇烈 ，所以對於連續收到3個冗餘ACK，擁塞窗口不會從1開始開始。

Ⅳ tcp如何實現擁塞控制

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

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

1、慢開始演算法：

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

2、擁塞避免演算法：

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

3、快重傳演算法：

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

4、快恢復演算法：

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

Ⅵ 常見的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本身攜帶的信息就可以使得發送方有足夠的信息來知道需要重傳哪些包，而不需要重傳哪些包。

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

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

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

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

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

防止擁塞的方法

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

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

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

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

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