❶ TCP(IV) 擁塞控制
網路中的路由器因無法處理高速到達的流量而被迫丟棄數據信息的現象稱為擁塞。這里可能是因為路由器緩存較小或者處理不及時，雖然和流量控制時接收方的情況相似，但是這里有本質區別。因為後者是一對一的，幾乎隻影響一條連接；後者則影響多個連接。
當網路中大量的發送方和接收方被要求承擔超負荷的通信任務時，可以採用 降低發送方發送速率 或者 丟棄部分數據 （也可二者結合）來降低擁塞。
通常來說，接收方沒有一個精確的方法去知道中間路由器的狀態。目前基本的方法有：
之前的文章提到，發送方為了適應接收方接受速度，設置了一個發送窗口來控制流量。同樣的，當擁堵發生時，也需要控制發送速率，於是引入了一個窗口變數，來反映網路傳輸能力，稱為 擁塞窗口 （Congestion window），記作 cwnd。很直觀的，我們可以知道，發送端實際可用窗口 W 表示如下,其中 awnd 表示接收方窗口大小：
W = min(cwnd, awnd)
也就是說，還沒有收到 ACK 的數據量（也稱在外數據量）不能多於 W 。通常 W 以位元組或包為單位。很明顯， W 的值是在隨時變化的，並且我們希望 W 接近一個最佳窗口大小——帶寬延時積（Bandwidth-Delay Proct, BDP）,BDP 表示某一時刻的在外數據量，但是確定一個連接的 BDP 也是一個難點。
當連接建立之初，還無法獲知可用的連接資源，也無法確定 cwnd 初始值（有例外，就是之前文章里提到的目的度量）。這時候不應該直接大量快速的向網路中發送數據，因為會造成更嚴重的網路擁堵。獲得 cwnd 最佳值的唯一方法就是以越來越快的速度發包，直到有數據包丟失（或網路擁堵）。可以考慮 慢啟動 發送。在討論具體演算法之前，需要先了解 數據包守恆 的概念。
TCP 發送端的擁塞控制行為是由 ACK 的接收來驅動或「控制」的。並且鏈路的傳輸能力是固定的，當發送方接收到一個 ACK 時，就表示鏈路上多了一個「空位」，於是發送方可以再發送一個數據包。數據包守恆就是指鏈路中最大包的數量守恆。
當一個連接剛啟動時，或者檢測到重傳超時導致的丟包時，需要執行慢啟動 ； TCP 長時間處於空閑狀態也可能觸發慢啟動。其目的是探尋到 cwnd 值已經幫助 TCP 建立 ACK 時鍾。
TCP 發送一定數目的報文開始慢啟動，該數目稱為初始窗口（IInitial Window，IW）。為了簡便，我們討論 IW 為一個 SMSS （sender's MSS）的情況。意味著初始 cwnd 大小為 1 SMSS。
假設沒有丟包且每一個數據都有相應的 ACK。那麼第一個 ACK 到達，說明可以再發送一個新的報文段（數據包守恆），每收到一個「好的」 ACK， cwnd = cwnd + min(N, SMSS) ，這里的 N 是指那個「好的」 ACK 所確認的位元組數。所謂「好的」是指 ACK 號使窗口更新了。
因為通常來說 N 的值等於 SMSS，使得 cwnd 在收到一個 ACK 後增大一倍。所以慢啟動實際上是以指數增長，在 K 輪之後，cwnd = 2^K。如下圖：
當接收方開啟延時 ACK，則發送方 cwnd 增長曲線如圖中藍色曲線，雖然起步看起來慢，但仍是指數增長。當然這對於帶寬延時積很大的網路來說，確實有所浪費，應該採用更好的辦法。
當然不可能讓窗口大小無限增長，否則會造成嚴重的網路擁堵直至網路癱瘓。在上述情況下，cwnd 將大幅減小（減至原值一半），也是慢啟動和 擁塞避免 的轉折點，與 慢啟動閾值 （slow start threshold, ssthresh）有關。
當 cwnd 達到 ssthresh 時，可能還有一些傳輸資源未被佔用。但這時候需要謹慎的試探，不能再以較快速度增大 cwnd。採用避免擁塞演算法，每接收到一個新的 ACK，cwnd 會做以下更新：
cwnd = cwnd + SMSS * SMSS / cwnd
假設 cwnd = k * SMSS，則可推導如下：
cwnd = cwnd + SMSS / k
發包來看像這樣：
通常認為擁塞避免階段 cwnd 呈線性增長，稱為累加增長。
通常 TCP 連接總是會選擇慢啟動和擁塞避免中的一個，依據就是之前提到的慢啟動閾值。當 cwnd < ssthresh，採用慢啟動演算法， cwnd > ssthresh 採用擁塞避免，相等時選擇任意都行。所以關鍵就是 ssthresh 的值，該值並不是固定的，它的主要目的是， 記錄上一次最好的窗口估計值 。
ssthresh 初始值可以任意設定（如 awnd 或更大），這通常會使 TCP 總是以慢啟動開始。當出現重傳，無論是超時重傳還是快速重傳，都會導致 ssthresh 值更新如下：
ssthresh = max(在外數據值 / 2, 2 * SMSS)
在外數據值其實就是當前窗口大小。這樣通常會使 ssthresh 變小（但也可能使其變大），然後觸發擁塞避免。
Tahoe 演算法規定當重傳時，都會進入慢啟動，並且丟包時，將 cwnd 設為 1 SMSS。這顯然性能不太好，已被棄用，不用深究。
Reno 演算法是標准 TCP 的基礎，它根據之前提到的「包守恆」實現了快速恢復，較好的利用了帶寬。快速恢復是針對快速重傳的情景實現的，來看一下它在標准 TCP 中的使用：
以下是 Reno 的狀態轉換圖：
Reno 演算法在同一窗口下丟失多個包時，其中一個包快速重傳成功，就會停止 cwnd 膨脹，造成其它丟失的包可能觸發超時重傳，然後 cwnd 降為 1 SMSS，吞吐量大大降低。NewReno 採用了一個「恢復點」，指的是收到的 ACK 號大於已發送包的序列號的最大值，達到這個恢復點，才會退出快速恢復。下圖最右圖中， ACK11 達到了恢復點。
限制傳輸策略對 TCP 做了微小改進，主要是為了解決窗口較小時，出現丟包，但是沒有足夠的包去引發快速重傳/快速恢復機制。為了盡快觸發快速重傳，每接收兩個連續重復 ACK，就發送一個新的包，使網路中的數據量維持一定數量。這是 TCP 推薦策略。
這里對應 TCP/IP 詳解卷一里，書上對於「應用受限」說法不正確。書上說此時「無法發送」，但是查閱 rfc 原文如下：
擁塞窗口校驗（Congestion Window Validation）機制規定，需要發送新數據時，距離上次發送操作超過一個 RTO，如果是：
在長時間發送暫停後，cwnd 低於 ssthresh，再次發送時會進入慢啟動。Linux 默認開啟 CWV。
在之前的超時重傳里，我們提到了 偽超時，再來回顧下(注意下圖是相當簡易的情形，沒有考慮延時 ACK 以及 cwnd 增長，會意即可)：
偽超時可能引起「回退 N 步」的行為，並且可能觸發快速重傳，浪費不少資源。
該演算法利用 TCP 的 TSOPT 選項，在發送生超時後，重傳報文並記錄 TSV，期待一個 ACK，若 ACK 的 TSER 小於重傳報文的 TSV，則認為該 ACK 是對原始報文的確認而不是對重傳報文的確認，即認定該重傳是偽重傳。
前面提到過，發生超時，則 ssthresh 減半，cwnd 降為 1 SMSS。發生偽超時的話，在 RTO 之後到來的 ACK 會使 cwnd 快速變大，但仍會有不必要重傳。
採用 Eifel 演算法，在判定偽超時後，會撤銷對 ssthresh 的修改。在每次超時對 ssthresh 修改之前，會用 pipe_prev 變數來保存當前的 ssthresh，以便撤銷修改。
若出現偽重傳，當 ACK 到達時，假設 ACK 確認的報文段長度為 A：
前面討論了當失序或者超時的時候 TCP 的行為，這些行為都是通過 ACK 的反饋來觸發或者驅動的，換句話說，這些「擁塞」的情況是「猜出來的」。當明確知道發生擁堵了，TCP 會執行 擁塞窗口縮減 （congestion window recing，CWR）。明確知道擁堵的情況主要有兩種：
CWR 處理過程如下：
直到 cwnd 達到新的 ssthresh 值或者由於其他原因（如丟包）打斷 CWR。
到此，我們總結一下 TCP 擁塞控制的幾個重要狀態：
這個問題還是很有趣的，所以拿出來講一下。先說結論，網路設備的緩沖區並不是越大越好，也不是越小越好，而是需要根據鏈路速率和RTT進行計算，得到一個經驗值。
緩沖區過小的問題很明顯，如果緩沖區太小，很容易就被寫滿了，只要不能進行適當的排隊，丟包率會高，導致傳輸效率差。
假設如下場景：
上圖中，我們假設中間的路由設備的buffer極大，理論來說無論來多少數據，都能buffer起來。中間的路由設備，接收速率是1M/s，而發送速率只有10k/s。
到某一時刻，發送方認為某一數據超時丟失（實際上沒有丟失，而是在緩沖區沒來得及處理），於是重發，導致緩存區有冗餘數據。大量的冗餘數據導致利用率變得極低。
而緩沖區為正常大小的時候，多的數據會被丟棄，過一會而緩沖區有新的位置，新的數據會到來，接收方收到數據是失序的，於是發送冗餘 ACK，促進快速重傳，反而使鏈路利用率得到保障。
大多數攻擊是強迫 TCP 發送速率比一般情況更快或更慢。
原理是接收方將原來的確認范圍劃分成很多小塊，把一個 ACK 變成多個 ACK，使得發送方不斷增大 cwnd，使網路變的擁堵。可以通過計算每個 ACK 的確認量（而不是一個包）來判斷是否是正確的 ACK。
接收方對還沒到達的數據進行提前確認，使得 RTT 變得比較小，同樣使得發送方不斷增大 cwnd。可以採用一個可累加的隨機數，動態匹配 ACK。
❷ 網路原理關於tcp擁塞窗口的一道題
發送窗口的上限值由min（接受窗口，擁塞窗口）決定，顯然發送窗口為2000。而第二個最大段沒有得到確認，所以還可以發送的最大位元組數為：2000-1000=1000.
❸ TCP擁塞窗口的問題
TCP擁塞控制最開始採用慢開始演算法，擁塞窗口值cwnd從1開始按指數增加，1、2、4、8（第1——4次的值）；這時達到了ssthresh的初始值8，轉而採用擁塞避免演算法，擁塞窗口值cwnd從ssthresh初始值8按線性+1增加，因此為9、10、11、12（第4——8次的值）；到了cwnd=12時網路發生超時，這時改ssthreash的值為發生超時時cwnd的值的一半（即為12/2=6），並重新採用慢開始演算法，改cwnd的值為1（這是第9次的值），然後cnwd的值依然按指數增加，2、4（第10、11次），理論上按這個演算法再增加就是cnwd=8了，超過了ssthresh=6，所以第12次開始改為擁塞避免演算法、cwnd的值從6開始按線性+1，即為6、7、8、9（第12——15次）。
純手打，希望能幫助你理解。
❹ 計算機網路里，建立TCP連接的三個TCP窗口分別是什麼rwnd，cwnd是嗎還有嗎謝謝！
擁塞控制：防止過多的數據注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提：網路能夠承受現有的網路負荷。擁塞控制是一個全局性的過程，涉及到所有的主機、路由器，以及與降低網路傳輸性能有關的所有因素。流量控制：指點對點通信量的控制，是端到端中的問題。流量控制所要做的就是抑制發送端發送數據的速率，以便使接收端來得及接收
❺ tcp如何實現擁塞控制
TCP擁塞控制是傳輸控制協議（英語：Transmission Control Protocol，縮寫TCP）避免網路擁塞的演算法，是互聯網上主要的一個擁塞控制措施。它使用一套基於線增積減模式的多樣化網路擁塞控制方法（包括慢啟動和擁塞窗口等模式）來控制擁塞。在互聯網上應用中有相當多的具體實現演算法。
在TCP中，擁塞窗口（congestion window）是任何時刻內確定能被發送出去的位元組數的控制因素之一，是阻止發送方至接收方之間的鏈路變得擁塞的手段。他是由發送方維護，通過估計鏈路的擁塞程度計算出來的，與由接收方維護的接收窗口大小並不沖突。
1、慢開始演算法：
簡單的說，開始傳輸時，傳輸的數據由小到大遞增到一個值(即發送窗口由小到大(指數增長)逐漸增大到擁塞窗口的數值)。
2、擁塞避免演算法：
數據發送出去，並發到接收方發回來的確認收到，擁塞窗口每次值加1地線性增大。
3、快重傳演算法：
數據傳輸時(數據被分成報文，每個報文都有個序號)，中間的一部分丟失接收方沒收到，接收方連續接到後面的數據，則發回對丟失前的數據的重復確認，這樣發送方就知道有部分數據丟失了，於是從丟失出重傳數據。
4、快恢復演算法：
快恢復是與快重傳配合的演算法，在發生數據丟失時，發送方收到接收方發回的三個重復確認信息時，就把每次傳輸的數據量減為原來的一半，擁塞窗口也修改為這個值,然後又開始擁塞避免的演算法。
❻ TCP 流量控制與擁塞控制
TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連接的、可靠的、基於位元組流的。為了通過IP數據報實現可靠性傳輸，需要考慮很多事情，側如數據的破壞、丟包、重復以及分片順序混亂等問題。如不能解決這些問題，也就無從談起可靠傳輸。 TCP通過校驗和、序列號、確認應答、重發控制、連接管理、以及窗口控制等機制來實現可靠性傳輸 。TCP建立連接的實質是，主機A和主機B告知彼此的第一個發送位元組的初始序列號，建立連接後對每一個發送的位元組都需要以初始序列號為基點進行編號，需要對方來確認每一個位元組編號都已經成功接收，雙方初始序列號是由操作系統動態生成的隨機的值，一般每個TCP 會話都會有不一樣的初始序列號，佔四個位元組。
TCP通過肯定的確認應答(ACK) 實現可靠的數據傳輸。當發送端將數據發出之後會等待對端的確認應答。如果有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。在一定時間內沒有等到確認應答，發送端就可以認為數據已經丟失，並進行重發由此，即使產生了丟包，仍然能夠保證數據能夠到達對端，實現可靠傳輸。如果數據被重發之後若還是收不到確認應答，則進行再次發送。此時確認應答的時間將會以2倍、4信的指數函數延長。達到一定次數後，如果任沒有任何確認應答返回，就會判斷為網路發生異常，強制關閉連接，並且通知應用通信異常強行終止。
發送端根據自己的實際情況發送數據。但是，接收端可能收到的是一個毫無
關系的數據包又可能會在處理其他問題上花費一些時間。因此在為這個數據包做其他處理時會耗費一些時間，甚至在高負荷的情況下無法接收任何數據。如此一來，如果接收端將本應該接收的數據丟棄的話，就又會觸發重發機制，從而導致網路流量的無端浪費。為了防止這種現象的發生，TCP 提供一種機制可以讓發送端根據接收端的實際接收能力控制發送的數據量。這就是所謂的 流控制。它的具體操作是，接收端主機向發送端主機通知自己可以接收數據的大小，於是發送端會發送不超過這個限度的數據。該大小限度就被稱作窗口大小 。在前面6.4.6 節中所介紹的窗口大
小的值就是由接收端主機決定的。TCP 首部中，專門有一個欄位用來通知窗口大小。接收主機將自己可以接收的緩沖區大小放人這個欄位中通知給發送端。這個欄位的值越大，說明網路的吞吐量越高。不過，接收端的這個緩沖區一旦面臨數據溢出時，窗口大小的值也會隨之被設置為一個更小的值通知給發送端，從而控制數據發送量。也就是說，發送端主機會根據接收端主機的指示，對發送數據的量進行控制。這也就形成了一個完整的TCP 流控制(流量控制)。
因為 TCP 的窗口控制，收發主機之間即使不再以一個數據段為單位發送確認應答，也能夠連續發送大量數據包。然而，如果在通信剛開始時就發送大量數據，也可能會引發其他問題。 一般來說，計算機網路都處在一個共享的環境。因此也有可能會因為其他主機之間的通信使得網路擁堵。在網路出現擁堵時，如果突然發送一個較大量的數據，極有可能會導致整個網路的癱瘓。TCP 為了防止該問題的出現，在通信一開始時就會通過一個叫做慢啟動的演算法得出的數值，對發送數據量進行控制 。首先，為了在發送端調節所要發送數據的量，定義了一個叫做「擁塞窗口」的概念。於是在慢啟動的時候，將這個擁塞窗口的大小設置為1個數據段發送數據，之後每收到一次確認應答(ACK)，擁塞窗口的值就加1MSS。在發送數據包時，將擁塞窗D的大小與接收端主機通知的窗口大小做比較，然後按照它們當中較小那個值，發送比其還要小的數據量。如果重發採用超時機制，那麼擁塞窗口的初始值可以設置為1以後再進行慢啟動修正。有了上述這些機制，就可以有效地減少通信開始時連續發包導致的網路擁堵，還可以避免網路擁塞情況的發生。
慢啟動演算法的基本思想是當TCP開始在一個網路中傳輸數據或發現數據丟失並開始重發時，首先慢慢的對網路實際容量進行試探，避免由於發送了過量的數據而導致阻塞。主機發送了一個報文後就要停下來等待應答，每收到一個應答，擁塞窗口就增加一段長度，直至等於設定的閾值。比如我們可以先讓發送方發一個包，等這個包被 ack 之後，我們再發 2 個包，這 2 個被 ack 之後再發 4 個包，以此類推，讓一次所發的包數量慢慢增加，這就是慢啟動。
談 TCP 離不開 窗口的概念，有 congestion window，receive window，sliding window 等等。window 是以 tcp segment 數量為單位，我們可以說當前 window 值由幾個 tcp 包構成，而當我們說 window size 的時候，又是在說一個 window 所包含的位元組數。window size 除了和 tcp segment 的數量有關之外，還和單個 tcp segment 的最大 size 有關，即 MSS 值。發送方的 Window 大小稱之為 CWND（congestion window），接收方的 Window 大小稱之為 RWND（receiver window，或 advertised window）。CWND 表示當前發送方可以發送多少個 TCP 包，而 RWND 表示當前接收方還能接收多少個 TCP 包。值得注意的是，CWND 是一個發送方本地的值，並不會在網路上傳輸。而 RWND 則是由接收方告知發送方的，是存在於 TCP 包的協議中，會通過網路傳輸。比如，A主機發送給B window 大小為8192，意思是：B主機最多可以連續發送8192 位元組給A主機（一般來說，8192位元組就是A主機的接收緩沖區大小），如果B主機不小心發送超過8192位元組，如果application 沒有及時取走，則超過 8192 自己數據可能會因為A主機的接收緩沖區滿而被丟棄，所以B主機會嚴格遵守A的 RWND 的大小，如果A主機通告它的window大小為 0，則B主機一定不會發送數據。TCP首部中 Window Size 占兩個byte，最大值為65535。
MTU： Maximum Transmit Unit，最大傳輸單元，即物理介面（數據鏈路層）提供給其上層（通常是IP層）最大一次傳輸數據的大小；以普遍使用的乙太網介面為例，預設MTU=1500 Byte，這是乙太網介面對IP層的約束，如果IP層有<=1500 byte 需要發送，只需要一個IP包就可以完成發送任務；如果IP層有> 1500 byte 數據需要發送，需要分片才能完成發送，這些分片有一個共同點，即IP Header ID相同。
MSS：Maximum Segment Size ，TCP提交給IP層最大分段大小，不包含TCP Header和 TCP Option，只包含TCP Payload ，MSS是TCP用來限制application層最大的發送位元組數。如果底層物理介面MTU= 1500 byte，則 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte，如果application 有2000 byte發送，需要兩個segment才可以完成發送，第一個TCP segment = 1460，第二個TCP segment = 540。
Persist Timer: 用於周期探測對方receiver window size 是否依然為0的定時器。比如，A主機通告它的window大小為 0，則B一定不會發送數據。B主機也不會一直等下去，如果一直等下去則會發生死鎖。為了防止這種情況的死鎖發生，發送者使用了一個持續計時器（persiet timer）來周期性的詢問接收者是否已增加了窗口。從發送者發出的這些段稱為窗口探測（window probes）。
在iOS設備上抓包比較方便，除了常用的，如：Charles、Paw 等軟體外，我們還可以使用tcpmp。以下是抓包的步驟：
（待續）
❼ 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開始開始。
❽ 計算機網路，傳輸層擁塞控制小問題。謝謝。 假設在沒有發生擁塞的情況下，在一條往返時延RTT為10m
擁塞窗口初始值=1個TCP報文= 2 K B < 24 K B =2KB<24KB=2KB<24KB，發送窗口=min{擁塞窗口，接收窗口}，採用慢啟動演算法：
T=0，第1次發送，發送窗口=擁塞窗口=2KB；
t=10ms，得到確認，擁塞窗口=4KB
T=10ms，第2次發送，發送窗口=4KB；
t=20ms，得到確認，擁塞窗口=8KB
T=20ms，第3次發送，發送窗口=8KB；
t=30ms，得到確認，擁塞窗口=16KB
T=30ms，第4次發送，發送窗口=16KB；
t=40ms，得到確認，擁塞窗口=32KB
T=40ms，第5次發送，發送窗口=min{擁塞窗口，接收窗口}=24KB；
因此，需要40ms才能發送第一個完全窗口。