面試時你能把TCP講到這些程度，我真當你精通了~

關註上方 浩道Linux ，回復 資料 ，即可獲取海量 L inux 、 Python 、 網路通訊、網路安全 等學習資料！

前言

大家好，這裏是 浩道Linux ，主要給大家分享 L inux 、 P ython 、 網路通訊、網路安全等 相關的IT知識平台。

好多朋友擔心面試時被面試官問到TCP相關的知識，因為要回答好這一塊知識點並不容易。今天浩道跟大家分享關於TCP協定相關的硬核幹貨，關於面試中常常被問到的TCP相關知識，本文已經整理總結好，希望大家可以收藏好隨時復習，做到面試不用慌！

文章來源： https://juejin.cn/post/6844904070889603085

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

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

首先概括一下基本的區別:

TCP是一個面向連線的、可靠的、基於字節流的傳輸層協定。

而 UDP是一個面向無連線的傳輸層協定。 (就這麽簡單，其它TCP的特性也就沒有了)。

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

1. 面向連線 。所謂的連線，指的是客戶端和伺服器的連線，在雙方互相通訊之前，TCP 需要三次握手建立連線，而 UDP 沒有相應建立連線的過程。

2. 可靠性 。TCP 花了非常多的功夫保證連線的可靠，這個可靠性體現在哪些方面呢？一個是有狀態，另一個是可控制。

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

當意識到丟包了或者網路環境不佳，TCP 會根據具體情況調整自己的行為，控制自己的發送速度或者重發。這是 可控制 。

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

3. 面向字節流 。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?

這就是等待 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 攻擊？

005: 介紹一下 TCP 報文頭部的欄位

報文頭部結構如下(單位為字節):

請大家牢記這張圖！

源埠、目標埠

如何標識唯一標識一個連線？答案是 TCP 連線的 四元組 ——源 IP、源埠、目標 IP 和目標埠。

那 TCP 報文怎麽沒有源 IP 和目標 IP 呢？這是因為在 IP 層就已經處理了 IP 。TCP 只需要記錄兩者的埠即可。

序列號

即 Sequence number , 指的是本報文段第一個字節的序列號。

從圖中可以看出，序列號是一個長為 4 個字節，也就是 32 位的無符號整數，表示範圍為 0 ~ 2^32 - 1。如果到達最大值了後就迴圈到0。

序列號在 TCP 通訊的過程中有兩個作用:

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 直接丟棄之，等待重傳。

可選項

可選項的格式如下:

常用的可選項有以下幾個:

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

在沒有時間戳的時候，計算 RTT 會遇到的問題如下圖所示:

如果以第一次發包為開始時間的話，就會出現左圖的問題，RTT 明顯偏大，開始時間應該采用第二次的；

如果以第二次發包為開始時間的話，就會導致右圖的問題，RTT 明顯偏小，開始時間應該采用第一次發包的。

實際上無論開始時間以第一次發包還是第二次發包為準，都是不準確的。

那這個時候引入時間戳就很好的解決了這個問題。

比如現在 a 向 b 發送一個報文 s1，b 向 a 回復一個含 ACK 的報文 s2 那麽：

防止序列號回繞問題

現在我們來模擬一下這個問題。

序列號的範圍其實是在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）是指目前自己還能傳輸的數據量大小。

那麽之前介紹了接收視窗的概念，兩者有什麽區別呢？

限制誰呢？

限制的是 發送視窗 的大小。

有了這兩個視窗，如何來計算 發送視窗 ？

發送視窗大小 = min(rwnd, cwnd)

取兩者的較小值。而擁塞控制，就是來控制 cwnd 的變化。

慢啟動

剛開始進入傳輸數據的時候，你是不知道現在的網路到底是穩定還是擁堵的，如果做的太激進，發包太急，那麽瘋狂丟包，造成雪崩式的網路災難。

因此，擁塞控制首先就是要采用一種保守的演算法來慢慢地適應整個網路，這種演算法叫 慢啟動 。運作過程如下:

難道就這麽無止境地翻倍下去？當然不可能。它的閾值叫做 慢啟動閾值 ，當 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 之後，發現丟包，覺得現在的網路已經有些擁塞了，自己會進入 快速恢復 階段。

在這個階段，發送端如下改變：

以上就是 TCP 擁塞控制的經典演算法: 慢啟動 、 擁塞避免 、 快速重傳和快速恢復 。

011: 能不能說說 Nagle 演算法和延遲確認？

Nagle 演算法

試想一個場景，發送端不停地給接收端發很小的包，一次只發 1 個字節，那麽發 1 千個字節需要發 1000 次。這種頻繁的發送是存在問題的，不光是傳輸的時延消耗，發送和確認本身也是需要耗時的，頻繁的發送接收帶來了巨大的時延。

而避免小包的頻繁發送，這就是 Nagle 演算法要做的事情。

具體來說，Nagle 演算法的規則如下:

延遲確認

試想這樣一個場景，當我收到了發送端的一個包，然後在極短的時間內又接收到了第二個包，那我是一個個地回復，還是稍微等一下，把兩個包的 ACK 合並後一起回復呢？

延遲確認 (delayed ack)所做的事情，就是後者，稍稍延遲，然後合並 ACK，最後才回復給發送端。TCP 要求這個延遲的時延必須小於500ms，一般作業系統實作都不會超過200ms。

不過需要主要的是，有一些場景是不能延遲確認的，收到了就要馬上回復:

兩者一起使用會怎樣？

前者意味著延遲發，後者意味著延遲接收，會造成更大的延遲，產生效能問題。

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 選項，為什麽？

站在套用的角度:

因此是一個比較尷尬的設計。

更多精彩

關註公眾號 「 浩道Linux 」

浩道Linux ，專註於 Linux系統 的相關知識、 網路通訊 、 網路安全 、 Python相關 知識以及涵蓋IT行業相關技能的學習， 理論與實戰結合，真正讓你在學習工作中真正去用到所學。同時也會分享一些面試經驗，助你找到高薪offer，讓我們一起去學習，一起去進步，一起去漲薪！期待您的加入~~~ 關註回復「資料」可 免費獲取學習資料 （含有電子書籍、視訊等）。

喜歡的話，記得 點「贊」 和 「在看」 哦