瞎扯
大家好，我是老田，今天我們繼續分享連環炮。
TCP 作為傳輸層的協議，是一個軟體工程師素養的體現，也是面試中經常被問到的知識點。在此，我將 TCP 核心的一些問題梳理了一下，希望能幫到各位。
核心知識思維導圖
我給大家搞了一張TCP/IP的核心知識總結思維導圖：
（需要此圖，
私聊，免費贈送
）
TCPD的12連環炮如下
1、能不能說一說 TCP 和 UDP 的區別？
2、說說 TCP 三次握手的過程？為什麼是三次而不是兩次、四次？
3、說說 TCP 四次揮手的過程
4、說說半連線佇列和 SYN Flood 攻擊的關係
5、介紹一下 TCP 報文頭部的欄位
6、說說 TCP 快速開啟的原理（TFO）
7、能不能說說TCP報文中時間戳的作用？
8、TCP 的超時重傳時間是如何計算的？
9、 能不能說一說 TCP 的流量控制？
10、能不能說說 TCP 的擁塞控制？
11、能不能說說 Nagle 演算法和延遲確認？
12、如何理解 TCP 的 keep-alive？
一共就整理12個連環炮，下面開始發炮。
1、能不能說一說 TCP 和 UDP 的區別？
首先概括一下基本的區別：
TCP是一個面向連線的、可靠的、基於位元組流的傳輸層協議。而UDP是一個面向無連線的傳輸層協議。（就這麼簡單，其它TCP的特性也就沒有了）。
具體來分析，和 UDP 相比，TCP 有三大核心特性：
1、
面向連線
。所謂的連線，指的是客戶端和伺服器的連線，在雙方互相通訊之前，TCP 需要三次握手建立連線，而 UDP 沒有相應建立連線的過程。
2、
可靠性
。TCP 花了非常多的功夫保證連線的可靠，這個可靠性體現在哪些方面呢？一個是有狀態，另一個是可控制。
TCP 會精準記錄哪些資料傳送了，哪些資料被對方接收了，哪些沒有被接收到，而且保證資料包按序到達，不允許半點差錯。這是有
狀態
。
當意識到丟包了或者網路環境不佳，TCP 會根據具體情況調整自己的行為，控制自己的傳送速度或者重發。這是可控制。
相應的，UDP 就是無狀態， 不可控的。
3、
面向位元組流
。UDP 的資料傳輸是基於資料報的，這是因為僅僅只是繼承了 IP 層的特性，而 TCP 為了維護狀態，將一個個 IP 包變成了位元組流。
2、說說 TCP 三次握手的過程？怎麼不是兩次、四次
戀愛模擬
以談戀愛為例，兩個人能夠在一起最重要的事情是首先確認各自愛和被愛的能力。接下來我們以此來模擬三次握手的過程。
第一次：
男：
我愛你
。
女方收到。
由此證明男方擁有
愛
的能力。
第二次：
女：
我收到了你的愛，我也愛你
。
男方收到。
OK，現在的情況說明，女方擁有
愛
和
被愛
的能力。
第三次：
男：
我收到了你的愛
。
女方收到。
現在能夠保證男方具備被愛的能力。
由此完整地確認了雙方
愛
和
被愛
的能力，兩人開始一段甜蜜的愛情。
真實握手
當然剛剛那段屬於扯淡，不代表本人價值觀，目的是讓大家理解整個握手過程的意義，因為兩個過程非常相似。對應到 TCP 的三次握手，也是需要確認雙方的兩樣能力： 傳送的能力和接收的能力。於是便會有下面的三次握手的過程：
從最開始雙方都處於CLOSED狀態。然後服務端開始監聽某個埠，進入了LISTEN狀態。
然後客戶端主動發起連線，傳送 SYN ， 自己變成了SYN-SENT狀態。
服務端接收到，返回SYN和ACK（對應客戶端發來的SYN），自己變成了SYN-REVD。
之後客戶端再發送ACK給服務端，自己變成了ESTABLISHED狀態；服務端收到ACK之後，也變成了ESTABLISHED狀態。
另外需要提醒你注意的是，從圖中可以看出，SYN 是需要消耗一個序列號的，下次傳送對應的 ACK 序列號要加1，為什麼呢？只需要記住一個規則：
凡是需要對端確認的，一定消耗TCP報文的序列號。
SYN 需要對端的確認， 而 ACK 並不需要，因此 SYN 消耗一個序列號而 ACK 不需要。
為什麼不是兩次？
根本原因： 無法確認客戶端的接收能力。
分析如下： 如果是兩次，你現在發了 SYN 報文想握手，但是這個包滯留在了當前的網路中遲遲沒有到達，TCP 以為這是丟了包，於是重傳，兩次握手建立好了連線。
看似沒有問題，但是連線關閉後，如果這個滯留在網路中的包到達了服務端呢？這時候由於是兩次握手，服務端只要接收到然後傳送相應的資料包，就預設建立連線，但是現在客戶端已經斷開了。
看到問題的吧，這就帶來了連線資源的浪費。
為什麼不是四次？
三次握手的目的是確認雙方
傳送
和
接收
的能力，那四次握手可以嘛？
當然可以，100 次都可以。但為了解決問題，三次就足夠了，再多用處就不大了。
三次握手過程中可以攜帶資料麼？
第三次握手的時候，可以攜帶。前兩次握手不能攜帶資料。
如果前兩次握手能夠攜帶資料，那麼一旦有人想攻擊伺服器，那麼他只需要在第一次握手中的 SYN 報文中放大量資料，那麼伺服器勢必會消耗更多的時間和記憶體空間去處理這些資料，增大了伺服器被攻擊的風險。
第三次握手的時候，客戶端已經處於ESTABLISHED狀態，並且已經能夠確認伺服器的接收、傳送能力正常，這個時候相對安全了，可以攜帶資料。
同時開啟會怎樣？
如果雙方同時發 SYN報文，狀態變化會是怎樣的呢？
這是一個可能會發生的情況。
狀態變遷如下：
在傳送方給接收方發
SYN
報文的同時，接收方也給傳送方發
SYN
報文，兩個人剛上了！
發完
SYN
，兩者的狀態都變為
SYN-SENT
。
在各自收到對方的
SYN
後，兩者狀態都變為
SYN-REVD
。
接著會回覆對應的
ACK + SYN
，這個報文在對方接收之後，兩者狀態一起變為
ESTABLISHED
。
這就是同時開啟情況下的狀態變遷。
3、說說 TCP 四次揮手的過程
過程拆解
剛開始雙方處於
ESTABLISHED
狀態。
客戶端要斷開了，向伺服器傳送
FIN
報文，在
TCP
報文中的位置如下圖：
傳送後客戶端變成了
FIN-WAIT-1
狀態。注意， 這時候客戶端同時也變成了
half-close（半關閉）
狀態，即無法向服務端傳送報文，只能接收。
服務端接收後向客戶端確認，變成了
CLOSED-WAIT
狀態。
客戶端接收到了服務端的確認，變成了
FIN-WAIT2
狀態。
隨後，服務端向客戶端傳送
FIN
，自己進入
LAST-ACK
狀態，
客戶端收到服務端發來的
FIN
後，自己變成了
TIME-WAIT
狀態，然後傳送
ACK
給服務端。
注意了，這個時候，客戶端需要等待足夠長的時間，具體來說，是 2 個
MSL（Maximum Segment Lifetime
，報文最大生存時間）， 在這段時間內如果客戶端沒有收到服務端的重發請求，那麼表示 ACK 成功到達，揮手結束，否則客戶端重發 ACK。
等待2MSL的意義
如果不等待會怎樣？
如果不等待，客戶端直接跑路，當服務端還有很多資料包要給客戶端發，且還在路上的時候，若客戶端的埠此時剛好被新的應用佔用，那麼就接收到了無用資料包，造成資料包混亂。所以，最保險的做法是等伺服器發來的資料包都死翹翹再啟動新的應用。
那，照這樣說一個
MSL
不就不夠了嗎，為什麼要等待
2 MSL
？
1 個 MSL 確保四次揮手中主動關閉方最後的 ACK 報文最終能達到對端
1 個 MSL 確保對端沒有收到 ACK 重傳的 FIN 報文可以到達
這就是等待 2MSL 的意義。
為什麼是四次揮手而不是三次？
因為服務端在接收到
FIN
， 往往不會立即返回
FIN
， 必須等到服務端所有的報文都發送完畢了，才能發
FIN
。因此先發一個ACK表示已經收到客戶端的
FIN
，延遲一段時間才發
FIN
。這就造成了
四次揮手
。
如果是三次揮手會有什麼問題？
等於說服務端將
ACK
和
FIN
的傳送合併為一次揮手，這個時候長時間的延遲可能會導致客戶端誤以為
FIN
沒有到達客戶端，從而讓客戶端不斷的重發
FIN
。
同時關閉會怎樣？
如果客戶端和服務端同時傳送 FIN ，狀態會如何變化？如圖所示：
4、說說半連線佇列和 SYN Flood 攻擊的關係
三次握手前，服務端的狀態從
CLOSED
變為
LISTEN
， 同時在內部建立了兩個佇列：
半連線佇列
和
全連線佇列
，即
SYN佇列
和
ACCEPT佇列
。
連線佇列
當客戶端傳送
SYN
到服務端，服務端收到以後回覆
ACK
和
SYN
，狀態由
LISTEN
變為
SYN_RCVD
，此時這個連線就被推入了
SYN佇列
，也就是
半連線佇列
。
全連線佇列
當客戶端返回
ACK
， 服務端接收後，三次握手完成。這個時候連線等待被具體的應用取走，在被取走之前，它會被推入另外一個
TCP
維護的佇列，也就是全連線佇列（Accept Queue）。
SYN Flood 攻擊原理
SYN Flood
屬於典型的
DoS/DDoS
攻擊。其攻擊的原理很簡單，就是用客戶端在短時間內偽造大量不存在的 IP 地址，並向服務端瘋狂傳送SYN。對於服務端而言，會產生兩個危險的後果：
處理大量的SYN包並返回對應ACK， 勢必有大量連線處於SYN_RCVD狀態，從而佔滿整個半連線佇列，無法處理正常的請求。
由於是不存在的 IP，服務端長時間收不到客戶端的ACK，會導致服務端不斷重發資料，直到耗盡服務端的資源。
如何應對 SYN Flood 攻擊？
增加 SYN 連線，也就是增加半連線佇列的容量。
減少 SYN + ACK 重試次數，避免大量的超時重發。
利用 SYN Cookie 技術，在服務端接收到SYN後不立即分配連線資源，而是根據這個SYN計算出一個Cookie，連同第二次握手回覆給客戶端，在客戶端回覆ACK的時候帶上這個Cookie值，服務端驗證 Cookie 合法之後才分配連線資源。
5、介紹一下 TCP 報文頭部的欄位
報文頭部結構如下（單位為位元組）：
請大家牢記這張圖！
源埠、目標埠
如何標識唯一標識一個連線？答案是 TCP 連線的
四元組
——源 IP、源埠、目標 IP 和目標埠。
那 TCP 報文怎麼沒有源 IP 和目標 IP 呢？這是因為在 IP 層就已經處理了 IP 。TCP 只需要記錄兩者的埠即可。
序列號
即Sequence number， 指的是本報文段第一個位元組的序列號。
從圖中可以看出，序列號是一個長為 4 個位元組，也就是 32 位的無符號整數，表示範圍為 0 ~ 2^32 - 1。如果到達最大值了後就迴圈到0。
序列號在 TCP 通訊的過程中有兩個作用：
在 SYN 報文中交換彼此的初始序列號。
保證資料包按正確的順序組裝。
ISN
即
Initial Sequence Number
（初始序列號），在三次握手的過程當中，雙方會用過
SYN
報文來交換彼此的
ISN
。
ISN
並不是一個固定的值，而是每 4 ms 加一，溢位則回到 0，這個演算法使得猜測 ISN 變得很困難。那為什麼要這麼做？
如果
ISN
被攻擊者預測到，要知道源
IP
和
源埠
號都是很容易偽造的，當攻擊者猜測
ISN
之後，直接偽造一個
RST
後，就可以強制連線關閉的，這是非常危險的。
而動態增長的 ISN 大大提高了猜測 ISN 的難度。
確認號
即
ACK（Acknowledgment number）
。用來告知對方下一個期望接收的序列號，小於
ACK
的所有位元組已經全部收到。
標記位
常見的標記位有
SYN，ACK，FIN，RST，PSH
。
SYN
和
ACK
已經在上文說過，後三個解釋如下：
FIN：即 Finish，表示傳送方準備斷開連線。
RST：即 Reset，用來強制斷開連線。
PSH：即 Push， 告知對方這些資料包收到後應該馬上交給上層的應用，不能快取。
視窗大小
佔用兩個位元組，也就是 16 位，但實際上是不夠用的。因此 TCP 引入了視窗縮放的選項，作為視窗縮放的比例因子，這個比例因子的範圍在 0 ~ 14，比例因子可以將視窗的值擴大為原來的 2 ^ n 次方。
校驗和
佔用兩個位元組，防止傳輸過程中資料包有損壞，如果遇到校驗和有差錯的報文，TCP 直接丟棄之，等待重傳。
可選項
可選項的格式如下：
常用的可選項有以下幾個：
TimeStamp： TCP 時間戳，後面詳細介紹。
MSS： 指的是 TCP 允許的從對方接收的最大報文段。
SACK： 選擇確認選項。
Window Scale：視窗縮放選項。
6、說說 TCP 快速開啟的原理（TFO）
第一節講了
TCP
三次握手，可能有人會說，每次都三次握手好麻煩呀！能不能最佳化一點？
可以啊。今天來說說這個最佳化後的
TCP
握手流程，也就是
TCP
快速開啟
（TCP Fast Open， 即TFO）
的原理。
最佳化的過程是這樣的，還記得我們說
SYN Flood
攻擊時提到的
SYN Cookie
嗎？這個
Cookie
可不是瀏覽器的
Cookie
， 用它同樣可以實現
TFO
。
TFO 流程
首輪三次握手
首先客戶端傳送SYN給服務端，服務端接收到。
注意哦！現在服務端不是立刻回覆
SYN + ACK
，而是透過計算得到一個
SYN Cookie
， 將這個
Cookie
放到
TCP
報文的
Fast Open
選項中，然後才給客戶端返回。
客戶端拿到這個
Cookie
的值快取下來。後面正常完成三次握手。
首輪三次握手就是這樣的流程。而後面的三次握手就不一樣啦！
後面的三次握手
在後面的三次握手中，客戶端會將之前快取的
Cookie
、
SYN
和
HTTP
請求（是的，你沒看錯）傳送給服務端，服務端驗證了
Cookie
的合法性，如果不合法直接丟棄；如果是合法的，那麼就正常返回
SYN + ACK
。
重點來了，現在服務端能向客戶端發
HTTP
響應了！這是最顯著的改變，三次握手還沒建立，僅僅驗證了
Cookie
的合法性，就可以返回
HTTP
響應了。
當然，客戶端的
ACK
還得正常傳過來，不然怎麼叫三次握手嘛。
流程如下：
注意： 客戶端最後握手的 ACK 不一定要等到服務端的 HTTP 響應到達才傳送，兩個過程沒有任何關係。
7、能不能說說TCP報文中時間戳的作用？
timestamp
是 TCP 報文首部的一個可選項，一共佔 10 個位元組，格式如下：
kind（1 位元組） + length（1 位元組） + info（8 個位元組）
其中 kind = 8， length = 10， info 有兩部分構成：
timestamp
和
timestamp echo
，各佔 4 個位元組。
那麼這些欄位都是幹嘛的呢？它們用來解決哪些問題？
接下來我們就來一一梳理，TCP 的時間戳主要解決兩大問題：
計算往返時延 RTT（Round-Trip Time）
防止序列號的迴繞問題
計算往返時延 RTT
在沒有時間戳的時候，計算 RTT 會遇到的問題如下圖所示：
如果以第一次發包為開始時間的話，就會出現左圖的問題，RTT 明顯偏大，開始時間應該採用第二次的；
如果以第二次發包為開始時間的話，就會導致右圖的問題，RTT 明顯偏小，開始時間應該採用第一次發包的。
實際上無論開始時間以第一次發包還是第二次發包為準，都是不準確的。
那這個時候引入時間戳就很好的解決了這個問題。
比如現在 a 向 b 傳送一個報文 s1，b 向 a 回覆一個含 ACK 的報文 s2 那麼：
step 1： a 向 b 傳送的時候，timestamp 中存放的內容就是 a 主機發送時的核心時刻 ta1。
step 2： b 向 a 回覆 s2 報文的時候，timestamp 中存放的是 b 主機的時刻 tb， timestamp echo欄位為從 s1 報文中解析出來的 ta1。
step 3： a 收到 b 的 s2 報文之後，此時 a 主機的核心時刻是 ta2， 而在 s2 報文中的 timestamp echo 選項中可以得到 ta1， 也就是 s2 對應的報文最初的傳送時刻。然後直接採用 ta2 - ta1 就得到了 RTT 的值。
防止序列號迴繞問題
現在我們來模擬一下這個問題。
序列號的範圍其實是在0 ~ 2 ^ 32 - 1， 為了方便演示，我們縮小一下這個區間，假設範圍是 0 ~ 4，那麼到達 4 的時候會回到 0。
假設在第 6 次的時候，之前還滯留在網路中的包回來了，那麼就有兩個序列號為1 ~ 2的資料包了，怎麼區分誰是誰呢？這個時候就產生了序列號迴繞的問題。
那麼用 timestamp 就能很好地解決這個問題，因為每次發包的時候都是將發包機器當時的核心時間記錄在報文中，那麼兩次發包序列號即使相同，時間戳也不可能相同，這樣就能夠區分開兩個資料包了。
8、TCP 的超時重傳時間是如何計算的？
TCP 具有超時重傳機制，即間隔一段時間沒有等到資料包的回覆時，重傳這個資料包。
那麼這個重傳間隔是如何來計算的呢？
今天我們就來討論一下這個問題。
這個重傳間隔也叫做超時重傳時間（Retransmission TimeOut， 簡稱RTO），它的計算跟上一節提到的 RTT 密切相關。這裡我們將介紹兩種主要的方法，一個是經典方法，一個是標準方法。
經典方法
經典方法引入了一個新的概念——SRTT（Smoothed round trip time，即平滑往返時間），沒產生一次新的 RTT。 就根據一定的演算法對 SRTT 進行更新，具體而言，計算方式如下（SRTT 初始值為0）：
SRTT = （α * SRTT） + （（1 - α） * RTT）
其中，α 是平滑因子，建議值是0。8，範圍是0。8 ~ 0。9。
拿到 SRTT，我們就可以計算 RTO 的值了：
RTO = min（ubound， max（lbound， β * SRTT））
β 是加權因子，一般為1。3 ~ 2。0， lbound 是下界，ubound 是上界。
其實這個演算法過程還是很簡單的，但是也存在一定的侷限，就是在 RTT 穩定的地方表現還可以，而在 RTT 變化較大的地方就不行了，因為平滑因子 α 的範圍是0。8 ~ 0。9， RTT 對於 RTO 的影響太小。
標準方法
為了解決經典方法對於 RTT 變化不敏感的問題，後面又引出了標準方法，也叫
Jacobson / Karels
演算法。
一共有三步。第一步： 計算SRTT，公式如下：
SRTT = （1 - α） * SRTT + α * RTT
注意這個時候的 α跟經典方法中的α取值不一樣了，建議值是1/8，也就是0。125。
第二步： 計算RTTVAR（round-trip time variation）這個中間變數。
RTTVAR = （1 - β） * RTTVAR + β * （|RTT - SRTT|）
β 建議值為 0。25。這個值是這個演算法中出彩的地方，也就是說，它記錄了最新的 RTT 與當前 SRTT 之間的差值，給我們在後續感知到 RTT 的變化提供了抓手。
第三步： 計算最終的RTO：
RTO = µ * SRTT + ∂ * RTTVAR
µ建議值取1， ∂建議值取4。
這個公式在 SRTT 的基礎上加上了最新 RTT 與它的偏移，從而很好的感知了 RTT 的變化，這種演算法下，RTO 與 RTT 變化的差值關係更加密切。
9、 能不能說一說 TCP 的流量控制？
對於傳送端和接收端而言，TCP 需要把傳送的資料放到傳送快取區， 將接收的資料放到接收快取區。
而流量控制索要做的事情，就是在透過接收快取區的大小，控制傳送端的傳送。如果對方的接收快取區滿了，就不能再繼續傳送了。
要具體理解流量控制，首先需要了解滑動視窗的概念。
TCP 滑動視窗
TCP 滑動視窗分為兩種： 傳送視窗和接收視窗。
傳送視窗
傳送端的滑動視窗結構如下：
其中包含四大部分：
已傳送且已確認
已傳送但未確認
未傳送但可以傳送
未傳送也不可以傳送 其中有一些重要的概念，我標註在圖中：
傳送視窗就是圖中被框住的範圍。SND 即send， WND 即window， UNA 即unacknowledged， 表示未被確認，NXT 即next， 表示下一個傳送的位置。
接收視窗
接收端的視窗結構如下：
REV
即
receive
，
NXT
表示下一個接收的位置，
WND
表示接收視窗大小。
流量控制過程
這裡我們不用太複雜的例子，以一個最簡單的來回來模擬一下流量控制的過程，方便大家理解。首先雙方三次握手，初始化各自的視窗大小，均為
200
個位元組。
假如當前傳送端給接收端傳送
100
個位元組，那麼此時對於傳送端而言，
SND。NXT
當然要右移 100 個位元組，也就是說當前的
可用視窗
減少了
100
個位元組，這很好理解。
現在這 100 個到達了接收端，被放到接收端的緩衝佇列中。不過此時由於大量負載的原因，接收端處理不了這麼多位元組，只能處理
40
個位元組，剩下的
60
個位元組被留在了緩衝佇列中。
注意了，此時接收端的情況是處理能力不夠用啦，你傳送端給我少發點，所以此時接收端的接收視窗應該縮小，具體來說，縮小
60
個位元組，由
200
個位元組變成了
140
位元組，因為緩衝佇列還有
60
個位元組沒被應用拿走。
因此，接收端會在
ACK
的報文首部帶上縮小後的滑動視窗
140
位元組，傳送端對應地調整發送視窗的大小為
140
個位元組。
此時對於傳送端而言，已經發送且確認的部分增加
40
位元組，也就是
SND。UNA
右移
40
個位元組，同時傳送視窗縮小為
140
個位元組。
這也就是流量控制的過程。儘管回合再多，整個控制的過程和原理是一樣的。
10、能不能說說 TCP 的擁塞控制？
上一節所說的流量控制發生在傳送端跟接收端之間，並沒有考慮到整個網路環境的影響，如果說當前網路特別差，特別容易丟包，那麼傳送端就應該注意一些了。而這，也正是擁塞控制需要處理的問題。
對於擁塞控制來說，TCP 每條連線都需要維護兩個核心狀態：
擁塞視窗（Congestion Window，cwnd）
慢啟動閾值（Slow Start Threshold，ssthresh）
涉及到的演算法有這幾個：
慢啟動
擁塞避免
快速重傳和快速恢復 接下來，我們就來一一拆解這些狀態和演算法。首先，從擁塞視窗說起。
擁塞視窗
擁塞視窗（
Congestion Window，cwnd
）是指目前自己還能傳輸的資料量大小。
那麼之前介紹了接收視窗的概念，兩者有什麼區別呢？
接收視窗（rwnd）是接收端給的限制
擁塞視窗（cwnd）是傳送端的限制
限制誰呢？
限制的是傳送視窗的大小。
有了這兩個視窗，如何來計算傳送視窗？
傳送視窗大小 = min（rwnd， cwnd）
取兩者的較小值。而擁塞控制，就是來控制
cwnd
的變化。
慢啟動
剛開始進入傳輸資料的時候，你是不知道現在的網路到底是穩定還是擁堵的，如果做的太激進，發包太急，那麼瘋狂丟包，造成雪崩式的網路災難。
因此，擁塞控制首先就是要採用一種保守的演算法來慢慢地適應整個網路，這種演算法叫慢啟動。運作過程如下：
首先，三次握手，雙方宣告自己的接收視窗大小
雙方初始化自己的擁塞視窗（cwnd）大小
在開始傳輸的一段時間，傳送端每收到一個 ACK，擁塞視窗大小加 1，也就是說，每經過一個 RTT，cwnd 翻倍。如果說初始視窗為 10，那麼第一輪 10 個報文傳完且傳送端收到 ACK 後，cwnd 變為 20，第二輪變為 40，第三輪變為 80，依次類推。
難道就這麼無止境地翻倍下去？當然不可能。它的閾值叫做慢啟動閾值，當 cwnd 到達這個閾值之後，好比踩了下剎車，別漲了那麼快了，老鐵，先 hold 住！
在到達閾值後，如何來控制 cwnd 的大小呢？
這就是擁塞避免做的事情了。
擁塞避免
原來每收到一個 ACK，cwnd 加1，現在到達閾值了，cwnd 只能加這麼一點： 1 / cwnd。那你仔細算算，一輪 RTT 下來，收到 cwnd 個 ACK， 那最後擁塞視窗的大小 cwnd 總共才增加 1。
也就是說，以前一個 RTT 下來，cwnd翻倍，現在cwnd只是增加 1 而已。
當然，慢啟動和擁塞避免是一起作用的，是一體的。
快速重傳和快速恢復
快速重傳
在 TCP 傳輸的過程中，如果發生了丟包，即接收端發現數據段不是按序到達的時候，接收端的處理是重複傳送之前的 ACK。
比如第 5 個包丟了，即使第 6、7 個包到達的接收端，接收端也一律返回第 4 個包的 ACK。當傳送端收到 3 個重複的 ACK 時，意識到丟包了，於是馬上進行重傳，不用等到一個 RTO 的時間到了才重傳。
這就是快速重傳，它解決的是是否需要重傳的問題。
選擇性重傳
那你可能會問了，既然要重傳，那麼只重傳第 5 個包還是第5、6、7 個包都重傳呢？
當然第 6、7 個都已經到達了，TCP 的設計者也不傻，已經傳過去幹嘛還要傳？乾脆記錄一下哪些包到了，哪些沒到，針對性地重傳。
在收到傳送端的報文後，接收端回覆一個 ACK 報文，那麼在這個報文首部的可選項中，就可以加上SACK這個屬性，透過left edge和right edge告知傳送端已經收到了哪些區間的資料報。因此，即使第 5 個包丟包了，當收到第 6、7 個包之後，接收端依然會告訴傳送端，這兩個包到了。剩下第 5 個包沒到，就重傳這個包。這個過程也叫做選擇性重傳（SACK，Selective Acknowledgment），它解決的是如何重傳的問題。
快速恢復
當然，傳送端收到三次重複 ACK 之後，發現丟包，覺得現在的網路已經有些擁塞了，自己會進入快速恢復階段。
在這個階段，傳送端如下改變：
擁塞閾值降低為 cwnd 的一半
cwnd 的大小變為擁塞閾值
cwnd 線性增加
以上就是 TCP 擁塞控制的經典演算法： 慢啟動、擁塞避免、快速重傳和快速恢復。
11、能不能說說 Nagle 演算法和延遲確認？
Nagle 演算法
試想一個場景，傳送端不停地給接收端發很小的包，一次只發 1 個位元組，那麼發 1 千個位元組需要發 1000 次。這種頻繁的傳送是存在問題的，不光是傳輸的時延消耗，傳送和確認本身也是需要耗時的，頻繁的傳送接收帶來了巨大的時延。
而避免小包的頻繁傳送，這就是 Nagle 演算法要做的事情。
具體來說，Nagle 演算法的規則如下：
當第一次傳送資料時不用等待，就算是 1byte 的小包也立即傳送
後面傳送滿足下麵條件之一就可以發了：
資料包大小達到最大段大小（Max Segment Size， 即 MSS）
之前所有包的 ACK 都已接收到
延遲確認
試想這樣一個場景，當我收到了傳送端的一個包，然後在極短的時間內又接收到了第二個包，那我是一個個地回覆，還是稍微等一下，把兩個包的 ACK 合併後一起回覆呢？
延遲確認（delayed ack）所做的事情，就是後者，稍稍延遲，然後合併 ACK，最後才回復給傳送端。TCP 要求這個延遲的時延必須小於500ms，一般作業系統實現都不會超過200ms。
不過需要主要的是，有一些場景是不能延遲確認的，收到了就要馬上回復：
接收到了大於一個 frame 的報文，且需要調整視窗大小
TCP 處於 quickack 模式（透過tcp_in_quickack_mode設定）
發現了亂序包
12、如何理解 TCP 的 keep-alive？
大家都聽說過 http 的keep-alive， 不過 TCP 層面也是有keep-alive機制，而且跟應用層不太一樣。
試想一個場景，當有一方因為網路故障或者宕機導致連線失效，由於 TCP 並不是一個輪詢的協議，在下一個資料包到達之前，對端對連線失效的情況是一無所知的。
這個時候就出現了 keep-alive， 它的作用就是探測對端的連線有沒有失效。
在 Linux 下，可以這樣檢視相關的配置：
sudo sysctl -a | grep keepalive// 每隔 7200 s 檢測一次net。ipv4。tcp_keepalive_time = 7200// 一次最多重傳 9 個包net。ipv4。tcp_keepalive_probes = 9// 每個包的間隔重傳間隔 75 snet。ipv4。tcp_keepalive_intvl = 75
不過，現狀是大部分的應用並沒有預設開啟 TCP 的keep-alive選項，為什麼？
站在應用的角度：
7200s 也就是兩個小時檢測一次，時間太長
時間再短一些，也難以體現其設計的初衷， 即檢測長時間的死連線
因此是一個比較尷尬的設計。
總結
如果覺得對你有幫助的話，期待你的點贊、在看和轉發，謝啦。
