建議收藏！TCP協議面試靈魂12 問

來源 | urlify.cn/rqumIn

先亮出這篇文章的思惟導圖:

TCP 做爲傳輸層的協議，是一個IT工程師素養的體現，也是面試中常常被問到的知識點。在此，我將 TCP 核心的一些問題梳理了一下，但願能幫到各位。

001. 能不能說一說 TCP 和 UDP 的區別？

首先歸納一下基本的區別:

TCP是一個面向鏈接的、可靠的、基於字節流的傳輸層協議。

而UDP是一個面向無鏈接的傳輸層協議。(就這麼簡單，其它TCP的特性也就沒有了)。

具體來分析，和 UDP 相比，TCP 有三大核心特性:

1. 面向鏈接。所謂的鏈接，指的是客戶端和服務器的鏈接，在雙方互相通訊以前，TCP 須要三次握手創建鏈接，而 UDP 沒有相應創建鏈接的過程。
2. 可靠性。TCP 花了很是多的功夫保證鏈接的可靠，這個可靠性體如今哪些方面呢？一個是有狀態，另外一個是可控制。

TCP 會精準記錄哪些數據發送了，哪些數據被對方接收了，哪些沒有被接收到，並且保證數據包按序到達，不容許半點差錯。這是有狀態。

當意識到丟包了或者網絡環境不佳，TCP 會根據具體狀況調整本身的行爲，控制本身的發送速度或者重發。這是可控制。

相應的，UDP 就是無狀態, 不可控的。

1. 面向字節流。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。對於服務端而言，會產生兩個危險的後果:

1. 處理大量的SYN包並返回對應ACK, 勢必有大量鏈接處於SYN_RCVD狀態，從而佔滿整個半鏈接隊列，沒法處理正常的請求。
2. 因爲是不存在的 IP，服務端長時間收不到客戶端的ACK，會致使服務端不斷重發數據，直到耗盡服務端的資源。

如何應對 SYN Flood 攻擊？

• 增長 SYN 鏈接，也就是增長半鏈接隊列的容量。
• 減小 SYN + ACK 重試次數，避免大量的超時重發。
• 利用 SYN Cookie 技術，在服務端接收到SYN後不當即分配鏈接資源，而是根據這個SYN計算出一個Cookie，連同第二次握手回覆給客戶端，在客戶端回覆ACK的時候帶上這個Cookie值，服務端驗證 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。

假設在第 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 個包丟了，即便第 六、7 個包到達的接收端，接收端也一概返回第 4 個包的 ACK。當發送端收到 3 個重複的 ACK 時，意識到丟包了，因而立刻進行重傳，不用等到一個 RTO 的時間到了才重傳。

這就是快速重傳，它解決的是是否須要重傳的問題。

選擇性重傳

那你可能會問了，既然要重傳，那麼只重傳第 5 個包仍是第五、六、7 個包都重傳呢？

固然第 六、7 個都已經到達了，TCP 的設計者也不傻，已經傳過去幹嗎還要傳？乾脆記錄一下哪些包到了，哪些沒到，針對性地重傳。

在收到發送端的報文後，接收端回覆一個 ACK 報文，那麼在這個報文首部的可選項中，就能夠加上SACK這個屬性，經過left edge和right edge告知發送端已經收到了哪些區間的數據報。所以，即便第 5 個包丟包了，當收到第 六、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 snet.ipv4.tcp_keepalive_intvl = 75

不過，現狀是大部分的應用並無默認開啓 TCP 的keep-alive選項，爲何？

站在應用的角度:

• 7200s 也就是兩個小時檢測一次，時間太長
• 時間再短一些，也難以體現其設計的初衷, 即檢測長時間的死鏈接

所以是一個比較尷尬的設計。