總結回顧
這篇文章你會了解到什麼
- OSI七層協議和TCP/IP四層協議模型
- 什麼是UDP協議
- 什麼是TCP協議
- TCP連線過程
- TCP兩次握手就可以完成，為撒需要三次了?
- TCP斷開連線過程
- 為什麼 A 要進入 TIME-WAIT 狀態，等待 2MSL 時間後才進入 CLOSED 狀態？
- ARQ協議（超時重傳機制）：停止等待ARQ協議、連續ARQ協議
- 滑動視窗協議
- 擁塞處理過程
- 擁塞演算法
一、七層協議（OSI）
1、應用層
作用：它是與其他計算機進行通訊的應用，它是對應應用程式的通訊服務的。各種應用軟體，包括web應用。
協議：DNS、FTP、HTTP、SMTP、TELNET、IRC、WHOIS
2、表示層
作用：這一層的主要作用是定義資料格式和加密。
3、會話層
作用：控制應用程式的會話能力，它定義了一段會話的開始、控制和結束，包括對多個雙向訊息的控制和管理，以便在只完成一部分訊息時可以通知應用。
PS：其實在應用層、表示層、會話層這三層中，協議是可以共用的
4、傳輸層
作用：對差錯恢復協議和無差錯恢復協議的選擇，對同一主機上不同資料流的輸入進行復用，對資料包進行重新排序。是最關鍵的一層，是唯一負責整體的資料傳輸和資料控制的。對上三層提供可靠的傳輸服務，對網路層提供可靠的目的地資訊。在這一層資料的單位被稱為資料段。
協議：TCP、UDP等
5、網路層
作用：主要負責尋找地址和路由選擇，網路層還可以實現阻塞控制、網際互聯等。
協議：IP、IPX、RIP、OSPF等
6、資料鏈路層
作用：負責物理層面上的互聯的、節點間的通訊傳輸；該層的作用包括：實體地址定址、資料的成幀、流量控制、資料的檢錯、重發等。在這一層，資料的單位稱為幀（frame）
協議：ARP、RARP、SDLC、HDLC、PPP、STP、幀中繼等
7、物理層
作用：負責0、1 位元流（0/1序列）與電壓的高低、逛的閃滅之間的轉換 規定了啟用、維持、關閉通訊端點之間的機械特性、電氣特性、功能特性以及過程特性；該層為上層協議提供了一個傳輸資料的物理媒體。在這一層，資料的單位稱為位元（bit）。
典型規範：EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45、fddi令牌環網等
二、四層協議（TCP/IP網路模型）
OSI:
- 物理層：EIA/TIA-232, EIA/TIA-499, V.35, V.24, RJ45, Ethernet, 802.3, 802.5, FDDI, NRZI, NRZ, B8ZS
- 資料鏈路層：Frame Relay, HDLC, PPP, IEEE 802.3/802.2, FDDI, ATM, IEEE 802.5/802.2
- 網路層：IP，IPX，AppleTalk DDP
- 傳輸層：TCP，UDP，SPX
- 會話層：RPC,SQL,NFS,NetBIOS,names,AppleTalk,ASP,DECnet,SCP
- 表示層:TIFF,GIF,JPEG,PICT,ASCII,EBCDIC,encryption,MPEG,MIDI,HTML
- 應用層：FTP,WWW,Telnet,NFS,SMTP,Gateway,SNMP
TCP/IP:
- 資料鏈路層：ARP,RARP
- 網路層： IP,ICMP,IGMP
- 傳輸層：TCP ,UDP,UGP
- 應用層：Telnet,FTP,SMTP,SNMP.
計算機與網路裝置要互相通訊，雙方需要基於相同的方法。比如如何建立通訊目標，如何建立通訊連線，由那一邊先發起通訊，使用何種語言進行通訊，何時斷開，這些都需要事先確認好。不同裝置、不同作業系統之間也需要確認規則，我們稱這些規則為協議。
TCP/IP是網際網路相關協議的統稱，包含：TCP，DUP，IP，FTP，HTTP，SMTP等等協議。
TCP/IP 模型是網際網路的基礎，它是一系列網路協議的總稱。這些協議可以劃分為四層，分別為鏈路層、網路層、傳輸層和應用層。
- 鏈路層：負責封裝和解封裝 IP 報文，傳送和接受 ARP/RARP 報文等。
- 網路層：負責路由以及把分組報文傳送給目標網路或主機。
- 傳輸層：負責對報文進行分組和重組，並以 TCP 或 UDP 協議格式封裝報文。
- 應用層：負責向使用者提供應用程式，比如 HTTP、FTP、Telnet、DNS、SMTP 等。
在網路體系結構中網路通訊的建立必須是在通訊雙方的對等層進行，不能交錯。 在整個資料傳輸過程中，資料在傳送端時經過各層時都要附加上相應層的協議頭和協議尾（僅資料鏈路層需要封裝協議尾）部分，也就是要對資料進行協議封裝，以標識對應層所用的通訊協議。接下去介紹 TCP/IP 中有兩個具有代表性的傳輸層協議----TCP 和 UDP。
三、UDP
UDP全稱是使用者資料協議，UDP是處於傳輸層的協議。和TCP一樣是處理資料包的。UDP是面向無連線的。UDP不提供資料分組和組裝，也不對資料進行重排，不保證資料是否安全到達。
1、面向無連線
UDP是一種面向無連線的協議，在傳送資料之前，它不需要想TCP一樣需要三次握手建立連線，想傳送資料就可以傳送，它只是資料的搬用工，不會對資料進行任何的拆分和組裝。
- 在傳送資料時，應用層把資料傳到傳輸層的UDP協議，UDP只是給資料增加一個UDP的標識。
- 在接收資料時，網路成把資料傳到傳輸層，UDP只是去除IP報文頭，就傳送給應用層了。
2、不可靠性
基於UDP是面試無連線的，不需要建立連線，想什麼時候傳送資料都可以發，所以，UDP是不可靠的。並且接受到什麼資料就傳遞什麼資料，並不會進行資料的備份。傳送資料方並不關心資料是夠丟失，也不關心接收方是夠正確接收資料。 然後網路時好時壞，但是UDP協議沒有網路阻塞的功能，如果資料開始傳送，就會以一種恆定的速度開始傳送資料。即使在網路不好的情況下，也不會進行速度的調整，這樣會導致，在網路情況一般時，發生資料丟包。
3、高效性
UDP以恆定的速度傳送資料，在網路情況不佳的情況下，是不可靠的，但是正是由於這樣的不可靠性，導致UDP沒有TCP那麼複雜，不需要去保證資料的準確到達，也不需要重發，更不行考慮資料丟包的情況。
UDP頭部包含：
- 兩個十六位的埠號，分別是源埠和目標埠
- 整個資料包文的長度
- 資料包文驗證和IPV4，該欄位用於發現頭部資訊和資料的錯誤。
所以，DUP的頭部開銷小，只有八個位元組，相比TCP的二十幾個位元組在資料傳輸時，是非常高效的。
4、多種傳輸方式
UDP不只支援一對一的傳輸方式，還支援一對多、多對多、多對一的傳輸方式。換句話說，UDP提供了單播、多播、廣播的傳輸方式。
5、面向報文
在資料傳送時，UDP只是對應用層資料進行UDP頭部表示就傳遞給IP網路層，並且不會對資料進行分組、拆分和封裝，保留報文的邊界，那麼需要應用程式選擇合適的報文大小。
使用場景：直播，遊戲，等大概率會使用UDP，如果使用TCP，可能會出現極差的使用者體驗。TCP保證資料的準確和正確，如果網路出現波動，資料傳輸慢，等到資料傳到過來時，可能已經發生了很多事情，使用者的畫面不是最新，已然是不能滿足使用者訴求。
四、TCP
當計算機進行通訊時，兩臺計算機很多時候需要保證資料的可靠安全正確。例如，當你檢視郵寄或者訪問一個網頁時，如果你不希望你看見的網頁或者郵寄是完整的，沒有丟失內容，那麼這裡需要使用到TCP。
TCP全稱是傳輸控制協議，是一種面向有連線、安全可靠的、基礎位元組流的傳輸控制協議。
1、面向連線
在傳送資料之前，雙方需要建立連線，才能進行資料的正常傳送。
2、僅支援單播傳輸
每條TCP傳輸只能在兩個端點，只能進行點對點的傳輸，不支援多播和廣播。
3、面向位元組流
TCP不像UDP那樣一個報文一個報文獨立傳輸，而是在不儲存報文邊界的情況下以位元組流的形式傳輸。
4、可靠性
TCP為了保證傳輸的可靠性給每一個包一個序號，同時也保證了傳輸到接收方的包是按序排列。接收方對於已經接受的包會回傳一個相應的確認（ACK），如果傳送方在確認的往返時延（RTT）沒有收到確認，就會重新傳送。
5、提供阻塞控制
當網路出現阻塞的時候，TCP會減少傳送數量和傳送速率。
6、全雙工通訊
TCP允許通訊的雙方應用程式在任何時候傳送資料，因為TCP在兩端都設有快取，來存放臨時通訊資料。TCP可以馬上傳送資料段，也可以快取等待一段時候在發資料段，以便一次傳送更多的資料（最大的資料段取決於MSS）。
五、TCP的連線（三次握手）
起初客戶端和服務端是都出關閉的狀態，在通訊開始前，雙方會建立TCB，客戶端在建立之後進行準備傳送階段，服務端處於LISTEN狀態。
1、第一次握手
客服端傳送請求連線報文段，其中包括自身的資料通訊初始碼。在請求傳送之後，客戶端進去了SYN-SENT狀態。
2、第二次握手
服務端接受到請求連線報文，如果同意連線，這服務端回覆一個報文段，其中也會包含一個自身的資料通訊資料碼。在傳送後，便進入了SYN-RECEIVED狀態。
3、第三次握手
客戶端接受到服務端的報文段。還要向服務端傳送一個確認報文。客戶端在傳送完成之後就進行了ESTABLISHED狀態，服務端在接受到這個請求後也進行ESTABLISHED狀態。此時客戶端服務端建立連線完成。
PS:兩次握手就可以完成，為撒需要三次了? 因為這是為了防止出現失效的連線請求報文段被服務端接收的情況，從而產生錯誤。 可以想象如下場景。客戶端傳送了一個連線請求 A，但是因為網路原因造成了超時，這時 TCP 會啟動超時重傳的機制再次傳送一個連線請求 B。此時請求順利到達服務端，服務端應答完就建立了請求，然後接收資料後釋放了連線。 假設這時候連線請求 A 在兩端關閉後終於抵達了服務端，那麼此時服務端會認為客戶端又需要建立 TCP 連線，從而應答了該請求並進入 ESTABLISHED 狀態。但是客戶端其實是 CLOSED 的狀態，那麼就會導致服務端一直等待，造成資源的浪費。
PS：在建立連線中，任意一端掉線，TCP 都會重發 SYN 包，一般會重試五次，在建立連線中可能會遇到 SYN Flood 攻擊。遇到這種情況你可以選擇調低重試次數或者乾脆在不能處理的情況下拒絕請求。
PS：ISN是什麼？存在的意義？ISN是傳送方的位元組資料編號的原點，讓對方生成一個合法的接收視窗。它是動態隨機的。動態隨機的目的是了增加安全性，為了避免被第三方猜測到，從而被第三方偽造RST報文reset。RST如果是想要得逞，必須seq-number位於對方的合法視窗內，而由於ISN是動態隨機的，所以這個概率是非常小的，但是如果ISN = 0，那麼被猜測出的概率就會變大。ISN動態隨機使得每個TCP session的位元組序列號都沒有重複，如果出現TCP五元組衝突這種極小的概率情況發生，一個session的資料也不會被誤認為成另一個session。
PS：三次握手第一次可以攜帶資料嗎？為什麼？三次握手的第一次是不能攜帶資料的，因為握手還沒有完成，如果對方服務端講資料快取下來，等握手成功在進行傳送，這樣會增大被SYN_FLOOD攻擊機率，如果攻擊者偽造了成千上萬的握手報文，攜帶1K的位元組資料，而接收方需要開闢大量的快取來儲存這些資料，導致記憶體被消耗。
PS：第三次握手可以攜帶資料嗎？第三次握手中可以包含資料， 能夠 通過快速開啟（TFO）技術就可以實現這一功能。其實只要涉及到握手的協議，都可以使用類似 TFO 的方式，客戶端和服務端儲存相同的 cookie，下次握手時發出 cookie 達到減少 RTT 的目的。
六、TCP斷開連線（四次握手）
1、第一次握手
如客戶端認為資料傳送完成，需要向服務端傳送釋放連線的請求。客戶端進入FIN_WAIT_1狀態。
2、第二次握手
服務端接收到客戶端的連線釋放請求，會告訴應用層要釋放TCP連線。然後傳送ACK到客戶端，然後進入CLOSE_WAIT狀態。此時表明客戶端到服務端的連線已經釋放，不會接受來自客戶端的資料了，但是由於TCP是全雙工。所以此時服務端還可以向客戶端傳送資料。
3、第三次握手
服務端如果在此時資料還沒有傳送完成，會繼續傳送，在資料傳送完畢之後。服務端會向客戶端傳送連線釋放的請求。然後服務端進入LAST_ACK狀態。
4、第四次握手
客戶端在接受到服務端的釋放請求。會向服務端在傳送一個確認請求。此時客戶端進入TIME_WAIT狀態 該狀態會持續 2MSL（最大段生存期，指報文段在網路中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 服務端的重發請求的話，就進入 CLOSED 狀態。當 客戶端收到確認應答後，也便進入 CLOSED 狀態。
PS:為什麼 A 要進入 TIME-WAIT 狀態，等待 2MSL 時間後才進入 CLOSED 狀態？ 為了保證 B 能收到 A 的確認應答。若 A 發完確認應答後直接進入 CLOSED 狀態，如果確認應答因為網路問題一直沒有到達，那麼會造成 B 不能正常關閉。按照道理，在四個報文都傳送完成之後，應該可以直接進入關閉狀態，但是必須以防萬一，網路是不可靠的，有可能最後一個ACK丟失。所以TIME_WAIT是為了防止最後一個報文丟失來進行ACK報文的重發的。具體的過程就是客服端在傳送最後的ACK後，可能出現ACK的丟失，服務端如果沒有收到ACK，就會不斷的傳送FIN，如果在2MSL時間內沒有收到服務端的FIN，客戶端就進入關閉狀態。這裡客戶端有一個活性計時器，當傳送完ACK進入到TIME_WAIT的時候就開始計時，如果在2MSL範圍內收到FIN就重新開始計時，MSL指一個片段在網路中的最大存活時間。
PS:為什麼連線的時候需要三次握手，關閉的時候卻是四次握手？ 因為當服務端接收到客戶端的SYN連線請求時，可以直接傳送SYN+ACK報文，其中ACK是用來應答的，SYN報文是用來同步的。但是 當關閉連線的時候，當服務端接收到服務端的FIN報文時，很可能並不會立即關閉連線，所以只能先回復一個ACK報文，告訴客戶端 ，傳送的FIN已經被服務端收到。只有等到服務端所有的報文都傳送完成了，才傳送FIN報文，因此FIN和ACK不能一起傳送，所以需要四步握手。
PS:如果已經建立了連結，但是客服端突然出現故障了怎麼辦？ TCP有一個保活器，顯然如果當客服端出現問題，服務端不能一直等待下來，一直等待會浪費資源，伺服器每次在接受到一個客戶端請求後都會去重置這個保活器，通常的設定時間是2小時，如兩個小時不能收到客服端的任何資料，服務端就會傳送一個探索的報文，這個報文不會連續傳送10次，如果這10次都沒有接到到客戶端的應答，伺服器就認為客戶端出現問題，服務端就自動進入管理狀態。
七、ARQ協議（超時重傳機制）
ARQ協議就是超時重傳機制。通過確認和超時機制保證資料的正確到達，是OSI模型中傳輸層和資料鏈路層的錯誤糾正協議之一，在不可靠的服務基礎上實現可靠的資訊傳輸。ARQ協議包含停止等待ARQ協議和連續ARQ協議，擁有錯誤檢測，正面確認，超時重傳和負面確認及重傳等機制。
1、停止等待ARQ協議
TCP是全雙工協議，就是在建立連線之後，雙方就是傳送方也是接收方。在只考慮只是一方傳送一方接收的情況下。我們假設傳送方為A，接收方為B。
1.1 無差錯的情況
A傳送報文分組M1，傳送完畢就暫停傳送，等待B的確認。B收到M1，就向A傳送確認。A收到確認之後就在傳送下一個分組M2。
1.2出現差錯的情況
如果A傳送過程中出現差錯或者B在接收M1是檢查到出了差錯（這裡A在傳送之前會儲存分組的副本，再只有在收到確認之後才會清除副本），B在接收M1時檢測到差錯就丟棄M1，其他什麼都不做。出現差錯的情況，A只要超過一段時間沒有收到確認，就任務出現差錯，就會重新傳送剛剛的分組，也就是超時重傳。
超時重傳就是在A傳送完一個分組之後，就會設定一個超時計時器，如果在超時時間大於這個時間，就會重新傳送分組。當然如果在時間內收到確認資訊就不會重新傳送。一般超時計時器的時間應該是大於一個RTT時間。
1.3 ACK延遲和丟失
如果A向B傳送了分組M1，B接收到M1之後，傳送確認應答資訊，但是由於網路問題，確認資訊丟失，那麼這個時間，A在超時重傳的時間段內，沒有收到B 的確認資訊。A會重傳M1分組。那麼B會做兩個動作，①B會丟棄到M1分組，不向上層交付 ，因為之前已經收到過M1分組。②向A傳送確認資訊。
停止等待ARQ協議的優點是簡答，但也有很嚴重的確定，就是通道利用率太低。 通道利用率U = TD / (TD + RTT + TA)。 其中Td傳送時延，RTT是一個往返時間，Ta是接收時延
2、連續傳送ARQ協議
由於停止等待ARQ協議通道利用率太低，所有需要使用連續ARQ協議來進行改善。這個協議會連續傳送一組資料包。然後等待這些資料包的ACK。
連續ARQ協議規定，傳送方每收到一個確認，就把傳送視窗向前滑動一個分組的位置。當傳送方收到第一個分組的確認，就把傳送視窗向前移動一個分組的位置。如果原來已經傳送了前5個分組，則現在可以傳送視窗內的第6個分組。
2.1累積確認
接收方一般都是採用累積確認的方式。也就是說接收方不必對收到的分組逐個傳送確認。而是在收到幾個分組後，對按序到達的最後一個分組傳送確認。如果收到了這個分組確認資訊，則表示到這個分組為止的所有分組都已經正確接收到了。
累積確認的優點是容易實現，即使確認丟失也不必重傳。但缺點是，不能正確的向傳送方反映出接收方已經正確收到的所有分組的資訊。比如傳送方傳送了前5個分組，而中間的第3個分組丟失了，這時候接收方只能對前2個發出確認。而不知道後面3個分組的下落，因此只能把後面的3個分組都重傳一次，這種機制叫Go-back-N（回退N），表示需要再退回來重傳已傳送過的N個分組。
八、滑動視窗協議
滑動視窗協議在在傳送方和接收方之間各自維持一個滑動視窗，傳送發是傳送視窗，接收方是接收視窗，而且這個視窗是隨著時間變化可以向前滑動的。它允許傳送方傳送多個分組而不需等待確認。TCP的滑動視窗是以位元組為單位的。
傳送視窗中有四個概念：
- 已傳送並收到確認的資料（不在傳送視窗和傳送緩衝區之內）
- 已傳送但未收到確認的資料（位於傳送視窗之內）
- 允許傳送但尚未傳送的資料（位於傳送視窗之內）
- 傳送視窗之外的緩衝區內暫時不允許傳送的資料 接收視窗中也有四個概念：
- 已傳送確認並交付主機的資料（不在接收視窗和接收緩衝區之內）
- 未按序收到的資料（位於接收視窗之內）
- 允許接收的資料（位於接收視窗之內）
- 不允許接收的資料（位於傳送視窗之內）
滑動視窗是一個很重要的概念，它幫助 TCP 實現了流量控制的功能。接收方通過報文告知傳送方還可以傳送多少資料，從而保證接收方能夠來得及接收資料，防止出現接收方頻寬已滿，但是傳送方還一直髮送資料的情況。
九、擁塞控制
網路擁塞現象是指到達通訊網路中某一部分的分組數量過多，使得該部分網路來不及處理，以致引起這部分乃至整個網路效能下降的現象，嚴重時甚至會導致網路通訊業務陷入停頓，即出現死鎖現象。擁塞控制是處理網路擁塞現象的一種機制。
擁塞控制是一種用來調整傳輸控制協議（TCP）連線上單次傳送的分組數量的演算法，通過增減單次傳送量逐步調整，使之逼近當前網路的承載量。如果單次傳送量為1，此協議就退化為停等協議。單次傳送量是以位元組來做單位的；但是如果假設TCP每次傳輸都是按照最大報文段（MSS）來傳送資料的，那麼也可以把資料包個數當作單次傳送量的單位，所以有時我們說單次傳送量增加1也就是增加相當於1個最大報文段的位元組數。
1、擁塞控制的演算法
擁塞控制假設分組的丟失都是由網路繁忙造成的。擁塞控制有三種動作，分別對應到源主機感受到的情況：
-
收到一條新確認。表明當前的單次傳送量小於網路的承載量。此時可以增加單次傳送量。若當前單次傳送量小於慢啟動閾值（ssthreash），則單次傳送量加倍（乘以2），即指數增長；否則單次傳送量加1，即線性增長。
-
收到三條對同一分組的確認，即三條重複的確認。說明網路有一點兒繁忙。此時單次傳送量減半，慢啟動閾值（ssthreash）約等於單次傳送量，進入線性增長階段。
-
對某一個分組的確認遲遲未到，即超時。說明網路比上一情況中的更加繁忙。此時慢啟動閾值=單次傳送量÷2，單次傳送量=1，進入慢啟動階段（指數增長階段）。
2、擁塞控制的四個階段
2.1慢啟動
慢啟動，是傳輸控制協議（TCP）使用的一種阻塞控制機制。慢啟動也叫做指數增長期。 慢啟動演算法通過觀察到新分組進入網路的速率應該與另一端返回確認的速率相同而進行工作。
慢啟動為傳送方的TCP增加了另一個視窗：擁塞視窗(congestion window)，記為cwnd。擁塞視窗是傳送方使用的流量控制，而通告視窗則是接收方使用的流量控制。演算法描述如下：
-
當與另一個網路的主機建立TCP連線時，擁塞視窗被初始化為1個報文段（即另一端通告的報文段大小）。
-
每收到一個ACK，擁塞視窗就翻倍（cwnd以位元組為單位，但是慢啟動以報文段大小為單位進行增加）。這是一種指數增長的關係。
-
傳送方取擁塞視窗與通告視窗中的最小值作為傳送上限。
2.2 擁塞避免
慢啟動演算法是在一個連線上發起資料流的方法，其指數級增長很快就會使網路出現擁塞現象，因為某些點上可能達到了網際網路的容量，於是中間路由器開始丟棄分組。擁塞避免演算法是一種處理丟失分組的方法。有兩種分組丟失的指示：發生超時和接收到重複的確認。發生超時，指源主機在超時定時器溢位時沒有收到目的主機對某一分組的ACK；接收到重複確認，指在源主機的超時定時器溢位前，連續收到3個或3個以上收對某一分組的ACK。
當發現超時或接收到3次重複確認時，則表示有丟包事件，此時網路已發生擁塞現象，要進行相應的擁塞控制。演算法描述如下：
-
將慢啟動閾值（ssthreash）設定為當前視窗的一半（cwnd 和通告視窗大小的最小值，但最小為2個報文）。
-
如果是超時引起的擁塞，則擁塞視窗（cwmd）被置為1，進入慢啟動過程。如果是重複確認引起的擁塞，則進入快速重傳和快速恢復過程。
-
進入慢啟動階段後，擁塞視窗會指數級增長，如果擁塞視窗大於慢啟動閾值（ssthreash），執行擁塞避免演算法。執行擁塞避免演算法時，由於慢啟動閾值（ssthreash）已經存在，擁塞視窗大小不再翻倍增長，而是線性增加。
擁塞避免演算法和慢啟動演算法是兩個目的不同、獨立的演算法。但是當擁塞發生時，我們希望降低分組進入網路的傳輸速率，於是可以呼叫慢啟動來作到這一點。在實際中這兩個演算法通常在一起實現。1990年出現的TCPReno版本增加了 “快速重傳”演算法、”快速恢復”演算法，避免了當網路擁塞不夠嚴重時採用”慢啟動”演算法而造成過大地減小傳送視窗尺寸的現象。
2.3快速重傳
目的主機在收到一個失序的報文段時，會立即產生一個ACK（重複的ACK），這個重複的ACK不應該被延遲，目的在於讓源主機知道目的主機收到了一個失序的報文段，並告訴源主機自己希望收到的序號。
由於我們不知道一個重複的ACK是由一個丟失的報文段引起的，還是由於僅僅出現了幾個報文段的重新排序，因此我們等待少量重複的ACK到來。假如這只是一些報文段的重新排序，則在重新排序的報文段被處理併產生一個新的ACK之前，只可能產生1到2個重複的ACK。如果一連串收到3個或3個以上的重複ACK，就非常可能是一個報文段丟失了，進入快速重傳過程，描述如下：
1.將慢啟動閾值（ssthreash）設定為當前擁塞視窗（cwnd）的一半，設定擁塞視窗（cwnd）為慢啟動閾值（ssthreash）加上3倍的報文段大小。重傳丟失的資料包文段，而無需等待超時定時器溢位。
2.每次收到另一個重複的ACK時，cwnd增加一個報文段大小併傳送1個分組（如果新的cwnd允許傳送）。收到另一個重複的ACK，說明網路中傳輸的一個分組到達了目的主機，網路中可再容納一個分組，故cwnd增加一個報文段大小併傳送一個分組。
2.4 快速恢復
丟失的分組通過快速重傳過程傳送完，並被目的主機接受後，目的主機就不再傳送重複的ACK通知源主機傳送丟失的分組了，而是傳送確認新資料的ACK通知源主機傳送新的分組。這個ACK應該是在進行重傳後的一個往返時間內對重傳分組的確認，也應該是對丟失的分組和收到的第1個重複的ACK之間的所有中間報文段的確認。此時為了快速的恢復到較高的傳輸速度，就會進入快速恢復階段，演算法描述如下：
- 當確認新資料的ACK到達時，設定擁塞視窗（cwnd）為慢啟動閾值（ssthreash）（快速重傳時步驟1中設定的值），進入擁塞避免過程。
參考