快速重傳演算法

⑴ 快重傳和快恢復的簡介

協議
在TCP/IP中，快速重傳和恢復（fast retransmit and recovery，FRR）是一種擁塞控制演算法，它能快速恢復丟失的數據包。沒有FRR，如果數據包丟失了，TCP將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或復制的數據包被發送。有了FRR，如果接收機接收到一個不按順序的數據段，它會立即給發送機發送一個重復確認。如果發送機接收到三個重復確認，它會假定確認件指出的數據段丟失了，並立即重傳這些丟失的數據段。有了FRR，就不會因為重傳時要求的暫停被耽誤。 當有單獨的數據包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數據信息包在某一段很短的時間內丟失時，它則不能很有效地工作。快速重傳快速恢復演算法是在4.3BSD Reno中提出的，並在RFC 2001和RFC2581中描述。 FRR也指誤拒絕率（false rejection rate），一個在生物安全系統中使用的術語。

⑵ TCP超時重傳機制的重傳

有了超時就要有重傳，但是就算是重傳也是有策略的，而不是將數據簡單的發送。 前面曾經提到過，數據在傳輸的時候不能只使用一個窗口協議，還需要有一個擁塞窗口來控制數據的流量，使得數據不會一下子都跑到網路中引起「擁 塞」。也曾經提到過，擁塞窗口最初使用指數增長的速度來增加自身的窗口，直到發生超時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免演算法和 慢啟動門限就是為此而生。
所謂的慢啟動門限就是說，當擁塞窗口超過這個門限的時候，就使用擁塞避免演算法，而在門限以內就採用慢啟動演算法。所以這個標准才叫做門限，通常，擁塞窗口記做cwnd，慢啟動門限記做ssthresh。下面來看看擁塞避免和慢啟動是怎麼一起工作的。 這是數據丟包的情況下給出的一種修補機制。一般來說，重傳發生在超時之後，但是如果發送端接受到3個以上的重復ACK的情況下，就應該意識到，數據丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，它可以避免發送端因等待重傳計時器的超時而空閑較長時間，以此增加網路吞吐量。而重新傳遞以後，因為走的不是慢啟動而是擁塞避免演算法，所以這又叫做快速恢復演算法。流程如下：
當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半。重傳丟失的 報文段。設置cwnd為ssthresh加上3倍的報文段大小。每次收到另一個重復的ACK時， cwnd增加1個報文段大小並發送1個分組（如果新的 cwnd允許發送）。當下一個確認新數據的ACK到達時，設置cwnd為ssthresh（在第1步中設置的值）。這個 ACK應該是在進行重傳後的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該是對丟失的分組和收到的第1個重復的ACK之間的所有中間報文段 的確認。這一步採用的是擁塞避免。ICMP不會引起重新傳遞，TCP會堅持用自己的定時器，但是TCP會保留下ICMP的錯誤並且通知用戶。 TCP為了提高自己的效率，允許再重新傳輸的時候，只要傳輸包含重傳數據報文的報文就可以，而不用只重傳需要傳輸的報文。

⑶ tcp協議通過什麼來區分不同的連接

TCP/IP
不同的計算機系統，就好像語言不同的兩個人互相見了面，完全不能交流信息。因而他們需要定義一些共通的東西來進行交流，TCP/IP就是為此而生。TCP/IP不是一個協議，而是一個協議族的統稱。裡麵包括了IP協議，IMCP協議，TCP協議，以及我們更加熟悉的http、ftp、pop3協議等等。電腦有了這些，就好像學會了外語一樣，就可以和其他的計算機終端做自由的交流了。
TCP/IP 層次
應用層(http、ftp、smtp) -->傳輸層(TCP、UDP)-->網路層(IP)-->數據鏈路層
域名系統 :域名系統是一個分布的資料庫，它提供將主機名（就是網址啦）轉換成IP地址的服務。
埠號(port): 注意，這個號碼是用在TCP，UDP上的一個邏輯號碼，並不是一個硬體埠，我們平時說把某某埠封掉了，也只是在IP層次把帶有這個號碼的IP包給過濾掉了而已。
應用編程介面:現在常用的編程介面有socket和TLI。
數據鏈路層
數據鏈路層有三個目的：
為IP模塊發送和 接收IP數據報。
為ARP模塊發送ARP請求和接收ARP應答。
為RARP發送RARP請 求和接收RARP應答
ip大家都聽說過。至於ARP和RARP，ARP叫做地址解析協議，是用IP地址換MAC地址的一種協議，而RARP則叫做逆地址解析協議.
--
IP 、ARP 、RARP 協議
三者都是在網路層 ，ARP協議用來找到目標主機的Ethernet網卡Mac地址，IP則承載要發送的消息。數據鏈路層可以從ARP得到數據的傳送信息，而從IP得到要傳輸的數據信息。
IP 協議
IP協議是TCP/IP協議的核心，所有的TCP，UDP，IMCP，IGCP的數據都以IP數據格式傳輸。要注意的是，IP不是可靠的協議，這是說，IP協議沒有提供一種數據未傳達以後的處理機制－－這被認為是上層協議：TCP或UDP要做的事情。所以這也就出現了TCP是一個可靠的協議，而UDP就沒有那麼可靠的區別。

協議頭
八位的TTL欄位，還記得這個欄位是做什麼的么？這個欄位規定該數據包在穿過多少個路由之後才會被拋棄(這里就體現出來IP協議包的不可靠性，它不保證數據被送達)，某個ip數據包每穿過一個路由器，該數據包的TTL數值就會減少1，當該數據包的TTL成為零，它就會被自動拋棄。這個欄位的最大值也就是255，也就是說一個協議包也就在路由器裡面穿行255次就會被拋棄了，根據系統的不同，這個數字也不一樣，一般是32或者是64，Tracerouter這個工具就是用這個原理工作的，tranceroute的-m選項要求最大值是255，也就是因為這個TTL在IP協議裡面只有8bit。
現在的ip版本號是4，所以也稱作IPv4。現在還有IPv6，而且運用也越來越廣泛了。
IP路由選擇
當一個IP數據包準備好了的時候，IP數據包（或者說是路由器）是如何將數據包送到目的地的呢？它是怎麼選擇一個合適的路徑來"送貨"的呢？
最特殊的情況是目的主機和主機直連，那麼主機根本不用尋找路由，直接把數據傳遞過去就可以了。至於是怎麼直接傳遞的，這就要靠ARP協議了。
稍微一般一點的情況是，主機通過若干個路由器(router)和目的主機連接。那麼路由器就要通過ip包的信息來為ip包尋找到一個合適的目標來進行傳遞，比如合適的主機，或者合適的路由。路由器或者主機將會用如下的方式來處理某一個IP數據包
如果IP數據包的TTL（生命周期）以到，則該IP數據包就被拋棄。
搜索路由表，優先搜索匹配主機，如果能找到和IP地址完全一致的目標主機，則將該包發向目標主機
搜索路由表，如果匹配主機失敗，則匹配同子網的路由器，這需要「子網掩碼(1.3.)」的協助。如果找到路由器，則將該包發向路由器。
搜索路由表，如果匹配同子網路由器失敗，則匹配同網號路由器，如果找到路由器，則將該包發向路由器。
搜索路由表，如果以上都失敗了，就搜索默認路由，如果默認路由存在，則發包
如果都失敗了，就丟掉這個包
這再一次證明了，ip包是不可靠的。因為它不保證送達。
ARP協議
還記得數據鏈路層的乙太網的協議中，每一個數據包都有一個MAC地址頭么？我們知道每一塊乙太網卡都有一個MAC地址，這個地址是唯一的，那麼IP包是如何知道這個MAC地址的？這就是ARP協議的工作。
ARP（地址解析）協議是一種解析協議，本來主機是完全不知道這個IP對應的是哪個主機的哪個介面，當主機要發送一個IP包的時候，會首先查一下自己的ARP高速緩存（就是一個IP-MAC地址對應表緩存），如果查詢的IP－MAC值對不存在，那麼主機就向網路發送一個ARP協議廣播包，這個廣播包裡面就有待查詢的IP地址，而直接收到這份廣播的包的所有主機都會查詢自己的IP地址，如果收到廣播包的某一個主機發現自己符合條件，那麼就准備好一個包含自己的MAC地址的ARP包傳送給發送ARP廣播的主機，而廣播主機拿到ARP包後會更新自己的ARP緩存（就是存放IP-MAC對應表的地方）。發送廣播的主機就會用新的ARP緩存數據准備好數據鏈路層的的數據包發送工作。
arp -a 可以查詢自己的arp緩存
這樣的高速緩存是有時限的，一般是20分鍾（伯克利系統的衍生系統）。
--
ICMP協議
--
UDP 協議
UDP是傳輸層協議，和TCP協議處於一個分層中，但是與TCP協議不同，UDP協議並不提供超時重傳，出錯重傳等功能，也就是說其是不可靠的協議。
1 、UDP 的埠號
由於很多軟體需要用到UDP協議，所以UDP協議必須通過某個標志用以區分不同的程序所需要的數據包。埠號的功能就在於此，例如某一個UDP程序A在系統中注冊了3000埠，那麼，以後從外面傳進來的目的埠號為3000的UDP包都會交給該程序。埠號理論上可以有2^16這么多。因為它的長度是16個bit
2 、UDP 的檢驗和
這是一個可選的選項，並不是所有的系統都對UDP數據包加以檢驗和數據(相對TCP協議的必須來說)，但是RFC中標准要求，發送端應該計算檢驗和。
UDP檢驗和覆蓋UDP協議頭和數據，這和IP的檢驗和是不同的，IP協議的檢驗和只是覆蓋IP數據頭，並不覆蓋所有的數據。UDP和TCP都包含一個偽首部，這是為了計算檢驗和而攝制的。偽首部甚至還包含IP地址這樣的IP協議裡面都有的信息，目的是讓UDP兩次檢查數據是否已經正確到達目的地。如果發送端沒有打開檢驗和選項，而接收端計算檢驗和有差錯，那麼UDP數據將會被悄悄的丟掉（不保證送達），而不產生任何差錯報文。
3 、UDP 的長度
UDP可以很長很長，可以有65535位元組那麼長。但是一般網路在傳送的時候，一次一般傳送不了那麼長的協議（涉及到MTU的問題），就只好對數據分片，當然，這些是對UDP等上級協議透明的，UDP不需要關心IP協議層對數據如何分片。
4 、IP 分片
IP在從上層接到數據以後，要根據IP地址來判斷從那個介面發送數據（通過選路），並進行MTU的查詢，如果數據大小超過MTU就進行數據分片。數據的分片是對上層和下層透明，而數據也只是到達目的地還會被重新組裝，不過不用擔心，IP層提供了足夠的信息進行數據的再組裝。
在IP頭裡面，16bit識別號唯一記錄了一個IP包的ID,具有同一個ID的IP片將會被重新組裝；而13位片偏移則記錄了某IP片相對整個包的位置；而這兩個表示中間的3bit標志則標示著該分片後面是否還有新的分片。這三個標示就組成了IP分片的所有信息，接受方就可以利用這些信息對IP數據進行重新組織（就算是後面的分片比前面的分片先到，這些信息也是足夠了）。
因為分片技術在網路上被經常的使用，所以偽造IP分片包進行流氓攻擊的軟體和人也就層出不窮。
5 、ICMP源站抑制差錯
當目標主機的處理速度趕不上數據接收的速度，因為接受主機的IP層緩存會被占滿，所以主機就會發出一個「我受不了」的一個ICMP報文。
--
單播廣播和多播
單播
單播是說，對特定的主機進行數據傳送。例如給某一個主機發送IP數據包。這時候，數據鏈路層給出的數據頭裡面是非常具體的目的地址，對於乙太網來 說，就是網卡的MAC地址（不是FF-FF-FF-FF-FF-FF這樣的地址）。現在的具有路由功能的主機應該可以將單播數據定向轉發，而目的主機的網 絡介面則可以過濾掉和自己MAC地址不一致的數據。
廣播
廣播是主機針對某一個網路上的所有主機發送數據包。這個網路可能是網路，可能是子網，還可能是所有的子網。如果是網路，例如A類網址的廣播就是 netid.255.255.255，如果是子網，則是netid.netid.subnetid.255；如果是所有的子網（B類IP）則是則是 netid.netid.255.255。廣播所用的MAC地址FF-FF-FF-FF-FF-FF。網路內所有的主機都會收到這個廣播數據，網卡只要把 MAC地址為FF-FF-FF-FF-FF-FF的數據交給內核就可以了。一般說來ARP，或者路由協議RIP應該是以廣播的形式播發的。
多播
可以說廣播是多播的特例，多播就是給一組特定的主機（多播組）發送數據，這樣，數據的播發范圍會小一些(實際上播發的范圍一點也沒有變小)，多播的MAC地址是最高位元組的低位為一，例 如01-00-00-00-00-00。多播組的地址是D類IP，規定是224.0.0.0-239.255.255.255。
雖然多播比較特殊，但是究其原理，多播的數據還是要通過數據鏈路層進行MAC地址綁定然後進行發送。所以一個乙太網卡在綁定了一個多播IP地址之後，必 定還要綁定一個多播的MAC地址，才能使得其可以像單播那樣工作。這個多播的IP和多播MAC地址有一個對應的演算法，在書的p133到p134之間。可以看到 這個對應不是一一對應的，主機還是要對多播數據進行過濾。
--
TCP
TCP和UDP處在同一層---運輸層，但是TCP和UDP最不同的地方是，TCP提供了一種可靠的數據傳輸服務，TCP是面向連接的，也就是說，利用TCP通信的兩台主機首先要經歷一個「撥打電話」的過程，等到通信准備結束才開始傳輸數據，最後結束通話。所以TCP要比UDP可靠的多，UDP是把數據直接發出去，而不管對方是不是在收信，就算是UDP無法送達，也不會產生ICMP差錯報文，這一經時重申了很多遍了。
把TCP保證可靠性的簡單工作原理:
應用數據被分割成TCP認為最適合發送的數據塊。這和UDP完全不同，應用程序產生的 數據報長度將保持不變。由TCP傳遞給IP的信息單位稱為報文段或段
當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能 及時收到一個確認，將重發這個報文段.
當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒.
TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸 過程中的任何變化。如果收到段的檢驗和有差錯， T P將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發）。
既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段 的到達也可能會失序。如果必要， TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。
TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發送接收端緩沖區所能接納的數據。這將防止較快主機致使較慢主機的緩沖區溢出。
從這段話中可以看到，TCP中保持可靠性的方式就是超時重發，這是有道理的，雖然TCP也可以用各種各樣的ICMP報文來處理這些，但是這也不是可靠的，最可靠的方式就是只要不得到確認，就重新發送數據報，直到得到對方的確認為止。
TCP的首部和UDP首部一樣，都有發送埠號和接收埠號。但是顯然，TCP的首部信息要比UDP的多，可以看到，TCP協議提供了發送和確認所需要的所有必要的信息。可以想像一個TCP數據的發送應該是如下的一個過程。
雙方建立連接
發送方給接受方TCP數據報，然後等待對方的確認TCP數據報，如果沒有，就重新發，如果有，就發送下一個數據報。
接受方等待發送方的數據報，如果得到數據報並檢驗無誤，就發送ACK(確認)數據報，並等待下一個TCP數據報的到來。直到接收到FIN(發送完成數據報)
中止連接
可以想見，為了建立一個TCP連接，系統可能會建立一個新的進程（最差也是一個線程），來進行數據的傳送
--
TCP協議
TCP是一個面向連接的協議，在發送輸送之前 ，雙方需要確定連接。而且，發送的數據可以進行TCP層的分片處理。
TCP連接的建立過程 ，可以看成是三次握手 。而連接的中斷可以看成四次握手 。
1.連接的建立
在建立連接的時候，客戶端首先向伺服器申請打開某一個埠(用SYN段等於1的TCP報文)，然後伺服器端發回一個ACK報文通知客戶端請求報文收到，客戶端收到確認報文以後再次發出確認報文確認剛才伺服器端發出的確認報文（繞口么），至此，連接的建立完成。這就叫做三次握手。如果打算讓雙方都做好准備的話，一定要發送三次報文，而且只需要三次報文就可以了。
可以想見，如果再加上TCP的超時重傳機制，那麼TCP就完全可以保證一個數據包被送到目的地。
2.結束連接
TCP有一個特別的概念叫做half-close，這個概念是說，TCP的連接是全雙工（可以同時發送和接收）連接，因此在關閉連接的時候，必須關閉傳和送兩個方向上的連接。客戶機給伺服器一個FIN為1的TCP報文，然後伺服器返回給客戶端一個確認ACK報文，並且發送一個FIN報文，當客戶機回復ACK報文後（四次握手），連接就結束了。
3.最大報文長度
在建立連接的時候，通信的雙方要互相確認對方的最大報文長度(MSS)，以便通信。一般這個SYN長度是MTU減去固定IP首部和TCP首部長度。對於一個乙太網，一般可以達到1460位元組。當然如果對於非本地的IP，這個MSS可能就只有536位元組，而且，如果中間的傳輸網路的MSS更加的小的話，這個值還會變得更小。
4.客戶端應用程序的狀態遷移圖
客戶端的狀態可以用如下的流程來表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情況下應該有的流程，從書中的圖中可以看到，在建立連接時，當客戶端收到SYN報文的ACK以後，客戶端就打開了數據交互地連接。而結束連接則通常是客戶端主動結束的，客戶端結束應用程序以後，需要經歷FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束連接的四次握手。
5.伺服器的狀態遷移圖
伺服器的狀態可以用如下的流程來表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立連接的時候，伺服器端是在第三次握手之後才進入數據交互狀態，而關閉連接則是在關閉連接的第二次握手以後（注意不是第四次）。而關閉以後還要等待客戶端給出最後的ACK包才能進入初始的狀態。
6.TCP伺服器設計
前面曾經講述過UDP的伺服器設計，可以發現UDP的伺服器完全不需要所謂的並發機制，它只要建立一個數據輸入隊列就可以。但是TCP不同，TCP伺服器對於每一個連接都需要建立一個獨立的進程（或者是輕量級的，線程），來保證對話的獨立性。所以TCP伺服器是並發的。而且TCP還需要配備一個呼入連接請求隊列（UDP伺服器也同樣不需要），來為每一個連接請求建立對話進程，這也就是為什麼各種TCP伺服器都有一個最大連接數的原因。而根據源主機的IP和埠號碼，伺服器可以很輕松的區別出不同的會話，來進行數據的分發。
TCP的交互數據流
對於交互性要求比較高的應用，TCP給出兩個策略來提高發送效率和減低網路負擔：（1）捎帶ACK。(2)Nagle演算法（一次盡量多的發數據）
捎帶ACK的發送方式
這個策略是說，當主機收到遠程主機的TCP數據報之後，通常不馬上發送ACK數據報，而是等上一個短暫的時間，如果這段時間裡面主機還有發送到遠程主機的TCP數據報，那麼就把這個ACK數據報「捎帶」著發送出去，把本來兩個TCP數據報整合成一個發送。一般的，這個時間是200ms。可以明顯地看到這個策略可以把TCP數據報的利用率提高很多。
Nagle演算法
上過bbs的人應該都會有感受，就是在網路慢的時候發貼，有時鍵入一串字元串以後，經過一段時間，客戶端「發瘋」一樣突然回顯出很多內容，就好像數據一下子傳過來了一樣，這就是Nagle演算法的作用。
Nagle演算法是說，當主機A給主機B發送了一個TCP數據報並進入等待主機B的ACK數據報的狀態時，TCP的輸出緩沖區裡面只能有一個TCP數據報，並且，這個數據報不斷地收集後來的數據，整合成一個大的數據報，等到B主機的ACK包一到，就把這些數據「一股腦」的發送出去。雖然這樣的描述有些不準確，但還算形象和易於理解，我們同樣可以體會到這個策略對於低減網路負擔的好處。
在編寫插口程序的時候，可以通過TCP_NODELAY來關閉這個演算法。並且，使用這個演算法看情況的，比如基於TCP的X窗口協議，如果處理滑鼠事件時還是用這個演算法，那麼「延遲」可就非常大了。
2.TCP的成塊數據流
對於FTP這樣對於數據吞吐量有較高要求的要求，將總是希望每次盡量多的發送數據到對方主機，就算是有點「延遲」也無所謂。TCP也提供了一整套的策略來支持這樣的需求。TCP協議中有16個bit表示「窗口」的大小，這是這些策略的核心。
2.1.傳輸數據時ACK的問題
在解釋滑動窗口前，需要看看ACK的應答策略，一般來說，發送端發送一個TCP數據報，那麼接收端就應該發送一個ACK數據報。但是事實上卻不是這樣，發送端將會連續發送數據盡量填滿接受方的緩沖區，而接受方對這些數據只要發送一個ACK報文來回應就可以了，這就是ACK的累積特性，這個特性大大減少了發送端和接收端的負擔。
2.2.滑動窗口
滑動窗口本質上是描述接受方的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報，那麼發送方將停止發送數據，等到接受方發送窗口大小不為0的數據報的到來。
2.3.數據擁塞
上面的策略用於區域網內傳輸還可以，但是用在廣域網中就可能會出現問題，最大的問題就是當傳輸時出現了瓶頸（比如說一定要經過一個slip低速鏈路）所產生的大量數據堵塞問題（擁塞），為了解決這個問題，TCP發送方需要確認連接雙方的線路的數據最大吞吐量是多少。這，就是所謂的擁塞窗口。
擁塞窗口的原理很簡單，TCP發送方首先發送一個數據報，然後等待對方的回應，得到回應後就把這個窗口的大小加倍，然後連續發送兩個數據報，等到對方回應以後，再把這個窗口加倍（先是2的指數倍，到一定程度後就變成現行增長，這就是所謂的慢啟動），發送更多的數據報，直到出現超時錯誤，這樣，發送端就了解到了通信雙方的線路承載能力，也就確定了擁塞窗口的大小，發送方就用這個擁塞窗口的大小發送數據。要觀察這個現象是非常容易的，我們一般在下載數據的時候，速度都是慢慢「沖起來的」
--
TCP的超時和重傳
超時重傳是TCP協議保證數據可靠性的另一個重要機制，其原理是在發送某一個數據以後就開啟一個計時器，在一定時間內如果沒有得到發送的數據報的ACK報文，那麼就重新發送數據，直到發送成功為止。
超時
超時時間的計算是超時的核心部分，TCP要求這個演算法能大致估計出當前的網路狀況，雖然這確實很困難。要求精確的原因有兩個：(1)定時長久會造成網路利用率不高。(2)定時太短會造成多次重傳，使得網路阻塞。所以，書中給出了一套經驗公式，和其他的保證計時器准確的措施。
計時器的使用
一個連接中，有且僅有一個測量定時器被使用。也就是說，如果TCP連續發出3組數據，只有一組數據會被測量。
ACK數據報不會被測量，原因很簡單，沒有ACK的ACK回應可以供結束定時器測量。
重傳
前面曾經提到過，數據在傳輸的時候不能只使用一個窗口協議，我們還需要有一個擁塞窗口來控制數據的流量，使得數據不會一下子都跑到網路中引起「擁塞」。也曾經提到過，擁塞窗口最初使用指數增長的速度來增加自身的窗口，直到發生超時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免演算法和慢啟動門限就是為此而生。
所謂的慢啟動門限就是說，當擁塞窗口超過這個門限的時候，就使用擁塞避免演算法，而在門限以內就採用慢啟動演算法。所以這個標准才叫做門限，通常，擁塞窗口記做cwnd，慢啟動門限記做ssthresh。下面我們來看看擁塞避免和慢啟動是怎麼一起工作的
演算法概要
對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個位元組。
TCP輸出常式的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發送方使用 的流量控制，而通告窗口則是接收方進行的流量控制。前者是發送方感受到的網路擁塞的估 計，而後者則與接收方在該連接上的可用緩存大小有關。
當擁塞發生時（超時或收到重復確認），ssthresh被設置為當前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設置為1個報文段（這就是慢啟動）。
當新的數據被對方確認時，就增加cwnd，但增加的方法依賴於我們是否正在進行慢啟 動或擁塞避免。如果cwnd小於或等於ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。 慢啟動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因為我們記錄了在步驟2 中給我們製造麻煩的窗口大小的一半），然後轉為執行擁塞避免。
快速重傳和快速恢復演算法
這是數據丟包的情況下給出的一種修補機制。一般來說，重傳發生在超時之後，但是如果發送端接受到3個以上的重復ACK的情況下，就應該意識到，數據丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，而重新傳遞以後，因為走的不是慢啟動而是擁塞避免演算法，所以這又叫做快速恢復演算法。流程如下：
當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半。重傳丟失的 報文段。設置cwnd為ssthresh加上3倍的報文段大小。
每次收到另一個重復的ACK時， cwnd增加1個報文段大小並發送1個分組（如果新的 cwnd允許發送）。
當下一個確認新數據的ACK到達時，設置cwnd為ssthresh（在第1步中設置的值）。這個 ACK應該是在進行重傳後的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該 是對丟失的分組和收到的第1個重復的ACK之間的所有中間報文段的確認。這一步採用的是擁 塞避免，因為當分組丟失時我們將當前的速率減半。
TCP的其它定時器
堅持定時器
用於防止通告窗口為0以後雙方互相等待死鎖的情況
堅持定時器的原理是簡單的，當TCP伺服器收到了客戶端的0滑動窗口報文的時候，就啟動一個定時器來計時，並在定時器溢出的時候向向客戶端查詢窗口是否已經增大，如果得到非零的窗口就重新開始發送數據，如果得到0窗口就再開一個新的定時器准備下一次查詢。通過觀察可以得知，TCP的堅持定時器使用1，2，4，8，16……64秒這樣的普通指數退避序列來作為每一次的溢出時間。
2.保活定時器
保活定時器更加的簡單，還記得FTP或者Http伺服器都有Sesstion Time機制么？因為TCP是面向連接的，所以就會出現只連接不傳送數據的「半開放連接」，伺服器當然要檢測到這種連接並且在某些情況下釋放這種連接，這就是保活定時器的作用。其時限根據伺服器的實現不同而不通。另外要提到的是，當其中一端如果崩潰並重新啟動的情況下，如果收到該端「前生」的保活探察，則要發送一個RST數據報文幫助另一端結束連接。

⑷ 快重傳和快恢復的介紹

為了防止網路的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由「慢啟動(Slow start)」和「擁塞避免(Congestion avoidance)」組成，後來TCP Reno版本中又針對性的加入了「快速重傳(Fast retransmit)」、「快速恢復(Fast Recovery)」演算法，再後來在TCP NewReno中又對「快速恢復」演算法進行了改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)演算法，還有其他方面的大大小小的改進，成為網路研究的一個熱點。

⑸ sdn默認路由演算法與擁塞相關問題

了防止網路的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由「慢啟動
(Slow start)」和「擁塞避免(Congestion avoidance)」組成，後來TCP Reno版本中又針對性的加入了「快速重傳
(Fast retransmit)」、「快速恢復(Fast Recovery)」演算法，再後來在TCP NewReno中又對「快速恢復」演算法進行了
改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)演算法，還有其他方面的大大小小的改進，成為網路研究
的一個熱點。

TCP的
擁塞控制主要原理依賴於一個擁塞窗口(cwnd)來控制，在之前我們還討論過TCP還有一個對端通告的接收窗口(rwnd)用於流量控制。窗口值的大小就
代表能夠發送出去的但還沒有收到ACK的最大數據報文段，顯然窗口越大那麼數據發送的速度也就越快，但是也有越可能使得網路出現擁塞，如果窗口值為1，那
么就簡化為一個停等協議，每發送一個數據，都要等到對方的確認才能發送第二個數據包，顯然數據傳輸效率低下。TCP的擁塞控制演算法就是要在這兩者之間權
衡，選取最好的cwnd值，從而使得網路吞吐量最大化且不產生擁塞。

由
於需要考慮擁塞控制和流量控制兩個方面的內容，因此TCP的真正的發送窗口=min(rwnd, cwnd)。但是rwnd是由對端確定的，網路環境對其
沒有影響，所以在考慮擁塞的時候我們一般不考慮rwnd的值，我們暫時只討論如何確定cwnd值的大小。關於cwnd的單位，在TCP中是以位元組來做單位
的，我們假設TCP每次傳輸都是按照MSS大小來發送數據的，因此你可以認為cwnd按照數據包個數來做單位也可以理解，所以有時我們說cwnd增加1也
就是相當於位元組數增加1個MSS大小。

慢
啟動：最初的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提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由「慢啟動(Slow start)」和「擁塞避免(Congestion avoidance)」組成，後來TCP Reno版本中又針對性的加入了「快速重傳(Fast retransmit)」、「快速恢復(Fast Recovery)」演算法，再後來在TCP NewReno中又對「快速恢復」演算法進行了改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)演算法，還有其他方面的大大小小的改進，成為網路研究的一個熱點。

TCP的擁塞控制主要原理依賴於一個擁塞窗口(cwnd)來控制，在之前我們還討論過TCP還有一個對端通告的接收窗口(rwnd)用於流量控制。窗口值的大小就代表能夠發送出去的但還沒有收到ACK的最大數據報文段，顯然窗口越大那麼數據發送的速度也就越快，但是也有越可能使得網路出現擁塞，如果窗口值為1，那麼就簡化為一個停等協議，每發送一個數據，都要等到對方的確認才能發送第二個數據包，顯然數據傳輸效率低下。TCP的擁塞控制演算法就是要在這兩者之間權衡，選取最好的cwnd值，從而使得網路吞吐量最大化且不產生擁塞。

由於需要考慮擁塞控制和流量控制兩個方面的內容，因此TCP的真正的發送窗口=min(rwnd, cwnd)。但是rwnd是由對端確定的，網路環境對其沒有影響，所以在考慮擁塞的時候我們一般不考慮rwnd的值，我們暫時只討論如何確定cwnd值的大小。關於cwnd的單位，在TCP中是以位元組來做單位的，我們假設TCP每次傳輸都是按照MSS大小來發送數據的，因此你可以認為cwnd按照數據包個數來做單位也可以理解，所以有時我們說cwnd增加1也就是相當於位元組數增加1個MSS大小。

慢啟動：最初的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擁塞控制有哪幾種演算法

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

⑼ tcp/ip採用什麼方法進行擁塞控制

TCP window機制

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

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

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

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

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

防止擁塞的方法

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

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

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