目錄

TCP 的特性

三次握手與四次揮手

三次握手：

?靈魂拷問：

四次揮手：

靈魂拷問：

TCP 的特性

TCP 提供一種面向連接的、可靠的字節(jié)流服務
在一個 TCP 連接中，僅有兩方進行彼此通信。廣播和多播不能用于 TCP
TCP 使用校驗和，確認和重傳機制來保證可靠傳輸
TCP 給數(shù)據(jù)分節(jié)進行排序，并使用累積確認保證數(shù)據(jù)的順序不變和非重復
TCP 使用滑動窗口機制來實現(xiàn)流量控制，通過動態(tài)改變窗口的大小進行擁塞控制
注意：TCP 并不能保證數(shù)據(jù)一定會被對方接收到，因為這是不可能的。TCP 能夠做到的是，如果有可能，就把數(shù)據(jù)遞送到接收方，否則就（通過放棄重傳并且中斷連接這一手段）通知用戶。因此準確說 TCP 也不是 100% 可靠的協(xié)議，它所能提供的是數(shù)據(jù)的可靠遞送或故障的可靠通知。

三次握手與四次揮手

三次握手：

所謂三次握手(Three-way Handshake)，是指建立一個 TCP 連接時，需要客戶端和服務器總共發(fā)送3個包。

三次握手的目的是連接服務器指定端口，建立 TCP 連接，并同步連接雙方的序列號和確認號，交換 TCP 窗口大小信息。在 socket 編程中，客戶端執(zhí)行?connect()?時。將觸發(fā)三次握手。

• 第一次握手(SYN=1, seq=x):

客戶端發(fā)送一個 TCP 的 SYN 標志位置1的包，指明客戶端打算連接的服務器的端口，以及初始序號 X,保存在包頭的序列號(Sequence Number)字段里。

發(fā)送完畢后，客戶端進入?SYN_SEND?狀態(tài)。

• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):

服務器發(fā)回確認包(ACK)應答。即 SYN 標志位和 ACK 標志位均為1。服務器端選擇自己 ISN 序列號，放到 Seq 域里，同時將確認序號(Acknowledgement Number)設置為客戶的 ISN 加1，即X+1。 發(fā)送完畢后，服務器端進入?SYN_RCVD?狀態(tài)。

• 第三次握手(ACK=1，ACKnum=y+1)

客戶端再次發(fā)送確認包(ACK)，SYN 標志位為0，ACK 標志位為1，并且把服務器發(fā)來 ACK 的序號字段+1，放在確定字段中發(fā)送給對方，并且在數(shù)據(jù)段放寫ISN的+1

發(fā)送完畢后，客戶端進入?ESTABLISHED?狀態(tài)，當服務器端接收到這個包時，也進入?ESTABLISHED?狀態(tài)，TCP 握手結束。

三次握手的過程的示意圖如下：

?靈魂拷問：

1、為什么是三次握手而不是兩次？

????????根本原因: 無法確認客戶端的接收能力。

如果是兩次，你現(xiàn)在發(fā)了 SYN 報文想握手，但是這個包滯留在了當前的網絡中遲遲沒有到達，TCP 以為這是丟了包，于是重傳，兩次握手建立好了連接。

看似沒有問題，但是連接關閉后，如果這個滯留在網路中的包到達了服務端呢？這時候由于是兩次握手，服務端只要接收到然后發(fā)送相應的數(shù)據(jù)包，就默認建立連接，但是現(xiàn)在客戶端已經斷開了。

看到問題的吧，這就帶來了連接資源的浪費。

備注：

丟包的數(shù)據(jù) 服務器會根據(jù)時間戳或者根據(jù)響應時間 判定是否接受 這個請求/數(shù)據(jù)；

2、為什么不是四次？

三次握手的目的是確認雙方發(fā)送和接收的能力，那四次握手可以嘛？

當然可以，100 次都可以。但為了解決問題，三次就足夠了，再多用處就不大了。

3、三次握手過程中可以攜帶數(shù)據(jù)么？

第三次握手的時候，可以攜帶。前兩次握手不能攜帶數(shù)據(jù)。

如果前兩次握手能夠攜帶數(shù)據(jù)，那么一旦有人想攻擊服務器，那么他只需要在第一次握手中的 SYN 報文中放大量數(shù)據(jù)，那么服務器勢必會消耗更多的時間和內存空間去處理這些數(shù)據(jù)，增大了服務器被攻擊的風險。

第三次握手的時候，客戶端已經處于ESTABLISHED狀態(tài)，并且已經能夠確認服務器的接收、發(fā)送能力正常，這個時候相對安全了，可以攜帶數(shù)據(jù)。

4、同時打開會怎樣？

如果雙方同時發(fā)?SYN報文，狀態(tài)變化會是怎樣的呢？

這是一個可能會發(fā)生的情況。

狀態(tài)變遷如下:

在發(fā)送方給接收方發(fā)SYN報文的同時，接收方也給發(fā)送方發(fā)SYN報文，兩個人剛上了!

發(fā)完SYN，兩者的狀態(tài)都變?yōu)?span style="color:#be191c;">SYN-SENT。

在各自收到對方的SYN后，兩者狀態(tài)都變?yōu)?span style="color:#be191c;">SYN-REVD。

接著會回復對應的ACK + SYN，這個報文在對方接收之后，兩者狀態(tài)一起變?yōu)?span style="color:#be191c;">ESTABLISHED。

這就是同時打開情況下的狀態(tài)變遷。

四次揮手：

?TCP 的連接的關閉需要發(fā)送四個包，因此稱為四次揮手(Four-way handshake)，也叫做改進的三次握手?？蛻舳嘶蚍掌骶芍鲃影l(fā)起揮手動作，在 socket 編程中，任何一方執(zhí)行?close()?操作即可產生揮手操作。

• 第一次揮手(FIN=1，seq=x)

假設客戶端想要關閉連接，客戶端發(fā)送一個 FIN 標志位置為1的包，表示自己已經沒有數(shù)據(jù)可以發(fā)送了，但是仍然可以接受數(shù)據(jù)。

發(fā)送完畢后，客戶端進入?FIN_WAIT_1?狀態(tài)。

• 第二次揮手(ACK=1，ACKnum=x+1)

服務器端確認客戶端的 FIN 包，發(fā)送一個確認包，表明自己接受到了客戶端關閉連接的請求，但還沒有準備好關閉連接。

發(fā)送完畢后，服務器端進入?CLOSE_WAIT?狀態(tài)，客戶端接收到這個確認包之后，進入?FIN_WAIT_2?狀態(tài)，等待服務器端關閉連接。

• 第三次揮手(FIN=1，seq=y)

服務器端準備好關閉連接時，向客戶端發(fā)送結束連接請求，F(xiàn)IN 置為1。

發(fā)送完畢后，服務器端進入?LAST_ACK?狀態(tài)，等待來自客戶端的最后一個ACK。

• 第四次揮手(ACK=1，ACKnum=y+1)

客戶端接收到來自服務器端的關閉請求，發(fā)送一個確認包，并進入?TIME_WAIT狀態(tài)，等待可能出現(xiàn)的要求重傳的 ACK 包。

服務器端接收到這個確認包之后，關閉連接，進入?CLOSED?狀態(tài)。

客戶端等待了某個固定時間（兩個最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，在這段時間內如果客戶端沒有收到服務端的重發(fā)請求（沒有收到服務器端的 ACK ），那么表示 ACK 成功到達，于是自己也關閉連接，進入?CLOSED?狀態(tài)，揮手結束；否則客戶端重發(fā) ACK。

四次揮手的示意圖如下：

?

靈魂拷問：

1、等待2MSL的意義，如果不等待會怎樣？

如果不等待，客戶端直接跑路，當服務端還有很多數(shù)據(jù)包要給客戶端發(fā)，且還在路上的時候，若客戶端的端口此時剛好被新的應用占用，那么就接收到了無用數(shù)據(jù)包，造成數(shù)據(jù)包混亂。所以，最保險的做法是等服務器發(fā)來的數(shù)據(jù)包都死翹翹再啟動新的應用。

那，照這樣說一個 MSL 不就不夠了嗎，為什么要等待 2 MSL?

• 1 個 MSL 確保四次揮手中主動關閉方最后的 ACK 報文最終能達到對端
• 1 個 MSL 確保對端沒有收到 ACK ，重傳的 FIN 報文可以到達

這就是等待 2MSL 的意義。

2、為什么是四次揮手而不是三次？

因為服務端在接收到FIN, 往往不會立即返回FIN, 必須等到服務端所有的報文都發(fā)送完畢了，才能發(fā)FIN。因此先發(fā)一個ACK表示已經收到客戶端的FIN，延遲一段時間才發(fā)FIN。這就造成了四次揮手。

3、如果是三次揮手會有什么問題？

等于說服務端將ACK和FIN的發(fā)送合并為一次揮手，這個時候長時間的延遲可能會導致客戶端誤以為FIN沒有到達客戶端，從而讓客戶端不斷的重發(fā)FIN。

4、同時關閉會怎樣？

如果客戶端和服務端同時發(fā)送 FIN ，狀態(tài)會如何變化？如圖所示:

5、說說半連接隊列和 SYN Flood 攻擊的關系

三次握手前，服務端的狀態(tài)從CLOSED變?yōu)長ISTEN, 同時在內部創(chuàng)建了兩個隊列：半連接隊列和全連接隊列，即SYN隊列和ACCEPT隊列。

半連接隊列

當客戶端發(fā)送SYN到服務端，服務端收到以后回復ACK和SYN，狀態(tài)由LISTEN變?yōu)镾YN_RCVD，此時這個連接就被推入了SYN隊列，也就是半連接隊列。

全連接隊列

當客戶端返回ACK, 服務端接收后，三次握手完成。這個時候連接等待被具體的應用取走，在被取走之前，它會被推入另外一個 TCP 維護的隊列，也就是全連接隊列(Accept Queue)。

SYN Flood 攻擊原理

SYN Flood 屬于典型的 DoS/DDoS 攻擊。其攻擊的原理很簡單，就是用客戶端在短時間內偽造大量不存在的 IP 地址，并向服務端瘋狂發(fā)送SYN。對于服務端而言，會產生兩個危險的后果:

1. 處理大量的SYN包并返回對應ACK, 勢必有大量連接處于SYN_RCVD狀態(tài)，從而占滿整個半連接隊列，無法處理正常的請求。
2. 由于是不存在的 IP，服務端長時間收不到客戶端的ACK，會導致服務端不斷重發(fā)數(shù)據(jù)，直到耗盡服務端的資源。

6、如何應對 SYN Flood 攻擊？

1. 增加 SYN 連接，也就是增加半連接隊列的容量。
2. 減少 SYN + ACK 重試次數(shù)，避免大量的超時重發(fā)。
3. 利用 SYN Cookie 技術，在服務端接收到SYN后不立即分配連接資源，而是根據(jù)這個SYN計算出一個Cookie，連同第二次握手回復給客戶端，在客戶端回復ACK的時候帶上這個Cookie值，服務端驗證 Cookie 合法之后才分配連接資源

7、介紹一下 TCP 報文頭部的字段

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

請大家牢記這張圖

源端口、目標端口

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

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

序列號

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

從圖中可以看出，序列號是一個長為 4 個字節(jié)，也就是 32 位的無符號整數(shù)，表示范圍為 0 ~ 2^32 - 1。如果到達最大值了后就循環(huán)到0。

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

1. 在 SYN 報文中交換彼此的初始序列號。
2. 保證數(shù)據(jù)包按正確的順序組裝。

ISN

即Initial Sequence Number（初始序列號）,在三次握手的過程當中，雙方會用過SYN報文來交換彼此的?ISN。

ISN 并不是一個固定的值，而是每 4 ms 加一，溢出則回到 0，這個算法使得猜測 ISN 變得很困難。那為什么要這么做？

如果 ISN 被攻擊者預測到，要知道源 IP 和源端口號都是很容易偽造的，當攻擊者猜測 ISN 之后，直接偽造一個 RST 后，就可以強制連接關閉的，這是非常危險的。

而動態(tài)增長的 ISN 大大提高了猜測 ISN 的難度。

確認號

即ACK(Acknowledgment number)。用來告知對方下一個期望接收的序列號，小于ACK的所有字節(jié)已經全部收到。

標記位

常見的標記位有SYN,ACK,FIN,RST,PSH。

SYN 和 ACK 已經在上文說過，后三個解釋如下:?FIN： 即 Finish，表示發(fā)送方準備斷開連接。

RST：即 Reset，用來強制斷開連接。

PSH： 即 Push, 告知對方這些數(shù)據(jù)包收到后應該馬上交給上層的應用，不能緩存。

窗口大小

占用兩個字節(jié)，也就是 16 位，但實際上是不夠用的。因此 TCP 引入了窗口縮放的選項，作為窗口縮放的比例因子，這個比例因子的范圍在 0 ~ 14，比例因子可以將窗口的值擴大為原來的 2 ^ n 次方。

校驗和

占用兩個字節(jié)，防止傳輸過程中數(shù)據(jù)包有損壞，如果遇到校驗和有差錯的報文，TCP 直接丟棄之，等待重傳。

可選項

可選項的格式如下:

TimeStamp: TCP 時間戳，后面詳細介紹。

MSS: 指的是 TCP 允許的從對方接收的最大報文段。

SACK: 選擇確認選項。

Window Scale： 窗口縮放選項。

8、說說 TCP 快速打開的原理(TFO)

第一節(jié)講了 TCP 三次握手，可能有人會說，每次都三次握手好麻煩呀！能不能優(yōu)化一點？

可以啊。今天來說說這個優(yōu)化后的 TCP 握手流程，也就是 TCP 快速打開(TCP Fast Open, 即TFO)的原理。

優(yōu)化的過程是這樣的，還記得我們說 SYN Flood 攻擊時提到的 SYN Cookie 嗎？這個 Cookie 可不是瀏覽器的Cookie, 用它同樣可以實現(xiàn) TFO。

TFO 流程

首輪三次握手

首先客戶端發(fā)送SYN給服務端，服務端接收到。

注意哦！現(xiàn)在服務端不是立刻回復 SYN + ACK，而是通過計算得到一個SYN Cookie, 將這個Cookie放到 TCP 報文的?Fast Open選項中，然后才給客戶端返回。

客戶端拿到這個 Cookie 的值緩存下來。后面正常完成三次握手。

首輪三次握手就是這樣的流程。而后面的三次握手就不一樣啦！

后面的三次握手

在后面的三次握手中，客戶端會將之前緩存的?Cookie、SYN?和HTTP請求(是的，你沒看錯)發(fā)送給服務端，服務端驗證了 Cookie 的合法性，如果不合法直接丟棄；如果是合法的，那么就正常返回SYN + ACK。

重點來了，現(xiàn)在服務端能向客戶端發(fā) HTTP 響應了！這是最顯著的改變，三次握手還沒建立，僅僅驗證了 Cookie 的合法性，就可以返回 HTTP 響應了。

當然，客戶端的ACK還得正常傳過來，不然怎么叫三次握手嘛。

流程如下:

注意: 客戶端最后握手的 ACK 不一定要等到服務端的 HTTP 響應到達才發(fā)送，兩個過程沒有任何關系。

TFO 的優(yōu)勢

TFO 的優(yōu)勢并不在與首輪三次握手，而在于后面的握手，在拿到客戶端的 Cookie 并驗證通過以后，可以直接返回 HTTP 響應，充分利用了1 個RTT(Round-Trip Time，往返時延)的時間提前進行數(shù)據(jù)傳輸，積累起來還是一個比較大的優(yōu)勢。

9、能不能說說TCP報文中時間戳的作用？

timestamp是 TCP 報文首部的一個可選項，一共占 10 個字節(jié)，格式如下:

kind(1 字節(jié)) + length(1 字節(jié)) + info(8 個字節(jié))?

其中 kind = 8， length = 10， info 有兩部分構成:?timestamp和timestamp echo，各占 4 個字節(jié)。

那么這些字段都是干嘛的呢？它們用來解決那些問題？

接下來我們就來一一梳理，TCP 的時間戳主要解決兩大問題:

• 計算往返時延 RTT(Round-Trip Time)
• 防止序列號的回繞問題

計算往返時延 RTT

在沒有時間戳的時候，計算 RTT 會遇到以下問題：

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

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

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

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

比如現(xiàn)在 a 向 b 發(fā)送一個報文 s1，b 向 a 回復一個含 ACK 的報文 s2 那么：

• step 1:?a 向 b 發(fā)送的時候，timestamp?中存放的內容就是 a 主機發(fā)送時的內核時刻?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 對應的報文最初的發(fā)送時刻。然后直接采用 ta2 - ta1 就得到了 RTT 的值。

防止序列號回繞問題

現(xiàn)在我們來模擬一下這個問題。

序列號的范圍其實是在0 ~ 2 ^ 32 - 1, 為了方便演示，我們縮小一下這個區(qū)間，假設范圍是 0 ~ 4，那么到達 4 的時候會回到 0。

假設在第 6 次的時候，之前還滯留在網路中的包回來了，那么就有兩個序列號為1 ~ 2的數(shù)據(jù)包了，怎么區(qū)分誰是誰呢？這個時候就產生了序列號回繞的問題。

那么用 timestamp 就能很好地解決這個問題，因為每次發(fā)包的時候都是將發(fā)包機器當時的內核時間記錄在報文中，那么兩次發(fā)包序列號即使相同，時間戳也不可能相同，這樣就能夠區(qū)分開兩個數(shù)據(jù)包了。

10、TCP 的超時重傳時間是如何計算的？

TCP 具有超時重傳機制，即間隔一段時間沒有等到數(shù)據(jù)包的回復時，重傳這個數(shù)據(jù)包。

那么這個重傳間隔是如何來計算的呢？

今天我們就來討論一下這個問題。

這個重傳間隔也叫做超時重傳時間(Retransmission TimeOut, 簡稱RTO)，它的計算跟上一節(jié)提到的 RTT 密切相關。這里我們將介紹兩種主要的方法，一個是經典方法，一個是標準方法。

經典方法

經典方法引入了一個新的概念——SRTT(Smoothed round trip time，即平滑往返時間)，沒產生一次新的 RTT. 就根據(jù)一定的算法對 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 穩(wěn)定的地方表現(xiàn)還可以，而在 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 之間的差值，給我們在后續(xù)感知到 RTT 的變化提供了抓手。

第三步: 計算最終的RTO:

RTO = μ * SRTT + ? * RTTVAR?

μ建議值取1,??建議值取4。

這個公式在 SRTT 的基礎上加上了最新 RTT 與它的偏移，從而很好的感知了 RTT 的變化，這種算法下，RTO 與 RTT 變化的差值關系更加密切。

11、能不能說一說 TCP 的流量控制？

對于發(fā)送端和接收端而言，TCP 需要把發(fā)送的數(shù)據(jù)放到發(fā)送緩存區(qū), 將接收的數(shù)據(jù)放到接收緩存區(qū)。

而流量控制所要做的事情，就是在通過接收緩存區(qū)的大小，控制發(fā)送端的發(fā)送。如果對方的接收緩存區(qū)滿了，就不能再繼續(xù)發(fā)送了。

要具體理解流量控制，首先需要了解滑動窗口的概念。

TCP 滑動窗口

TCP 滑動窗口分為兩種:?發(fā)送窗口和接收窗口。

發(fā)送窗口

發(fā)送端的滑動窗口結構如下:

其中包含四大部分:

• 已發(fā)送且已確認
• 已發(fā)送但未確認
• 未發(fā)送但可以發(fā)送
• 未發(fā)送也不可以發(fā)送

其中有一些重要的概念，我標注在圖中:

發(fā)送窗口就是圖中被框住的范圍。SND 即send, WND 即window, UNA 即unacknowledged, 表示未被確認，NXT 即next, 表示下一個發(fā)送的位置。

接收窗口

接收端的窗口結構如下:

REV 即?receive，NXT 表示下一個接收的位置，WND 表示接收窗口大小。

流量控制過程

這里我們不用太復雜的例子，以一個最簡單的來回來模擬一下流量控制的過程，方便大家理解。

首先雙方三次握手，初始化各自的窗口大小，均為 200 個字節(jié)。

假如當前發(fā)送端給接收端發(fā)送 100 個字節(jié)，那么此時對于發(fā)送端而言，SND.NXT 當然要右移 100 個字節(jié)，也就是說當前的可用窗口減少了 100 個字節(jié)，這很好理解。

現(xiàn)在這 100 個到達了接收端，被放到接收端的緩沖隊列中。不過此時由于大量負載的原因，接收端處理不了這么多字節(jié)，只能處理 40 個字節(jié)，剩下的?60?個字節(jié)被留在了緩沖隊列中。

注意了，此時接收端的情況是處理能力不夠用啦，你發(fā)送端給我少發(fā)點，所以此時接收端的接收窗口應該縮小，具體來說，縮小 60 個字節(jié)，由 200 個字節(jié)變成了 140 字節(jié)，因為緩沖隊列還有 60 個字節(jié)沒被應用拿走。

因此，接收端會在 ACK 的報文首部帶上縮小后的滑動窗口 140 字節(jié)，發(fā)送端對應地調整發(fā)送窗口的大小為 140 個字節(jié)。

此時對于發(fā)送端而言，已經發(fā)送且確認的部分增加 40 字節(jié)，也就是 SND.UNA 右移 40 個字節(jié)，同時發(fā)送窗口縮小為 140 個字節(jié)。

這也就是流量控制的過程。盡管回合再多，整個控制的過程和原理是一樣的

?12、能不能說說 TCP 的擁塞控制？

上面所說的流量控制發(fā)生在發(fā)送端跟接收端之間，并沒有考慮到整個網絡環(huán)境的影響，如果說當前網絡特別差，特別容易丟包，那么發(fā)送端就應該注意一些了。而這，也正是擁塞控制需要處理的問題。

對于擁塞控制來說，TCP 每條連接都需要維護兩個核心狀態(tài):

• 擁塞窗口（Congestion Window，cwnd）
• 慢啟動閾值（Slow Start Threshold，ssthresh）

涉及到的算法有這幾個:

• 慢啟動
• 擁塞避免
• 快速重傳和快速恢復

接下來，我們就來一一拆解這些狀態(tài)和算法。首先，從擁塞窗口說起。

擁塞窗口

擁塞窗口（Congestion Window，cwnd）是指目前自己還能傳輸?shù)臄?shù)據(jù)量大小。

那么之前介紹了接收窗口的概念，兩者有什么區(qū)別呢？

• 接收窗口(rwnd)是接收端給的限制
• 擁塞窗口(cwnd)是發(fā)送端的限制

限制誰呢？

限制的是發(fā)送窗口的大小。

有了這兩個窗口，如何來計算發(fā)送窗口？

發(fā)送窗口大小 = min(rwnd, cwnd)

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

慢啟動

剛開始進入傳輸數(shù)據(jù)的時候，你是不知道現(xiàn)在的網路到底是穩(wěn)定還是擁堵的，如果做的太激進，發(fā)包太急，那么瘋狂丟包，造成雪崩式的網絡災難。

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

• 首先，三次握手，雙方宣告自己的接收窗口大小
• 雙方初始化自己的擁塞窗口(cwnd)大小
• 在開始傳輸?shù)囊欢螘r間，發(fā)送端每收到一個 ACK，擁塞窗口大小加 1，也就是說，每經過一個 RTT，cwnd 翻倍。如果說初始窗口為 10，那么第一輪 10 個報文傳完且發(fā)送端收到 ACK 后，cwnd 變?yōu)?20，第二輪變?yōu)?40，第三輪變?yōu)?80，依次類推。

難道就這么無止境地翻倍下去？當然不可能。它的閾值叫做慢啟動閾值，當 cwnd 到達這個閾值之后，好比踩了下剎車，別漲了那么快了，老鐵，先 hold ??！

在到達閾值后，如何來控制 cwnd 的大小呢？

這就是擁塞避免做的事情了。

擁塞避免

原來每收到一個 ACK，cwnd 加1，現(xiàn)在到達閾值了，cwnd 只能加這么一點:?1 / cwnd。那你仔細算算，一輪 RTT 下來，收到 cwnd 個 ACK, 那最后擁塞窗口的大小 cwnd 總共才增加 1。

也就是說，以前一個 RTT 下來，cwnd翻倍，現(xiàn)在cwnd只是增加 1 而已。

當然，慢啟動和擁塞避免是一起作用的，是一體的。

快速重傳和快速恢復

快速重傳

在 TCP 傳輸?shù)倪^程中，如果發(fā)生了丟包，即接收端發(fā)現(xiàn)數(shù)據(jù)段不是按序到達的時候，接收端的處理是重復發(fā)送之前的 ACK。

比如第 5 個包丟了，即使第 6、7 個包到達的接收端，接收端也一律返回第 4 個包的 ACK。當發(fā)送端收到 3 個重復的 ACK 時，意識到丟包了，于是馬上進行重傳，不用等到一個 RTO 的時間到了才重傳。

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

選擇性重傳

那你可能會問了，既然要重傳，那么只重傳第 5 個包還是第5、6、7 個包都重傳呢？

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

在收到發(fā)送端的報文后，接收端回復一個 ACK 報文，那么在這個報文首部的可選項中，就可以加上SACK這個屬性，通過left edge和right edge告知發(fā)送端已經收到了哪些區(qū)間的數(shù)據(jù)報。因此，即使第 5 個包丟包了，當收到第 6、7 個包之后，接收端依然會告訴發(fā)送端，這兩個包到了。剩下第 5 個包沒到，就重傳這個包。這個過程也叫做選擇性重傳(SACK，Selective Acknowledgment)，它解決的是如何重傳的問題。

快速恢復

當然，發(fā)送端收到三次重復 ACK 之后，發(fā)現(xiàn)丟包，覺得現(xiàn)在的網絡已經有些擁塞了，自己會進入快速恢復階段。

在這個階段，發(fā)送端如下改變：

• 擁塞閾值降低為 cwnd 的一半
• cwnd 的大小變?yōu)閾砣撝?/li>
• cwnd 線性增加

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

13、 能不能說說 Nagle 算法和延遲確認？

Nagle 算法

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

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

具體來說，Nagle 算法的規(guī)則如下:

• 當?shù)谝淮伟l(fā)送數(shù)據(jù)時不用等待，就算是 1byte 的小包也立即發(fā)送
• 后面發(fā)送滿足下面條件之一就可以發(fā)了:

• • 數(shù)據(jù)包大小達到最大段大小(Max Segment Size, 即 MSS)
  • 之前所有包的 ACK 都已接收到

延遲確認

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

延遲確認(delayed ack)所做的事情，就是后者，稍稍延遲，然后合并 ACK，最后才回復給發(fā)送端。TCP 要求這個延遲的時延必須小于500ms，一般操作系統(tǒng)實現(xiàn)都不會超過200ms。

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

• 接收到了大于一個 frame 的報文，且需要調整窗口大小
• TCP 處于 quickack 模式（通過tcp_in_quickack_mode設置）
• 發(fā)現(xiàn)了亂序包

兩者一起使用會怎樣？

前者意味著延遲發(fā)，后者意味著延遲接收，會造成更大的延遲，產生性能問題。

14、如何理解 TCP 的 keep-alive？

大家都聽說過 http 的keep-alive, 不過 TCP 層面也是有keep-alive機制，而且跟應用層不太一樣。

試想一個場景，當有一方因為網絡故障或者宕機導致連接失效，由于 TCP 并不是一個輪詢的協(xié)議，在下一個數(shù)據(jù)包到達之前，對端對連接失效的情況是一無所知的。

這個時候就出現(xiàn)了 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?

不過，現(xiàn)狀是大部分的應用并沒有默認開啟 TCP 的keep-alive選項，為什么？

站在應用的角度:

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

因此是一個比較尷尬的設計。文章來源地址http://www.zghlxwxcb.cn/news/detail-806814.html

到了這里，關于【網絡基礎】TCP協(xié)議之三次握手&四次揮手--詳解與常見問題解答的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！