tcp快速恢復演算法

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

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

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

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

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

防止擁塞的方法

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

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

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

⑵ tcp如何實現擁塞控制

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

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

1、慢開始演算法：

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

2、擁塞避免演算法：

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

3、快重傳演算法：

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

4、快恢復演算法：

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

⑶ 快重傳和快恢復的具體演算法

(1) 當發送端收到連續三個重復的 ACK 時，就重新設置慢開始門限 ssthresh。
(2) 與慢開始不同之處是擁塞窗口 cwnd 不是設置為 1，而是設置為 ssthresh + 3 ´ MSS。
(3) 若收到的重復的 ACK 為 n 個（n> 3），則將 cwnd 設置為 ssthresh + n´ MSS。
(4) 若發送窗口值還容許發送報文段，就按擁塞避免演算法繼續發送報文段。
(5) 若收到了確認新的報文段的 ACK，就將 cwnd 縮小到 ssthresh。 其中：擁塞窗口 cwnd
如果收到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需要收到該窗口內所有數據包的確認後才會退出快速恢復狀態，從而更一步提高吞吐量。

⑷ TCP/IP的快恢復演算法怎麼理解

struct tcp_sock {
...
/* Congestion window at start of Recovery. 進入Recovery前的擁塞窗口*/
u32 prior_cwnd;

/* Number of newly delivered packets to receiver in Recovery.
* 實際上用於統計data_rate_at_the_receiver，數據離開網路的速度。
*/
u32 prr_delivered;

/* Total number of pkts sent ring Recovery.
* 實際上用於統計sending_rate，數據進入網路的速度。
*/
u32 prr_out;
...
}
@net/ipv4/tcp_input.c
[java] view plain
static inline void tcp_complete_cwr (struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
/* Do not moderate cwnd if it's already undone in cwr or recovery. */
if (tp->undo_marker) {
if (inet_csk(sk)->icsk_ca_state == TCP_CA_CWR)
tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh);

else /* PRR */
tp->snd_cwnd = tp->snd_ssthresh; /* 防止不必要的進入慢啟動*/

tp->snd_cwnd_stamp = tcp_time_stamp;
}
tcp_ca_event(sk, CA_EVENT_COMPLETE_CWR);
}
[java] view plain
/* This function implements the PRR algorithm, specifically the PRR-SSRB
* (proportional rate rection with slow start rection bound) as described in
* http://www.ietf.org/id/draft-mathis-tcpm-proportional-rate-rection-01.txt.
* It computes the number of packets to send (sndcnt) based on packets newly
* delivered:
* 1) If the packets in flight is larger than ssthresh, PRR spreads the cwnd
* rections across a full RTT.
* 2) If packets in flight is lower than ssthresh (such as e to excess losses
* and/or application stalls), do not perform any further cwnd rections, but
* instead slow start up to ssthresh.
*/

static void tcp_update_cwnd_in_recovery (struct sock *sk, int newly_acked_sacked,
int fast_rexmits, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
int sndcnt = 0; /* 對於每個ACK，可以發送的數據量*/
int delta = tp->snd_ssthresh - tcp_packets_in_flight(tp);

if (tcp_packets_in_flight(tp) > tp->snd_ssthresh) {

/* Main idea : sending_rate = CC_rection_factor * data_rate_at_the_receiver，
* 按照擁塞演算法得到的減小因子，按比例的減小pipe，最終使pipe收斂於snd_ssthresh。
*/
u64 dividend = (u64) tp->snd_ssthresh * tp->prr_delivered + tp->prior_cwnd - 1;
sndcnt = div_u64(dividend, tp->prior_cwnd) - tp->prr_out;

} else {
/* tp->prr_delivered - tp->prr_out首先用於撤銷之前對pipe的減小，即首先讓網路中的數據包恢復守恆。
* 然後，tp->prr_delivered < tp->prr_out，因為目前是慢啟動，網路中數據包開始增加：
* 對於每個ACK，sndcnt = newly_acked_sacked + 1，使pipe加1，即慢啟動。
* delta使pipe最終收斂於snd_ssthresh。
*/
sndcnt = min_t(int, delta, max_t(int, tp->prr_delivered - tp->prr_out, newly_acked_sacked) + 1);
}

sndcnt = max(sndcnt, (fast_rexmit ? 1 : 0));
tp->snd_cwnd = tcp_packets_in_flight(tp) + sndcnt;
}
@tcp_ack()
[java] view plain
/* count the number of new bytes that the current acknowledgement indicates have
* been delivered to the receiver.
* newly_acked_sacked = delta(snd.una) + delat(SACKed)
*/
newly_acked_sacked = (prior_packets - tp->packets_out) + (tp->sacked_out - prior_sacked);

...

tcp_fastretrans_alert(sk, prior_packets - tp->packets_out, newly_acked_sacked, flag);

⑸ 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 如何保證可靠性

[TOC]

1. TCP可靠性的保證機制總結

2. 網路基礎：TCP協議-如何保證傳輸可靠性

3. TCP協議的流量控制和擁塞控制

4. TCP 的那些事兒（下）

5. TCP擁塞控制：慢開始、擁塞避免、快重傳、快恢復

TCP檢驗和的計算與UDP一樣，在計算時要加上12byte的偽首部，檢驗范圍包括TCP首部及數據部分，但是UDP的檢驗和欄位為可選的，而TCP中是必須有的。計算方法為：在發送方將整個報文段分為多個16位的段，然後將所有段進行反碼相加，將結果存放在檢驗和欄位中，接收方用相同的方法進行計算，如最終結果為檢驗欄位所有位是全1則正確（UDP中也是全為1則正確），否則存在錯誤。

TCP將每個數據包都進行了編號，這就是序列號。
序列號的作用：
a、保證可靠性（當接收到的數據總少了某個序號的數據時，能馬上知道）
b、保證數據的按序到達
c、提高效率，可實現多次發送，一次確認
d、去除重復數據
數據傳輸過程中的確認應答處理、重發控制以及重復控制等功能都可以通過序列號來實現

TCP通過確認應答機制實現可靠的數據傳輸。在TCP的首部中有一個標志位——ACK，此標志位表示確認號是否有效。接收方對於按序到達的數據會進行確認，當標志位ACK=1時確認首部的確認欄位有效。進行確認時，確認欄位值表示這個值之前的數據都已經按序到達了。而發送方如果收到了已發送的數據的確認報文，則繼續傳輸下一部分數據；而如果等待了一定時間還沒有收到確認報文就會啟動重傳機制。

當報文發出後在一定的時間內未收到接收方的確認，發送方就會進行重傳（通常是在發出報文段後設定一個鬧鍾，到點了還沒有收到應答則進行重傳）。
一種情況是發送包丟失了，其基本過程如下：

另一種情況是ACK 丟失，過程如下：

當接收方接收到重復的數據時就將其丟掉，重新發送ACK。而要識別出重復的數據，前面提到的序列號就起作用了。

重傳時間的確定：
重傳時間的確定：報文段發出到收到應答中間有一個報文段的往返時間RTT，顯然超時重傳時間RTO會略大於這個RTT，TCP會根據網路情況動態的計算RTT，即RTO是不斷變化的。在Linux中，超時以500ms為單位進行控制，每次判定超時重發的超時時間都是500ms的整數倍。其規律為：如果重發一次仍得不到應答，就等待2 500ms後再進行重傳，如果仍然得不到應答就等待4 500ms後重傳，依次類推，以指數形式遞增，重傳次數累計到一定次數後，TCP認為網路或對端主機出現異常，就會強行關閉連接。

連接管理機制即TCP建立連接時的三次握手和斷開連接時的四次揮手。

接收端處理數據的速度是有限的，如果發送方發送數據的速度過快，導致接收端的緩沖區滿，而發送方繼續發送，就會造成丟包，繼而引起丟包重傳等一系列連鎖反應。
因此TCP支持根據接收端的處理能力，來決定發送端的發送速度，這個機制叫做流量控制。
在TCP報文段首部中有一個16位窗口長度，當接收端接收到發送方的數據後，在應答報文ACK中就將自身緩沖區的剩餘大小，放入16窗口大小中。這個大小隨數據傳輸情況而變，窗口越大，網路吞吐量越高，而一旦接收方發現自身的緩沖區快滿了，就將窗口設置為更小的值通知發送方。如果緩沖區滿，就將窗口置為0，發送方收到後就不再發送數據，但是需要定期發送一個窗口探測數據段，使接收端把窗口大小告訴發送端。

注意：窗口大小不受16位窗口大小限制，在TCP首部40位元組選項中還包含一個窗口擴大因子M，實際窗口大小是窗口欄位的值左移M位。

流量控制解決了兩台主機之間因傳送速率而可能引起的丟包問題，在一方面保證了TCP數據傳送的可靠性。然而如果網路非常擁堵，此時再發送數據就會加重網路負擔，那麼發送的數據段很可能超過了最大生存時間也沒有到達接收方，就會產生丟包問題。
為此TCP引入慢啟動機制，先發出少量數據，就像探路一樣，先摸清當前的網路擁堵狀態後，再決定按照多大的速度傳送數據。
此處引入一個擁塞窗口：
發送開始時定義擁塞窗口大小為1；每次收到一個ACK應答，擁塞窗口加1；而在每次發送數據時，發送窗口取擁塞窗口與接送段接收窗口最小者。
慢啟動：在啟動初期以指數增長方式增長；設置一個慢啟動的閾值，當以指數增長達到閾值時就停止指數增長，按照線性增長方式增加；線性增長達到網路擁塞時立即「乘法減小」，擁塞窗口置回1，進行新一輪的「慢啟動」，同時新一輪的閾值變為原來的一半。
「慢啟動」機制可用圖表示：

1）連接建好的開始先初始化cwnd = 1，表明可以傳一個MSS大小的數據。

2）每當收到一個ACK，cwnd++; 呈線性上升

3）每當過了一個RTT，cwnd = cwnd*2; 呈指數讓升

4）還有一個ssthresh（slow start threshold），是一個上限，當cwnd >= ssthresh時，就會進入「擁塞避免演算法」（後面會說這個演算法）

1）收到一個ACK時，cwnd = cwnd + 1/cwnd

2）當每過一個RTT時，cwnd = cwnd + 1

這樣就可以避免增長過快導致網路擁塞，慢慢的增加調整到網路的最佳值。很明顯，是一個線性上升的演算法。

當出現ack超時的時候，需要重傳數據包。

TCP認為這種情況太糟糕，反應也很強烈。
快速重傳在收到3個plicate ACK時就開啟重傳(三次 ack 就認為丟包的原理見 關於TCP亂序和重傳的問題 、 TCP 快速重傳為什麼是三次冗餘 ACK )，而不用等到RTO超時。

TCP Reno的實現是：

快速重傳和快速恢復演算法一般同時使用。快速恢復演算法是認為，你還有3個Duplicated Acks說明網路也不那麼糟糕，所以沒有必要像RTO超時那麼強烈。 注意，正如前面所說，進入Fast Recovery之前，cwnd 和 sshthresh已被更新：

然後，真正的Fast Recovery演算法如下：
cwnd = sshthresh + 3 * MSS （3的意思是確認有3個數據包被收到了）
重傳Duplicated ACKs指定的數據包
如果再收到 plicated Acks，那麼cwnd = cwnd +1
如果收到了新的Ack，那麼，cwnd = sshthresh ，然後就進入了擁塞避免的演算法了。
如果你仔細思考一下上面的這個演算法，你就會知道，上面這個演算法也有問題，那就是——它依賴於3個重復的Acks。注意，3個重復的Acks並不代表只丟了一個數據包，很有可能是丟了好多包。但這個演算法只會重傳一個，而剩下的那些包只能等到RTO超時，於是，進入了惡夢模式——超時一個窗口就減半一下，多個超時會超成TCP的傳輸速度呈級數下降，而且也不會觸發Fast Recovery演算法了。

通常來說，正如我們前面所說的，SACK或D-SACK的方法可以讓Fast Recovery或Sender在做決定時更聰明一些，但是並不是所有的TCP的實現都支持SACK（SACK需要兩端都支持），所以，需要一個沒有SACK的解決方案。而通過SACK進行擁塞控制的演算法是FACK（可參見 關於TCP亂序和重傳的問題 ）

⑺ TCP擁塞控制演算法之NewReno和SACK

改進原因分析
TCP Reno 提出的快速恢復演算法提高了丟失報文後的吞吐量和頑健性，但是：

僅考慮了每次擁塞發生時只丟失一個報文的情形。
實際網路中，一旦發生擁塞，路由器會丟棄大量的報文，即一次擁塞中丟失多個報文的情形很普遍。

下圖是Reno演算法中快速恢復狀態和擁塞避免狀態之間的相互轉換：

所以，網路在一次擁塞中丟棄了多個報文，被TCP Reno錯誤地分析為傳輸中發生了多次擁塞。過度的窗口減小導致了傳輸超時的發生。因此為了提高一次擁塞中丟棄多個報文情形下TCP的性能，必須使TCP終端減少盲目削減發送窗口的行為。

New Reno：基於Reno演算法的改進
NewReno TCP在Reno TCP的基礎上對快速恢復演算法進行修改，只有一個數據包丟失的情況下，其機制和Reno是一樣的；當同時有多個包丟失時就顯示出了它的優勢。

Reno快速恢復演算法中發送方收到一個新的ACK就退出快速恢復狀態，New Reno演算法中只有當所有報文都被應答後才退出快速恢復狀態。

NewReno TCP添加了恢復應答判斷功能，以增強TCP終端通過ACK報文信息分析報文傳輸狀況的能力。
使TCP終端可以把一次擁塞丟失多個報文的情形與多次擁塞的情形區分開來，進而在每一次擁塞發生後擁塞窗口僅減半一次，從而提高了TCP的頑健性和吞吐量。

兩個概念：部分應答（PACK）、恢復應答（RACK）

記TCP發送端恢復階段中接收到的ACK報文（非冗餘ACK）為ACKx，記在接收到ACKx時TCP終端已發出的序列號（SN）最大的報文是PKTy，如果ACKx不是PKTy的應答報文，則稱報文ACKx為部分應答（Partial ACK，簡稱PACK）；若ACKx恰好是PKTy的應答報文則稱報文ACKx為恢復應答（Recovery ACK，簡稱RACK）。

舉例來理解：
如果4、5、6號包丟了，現在只重傳4，只收到了4的ACK，後面的5、6沒有確認，這就是部分應答Partial ACK。如果收到了6的ACK，則是恢復應答Recovery ACK。

TCP發送端接收到恢復應答表明：經過重傳，TCP終端發送的所有報文都已經被接收端正確接收，網路已經從擁塞中恢復。

NewReno發送端在收到第一個Partial ACK時，並不會立即結束Fast-recovery，而會持續地重送Partial ACK之後的數據包，直到將所有遺失的數據包重送後才結束Fast-recovery。收到一個Partial ACK時，重傳定時器就復位。這使得NewReno的發送端在網路有大量數據包遺失時不需等待Timeout就能更正此錯誤，減少大量數據包遺失對傳輸效果造成的影響。

NewReno大約每一個RTT時間可重傳一個丟失的數據包，如果一個發送窗口有M個數據包丟失，TCP NewReno的快速恢復階段將持續M個RTT。

改進的快速恢復演算法具體步驟：

快速恢復是基於數據包守恆的原則，即同一時刻能在網路中傳輸的數據包是恆定的，只有當舊數據包離開網路後，才能發送新數據包進入網路。一個重復ACK不僅意味著有一個包丟失了，還表示有發送的數據包離開了網路，已經在接收區的緩沖區中，不再佔用網路資源，於是將擁塞窗口加一個數據包大小。

Reno和NewReno演算法仍存在的問題？
雖然NewReno可以解決大量數據包遺失的問題，但是NewReno在每個RTT時間只能一個數據包遺失的錯誤。為了更有效地處理大量數據包遺失的問題，另一個解決方法就是讓傳送端知道哪些已經被接收端收到，但用此方法必須同時修改傳送端和接收端的傳送機制。

缺乏SACK演算法時發送端只能選擇兩種恢復策略：

TCP SACK在TCP Reno基礎上增加了：

當一個窗口內有多個數據包丟失時：

減少了時延，提高了網路吞吐量，使更快地從擁塞狀態恢復。

SACK中加入了一個SACK選項（TCP option field），允許接收端在返回Duplicate ACK時，將已經收到的數據區段（連續收到的數據范圍）返回給發送端，數據區段與數據區段之間的間隔就是接收端沒有收到的數據。發送端就知道哪些數據包已經收到，哪些該重傳，因此SACK的發送端可以在一個RTT時間內重傳多個數據包。

整個TCP選項長度不超過40位元組，實際最多不超過4組邊界值。

通過一個wireshark示例來說明接收端的SACK行為:

上圖中ACK確認序列號為12421，SACK的塊左邊界值為13801，SACK的塊右邊界值為15181。明確了這三個參數的數值，我們基本上就可以計算出被丟棄的數據報的序列號和長度了。通過上圖所示的帶有SACK的數據報文，我們可以知道被丟棄的數據報文的TCP序列號為12422，其數據長度為13801-12421=1380B。

改進的快速恢復演算法：

【參考文獻】：
吳文紅，李向麗.TCP擁塞控制機制定量性能分析.計算機工程與應用.2008,44(18)
孫偉，溫濤，馮自勤，郭權.基於TCP NewReno的穩態吞吐量分析模型.計算機研究與發展.2010
陳琳，雙雪芹.TCP網路擁塞控制演算法比較研究.長江大學學報.2010,3
許豫飛，TCP擁塞控制演算法集齊性能評估.北京郵電大學.2005,3
劉擁民，年曉紅.對SACK擁塞控制演算法的研究.信息技術.2003,9
焦程波，竇睿彧，蘭巨龍.無線網路中選擇性重傳機制性能分析與改進.計算機應用研究.2007.3
James F.Kurose,Keith W.Ross，Computer Networking A Top-Down Approach Sixth Edition.機械工業出版社

原文： https://blog.csdn.net/m0_38068229/article/details/80417503

⑻ tcp擁塞控制常用演算法

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