TCP協議面試靈魂10問,建議收藏~
點擊上方 “ 匠心零度 ” ,選擇“ 設爲星標 ”
做積極的人,而不是積極廢人
來源 | https://urlify.cn/rqumIn
先亮出這篇文章的思維導圖
TCP 作爲傳輸層的協議,是一個軟件工程師素養的體現,也是面試中經常被問到的知識點。在此,我將 TCP 核心的一些問題梳理了一下,希望能幫到各位。
001. 能不能說一說 TCP 和 UDP 的區別?
首先概括一下基本的區別:
TCP是一個面向連接的、可靠的、基於字節流的傳輸層協議。
而 UDP是一個面向無連接的傳輸層協議。 (就這麼簡單,其它TCP的特性也就沒有了)。
具體來分析,和 UDP
相比, TCP
有三大核心特性:
-
面向連接。所謂的連接,指的是客戶端和服務器的連接,在雙方互相通信之前,TCP 需要三次握手建立連接,而 UDP 沒有相應建立連接的過程。
-
可靠性。TCP 花了非常多的功夫保證連接的可靠,這個可靠性體現在哪些方面呢?一個是有狀態,另一個是可控制。
TCP 會精準記錄哪些數據發送了,哪些數據被對方接收了,哪些沒有被接收到,而且保證數據包按序到達,不允許半點差錯。這是 有狀態 。
當意識到丟包了或者網絡環境不佳,TCP 會根據具體情況調整自己的行爲,控制自己的發送速度或者重發。這是 可控制 。
相應的,UDP 就是 無狀態
, 不可控
的。
-
面向字節流。UDP 的數據傳輸是基於數據報的,這是因爲僅僅只是繼承了 IP 層的特性,而 TCP 爲了維護狀態,將一個個 IP 包變成了字節流。
002: 說說 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
。
這就是同時打開情況下的狀態變遷。
003: 說說 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 ,狀態會如何變化?如圖所示:
004: 說說半連接隊列和 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 SYN ACK Cookie
005: 介紹一下 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:窗口縮放選項。
006: 說說 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 響應到達才發送,兩個過程沒有任何關係。
TFO 的優勢
TFO 的優勢並不在與首輪三次握手,而在於後面的握手,在拿到客戶端的 Cookie 並驗證通過以後,可以直接返回 HTTP 響應,充分利用了 1 個RTT (Round-Trip Time,往返時延)的時間 提前進行數據傳輸 ,積累起來還是一個比較大的優勢。
007: 能不能說說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。
第幾次發包 | 發送字節 | 對應序列號 | 狀態 |
---|---|---|---|
1 | 0 ~ 1 | 0 ~ 1 | 成功接收 |
2 | 1 ~ 2 | 1 ~ 2 | 滯留在網絡中 |
3 | 2 ~ 3 | 2 ~ 3 | 成功接收 |
4 | 3 ~ 4 | 3 ~ 4 | 成功接收 |
5 | 4 ~ 5 | 0 ~ 1 | 成功接收,序列號從0開始 |
6 | 5 ~ 6 | 1 ~ 2 | ??? |
假設在第 6 次的時候,之前還滯留在網路中的包回來了,那麼就有兩個序列號爲 1 ~ 2
的數據包了,怎麼區分誰是誰呢?這個時候就產生了序列號迴繞的問題。
那麼用 timestamp 就能很好地解決這個問題,因爲每次發包的時候都是將發包機器當時的內核時間記錄在報文中,那麼兩次發包序列號即使相同,時間戳也不可能相同,這樣就能夠區分開兩個數據包了。
008: 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 變化的差值關係更加密切。
009: 能不能說一說 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 個字節。
這也就是 流量控制 的過程。儘管回合再多,整個控制的過程和原理是一樣的。
010: 能不能說說 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 擁塞控制的經典算法: 慢啓動 、 擁塞避免 、 快速重傳和快速恢復 。
011: 能不能說說 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
設置) -
發現了亂序包
兩者一起使用會怎樣?
前者意味着延遲發,後者意味着延遲接收,會造成更大的延遲,產生性能問題。
012. 如何理解 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 s
net.ipv4.tcp_keepalive_intvl = 75
不過,現狀是大部分的應用並沒有默認開啓 TCP 的 keep-alive
選項,爲什麼?
站在應用的角度:
-
7200s 也就是兩個小時檢測一次,時間太長
-
時間再短一些,也難以體現其設計的初衷, 即檢測長時間的死連接
因此是一個比較尷尬的設計。
END
如果讀完覺得有收穫的話,歡迎點【好看】,關注【匠心零度】,查閱更多精彩歷史!!!
讓我“ 好看 ”