你咋又被 TCP/IP 虐了冕末？

先亮出這篇文章的思維導(dǎo)圖

TCP 作為傳輸層的協(xié)議萍歉，是一個軟件工程師素養(yǎng)的體現(xiàn)，也是面試中經(jīng)常被問到的知識點档桃。在此枪孩，我將 TCP 核心的一些問題梳理了一下，希望能幫到各位藻肄。

001. 能不能說一說 TCP 和 UDP 的區(qū)別蔑舞？

首先概括一下基本的區(qū)別:

TCP是一個面向連接的、可靠的嘹屯、基于字節(jié)流的傳輸層協(xié)議攻询。

而UDP是一個面向無連接的傳輸層協(xié)議。(就這么簡單州弟，其它TCP的特性也就沒有了)钧栖。

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

面向連接拯杠。所謂的連接掏婶，指的是客戶端和服務(wù)器的連接，在雙方互相通信之前潭陪，TCP 需要三次握手建立連接雄妥，而 UDP 沒有相應(yīng)建立連接的過程。

可靠性畔咧。TCP 花了非常多的功夫保證連接的可靠茎芭，這個可靠性體現(xiàn)在哪些方面呢？一個是有狀態(tài)誓沸，另一個是可控制。

TCP 會精準記錄哪些數(shù)據(jù)發(fā)送了壹粟，哪些數(shù)據(jù)被對方接收了拜隧，哪些沒有被接收到，而且保證數(shù)據(jù)包按序到達趁仙，不允許半點差錯洪添。這是有狀態(tài)。

當(dāng)意識到丟包了或者網(wǎng)絡(luò)環(huán)境不佳雀费，TCP 會根據(jù)具體情況調(diào)整自己的行為干奢，控制自己的發(fā)送速度或者重發(fā)。這是可控制盏袄。

相應(yīng)的忿峻，UDP 就是無狀態(tài),不可控的。

面向字節(jié)流辕羽。UDP 的數(shù)據(jù)傳輸是基于數(shù)據(jù)報的逛尚，這是因為僅僅只是繼承了 IP 層的特性，而 TCP 為了維護狀態(tài)刁愿，將一個個 IP 包變成了字節(jié)流绰寞。

002: 說說 TCP 三次握手的過程？為什么是三次而不是兩次铣口、四次滤钱？

戀愛模擬

以談戀愛為例，兩個人能夠在一起最重要的事情是首先確認各自愛和被愛的能力脑题。接下來我們以此來模擬三次握手的過程件缸。

第一次:

男:我愛你。

女方收到旭蠕。

由此證明男方擁有愛的能力停团。

第二次:

女:我收到了你的愛旷坦，我也愛你。

男方收到佑稠。

OK秒梅，現(xiàn)在的情況說明，女方擁有愛和被愛的能力舌胶。

第三次:

男:我收到了你的愛捆蜀。

女方收到。

現(xiàn)在能夠保證男方具備被愛的能力幔嫂。

由此完整地確認了雙方愛和被愛的能力辆它，兩人開始一段甜蜜的愛情。

真實握手

當(dāng)然剛剛那段屬于扯淡履恩，不代表本人價值觀锰茉，目的是讓大家理解整個握手過程的意義，因為兩個過程非常相似切心。對應(yīng)到 TCP 的三次握手飒筑，也是需要確認雙方的兩樣能力:發(fā)送的能力和接收的能力。于是便會有下面的三次握手的過程:

從最開始雙方都處于CLOSED狀態(tài)绽昏。然后服務(wù)端開始監(jiān)聽某個端口协屡，進入了LISTEN狀態(tài)。

然后客戶端主動發(fā)起連接全谤，發(fā)送 SYN , 自己變成了SYN-SENT狀態(tài)肤晓。

服務(wù)端接收到，返回SYN和ACK(對應(yīng)客戶端發(fā)來的SYN)认然，自己變成了SYN-REVD补憾。

之后客戶端再發(fā)送ACK給服務(wù)端，自己變成了ESTABLISHED狀態(tài)季眷；服務(wù)端收到ACK之后余蟹，也變成了ESTABLISHED狀態(tài)。

另外需要提醒你注意的是子刮，從圖中可以看出威酒，SYN 是需要消耗一個序列號的，下次發(fā)送對應(yīng)的 ACK 序列號要加1挺峡，為什么呢葵孤？只需要記住一個規(guī)則:

凡是需要對端確認的，一定消耗TCP報文的序列號橱赠。

SYN 需要對端的確認尤仍， 而 ACK 并不需要，因此 SYN 消耗一個序列號而 ACK 不需要狭姨。

為什么不是兩次宰啦？

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

分析如下:

如果是兩次，你現(xiàn)在發(fā)了 SYN 報文想握手赡模，但是這個包滯留在了當(dāng)前的網(wǎng)絡(luò)中遲遲沒有到達田炭，TCP 以為這是丟了包，于是重傳漓柑，兩次握手建立好了連接教硫。

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

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

為什么不是四次？

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

當(dāng)然可以穆刻，100 次都可以置尔。但為了解決問題，三次就足夠了氢伟，再多用處就不大了榜轿。

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

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

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

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

同時打開會怎樣购岗？

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

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

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

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

發(fā)完SYN注服，兩者的狀態(tài)都變?yōu)镾YN-SENT。

在各自收到對方的SYN后措近，兩者狀態(tài)都變?yōu)镾YN-REVD溶弟。

接著會回復(fù)對應(yīng)的ACK + SYN，這個報文在對方接收之后瞭郑，兩者狀態(tài)一起變?yōu)镋STABLISHED辜御。

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

003: 說說 TCP 四次揮手的過程

過程拆解

剛開始雙方處于ESTABLISHED狀態(tài)屈张。

客戶端要斷開了擒权，向服務(wù)器發(fā)送FIN報文，在 TCP 報文中的位置如下圖:

發(fā)送后客戶端變成了FIN-WAIT-1狀態(tài)阁谆。注意, 這時候客戶端同時也變成了half-close(半關(guān)閉)狀態(tài)碳抄，即無法向服務(wù)端發(fā)送報文，只能接收场绿。

服務(wù)端接收后向客戶端確認剖效，變成了CLOSED-WAIT狀態(tài)。

客戶端接收到了服務(wù)端的確認焰盗，變成了FIN-WAIT2狀態(tài)璧尸。

隨后，服務(wù)端向客戶端發(fā)送FIN熬拒，自己進入LAST-ACK狀態(tài)爷光，

客戶端收到服務(wù)端發(fā)來的FIN后，自己變成了TIME-WAIT狀態(tài)澎粟，然后發(fā)送 ACK 給服務(wù)端蛀序。

注意了，這個時候捌议，客戶端需要等待足夠長的時間哼拔，具體來說，是 2 個MSL(Maximum Segment Lifetime瓣颅，報文最大生存時間), 在這段時間內(nèi)如果客戶端沒有收到服務(wù)端的重發(fā)請求倦逐，那么表示 ACK 成功到達，揮手結(jié)束，否則客戶端重發(fā) ACK檬姥。

等待2MSL的意義

如果不等待會怎樣曾我？

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

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

1 個 MSL 確保四次揮手中主動關(guān)閉方最后的 ACK 報文最終能達到對端

1 個 MSL 確保對端沒有收到 ACK 重傳的 FIN 報文可以到達

這就是等待 2MSL 的意義狰贯。

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

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

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

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

同時關(guān)閉會怎樣尿贫？

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

004: 說說半連接隊列和 SYN Flood 攻擊的關(guān)系

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

半連接隊列

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

全連接隊列

當(dāng)客戶端返回ACK, 服務(wù)端接收后衰齐，三次握手完成任斋。這個時候連接等待被具體的應(yīng)用取走，在被取走之前耻涛，它會被推入另外一個 TCP 維護的隊列废酷，也就是全連接隊列(Accept Queue)瘟檩。

SYN Flood 攻擊原理

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

處理大量的SYN包并返回對應(yīng)ACK, 勢必有大量連接處于SYN_RCVD狀態(tài)睹簇，從而占滿整個半連接隊列，無法處理正常的請求寥闪。

由于是不存在的 IP太惠，服務(wù)端長時間收不到客戶端的ACK，會導(dǎo)致服務(wù)端不斷重發(fā)數(shù)據(jù)橙垢，直到耗盡服務(wù)端的資源垛叨。

如何應(yīng)對 SYN Flood 攻擊？

增加 SYN 連接柜某，也就是增加半連接隊列的容量嗽元。

減少 SYN + ACK 重試次數(shù)，避免大量的超時重發(fā)喂击。

利用 SYN Cookie 技術(shù)剂癌，在服務(wù)端接收到SYN后不立即分配連接資源，而是根據(jù)這個SYN計算出一個Cookie翰绊，連同第二次握手回復(fù)給客戶端佩谷，在客戶端回復(fù)ACK的時候帶上這個Cookie值胚想，服務(wù)端驗證 Cookie 合法之后才分配連接資源圆米。

005: 介紹一下 TCP 報文頭部的字段

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

請大家牢記這張圖！

源端口等脂、目標端口

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

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

序列號

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

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

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

在 SYN 報文中交換彼此的初始序列號莉撇。

保證數(shù)據(jù)包按正確的順序組裝呢蛤。

ISN

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

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

如果 ISN 被攻擊者預(yù)測到辜荠，要知道源 IP 和源端口號都是很容易偽造的汽抚，當(dāng)攻擊者猜測 ISN 之后，直接偽造一個 RST 后伯病，就可以強制連接關(guān)閉的造烁，這是非常危險的。

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

確認號

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

標記位

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

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

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

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

窗口大小

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

校驗和

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

可選項

可選項的格式如下:

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

TimeStamp: TCP 時間戳策精，后面詳細介紹舰始。

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

SACK: 選擇確認選項咽袜。

Window Scale：窗口縮放選項丸卷。

006: 說說 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給服務(wù)端澳淑，服務(wù)端接收到比原。

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

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

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

后面的三次握手

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

重點來了展箱，現(xiàn)在服務(wù)端能向客戶端發(fā) HTTP 響應(yīng)了旨枯！這是最顯著的改變，三次握手還沒建立混驰，僅僅驗證了 Cookie 的合法性攀隔，就可以返回 HTTP 響應(yīng)了皂贩。

當(dāng)然，客戶端的ACK還得正常傳過來昆汹，不然怎么叫三次握手嘛明刷。

流程如下:

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

TFO 的優(yōu)勢

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

007: 能不能說說TCP報文中時間戳的作用？

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

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

其中 kind = 8， length = 10贤旷， info 有兩部分構(gòu)成:timestamp和timestamp echo广料，各占 4 個字節(jié)。

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

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

計算往返時延 RTT(Round-Trip Time)

防止序列號的回繞問題

計算往返時延 RTT

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

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

如果以第二次發(fā)包為開始時間的話，就會導(dǎo)致右圖的問題假残，RTT 明顯偏小缭贡，開始時間應(yīng)該采用第一次發(fā)包的。

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

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

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

step 1:a 向 b 發(fā)送的時候穆端，timestamp中存放的內(nèi)容就是 a 主機發(fā)送時的內(nèi)核時刻ta1。

step 2:b 向 a 回復(fù) s2 報文的時候仿便，timestamp中存放的是 b 主機的時刻tb,timestamp echo字段為從 s1 報文中解析出來的 ta1体啰。

step 3:a 收到 b 的 s2 報文之后，此時 a 主機的內(nèi)核時刻是 ta2, 而在 s2 報文中的 timestamp echo 選項中可以得到ta1, 也就是 s2 對應(yīng)的報文最初的發(fā)送時刻嗽仪。然后直接采用 ta2 - ta1 就得到了 RTT 的值荒勇。

防止序列號回繞問題

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

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

第幾次發(fā)包發(fā)送字節(jié)對應(yīng)序列號狀態(tài)

10 ~ 10 ~ 1成功接收

21 ~ 21 ~ 2滯留在網(wǎng)絡(luò)中

32 ~ 32 ~ 3成功接收

43 ~ 43 ~ 4成功接收

54 ~ 50 ~ 1成功接收仅偎，序列號從0開始

65 ~ 61 ~ 2？雳殊？橘沥？

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

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

008: TCP 的超時重傳時間是如何計算的箕戳？

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

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

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

這個重傳間隔也叫做超時重傳時間(Retransmission TimeOut, 簡稱RTO)走越，它的計算跟上一節(jié)提到的 RTT 密切相關(guān)椭豫。這里我們將介紹兩種主要的方法，一個是經(jīng)典方法旨指，一個是標準方法赏酥。

經(jīng)典方法

經(jīng)典方法引入了一個新的概念——SRTT(Smoothed round trip time，即平滑往返時間)谆构，沒產(chǎn)生一次新的 RTT. 就根據(jù)一定的算法對 SRTT 進行更新裸扶，具體而言，計算方式如下(SRTT 初始值為0):

SRTT =? (α * SRTT) + ((1 - α) * RTT)

其中搬素，α 是平滑因子呵晨，建議值是0.8魏保，范圍是0.8 ~ 0.9。

拿到 SRTT摸屠，我們就可以計算 RTO 的值了:

RTO = min(ubound, max(lbound, β * SRTT))

β 是加權(quán)因子谓罗，一般為1.3 ~ 2.0，lbound是下界季二，ubound是上界檩咱。

其實這個算法過程還是很簡單的，但是也存在一定的局限胯舷，就是在 RTT 穩(wěn)定的地方表現(xiàn)還可以刻蚯，而在 RTT 變化較大的地方就不行了，因為平滑因子 α 的范圍是0.8 ~ 0.9, RTT 對于 RTO 的影響太小桑嘶。

標準方法

為了解決經(jīng)典方法對于 RTT 變化不敏感的問題炊汹，后面又引出了標準方法，也叫Jacobson / Karels 算法不翩。

一共有三步兵扬。

第一步: 計算SRTT，公式如下:

SRTT = (1 - α) * SRTT + α * RTT

注意這個時候的α跟經(jīng)典方法中的α取值不一樣了口蝠，建議值是1/8器钟，也就是0.125。

第二步: 計算RTTVAR(round-trip time variation)這個中間變量妙蔗。

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|)

β 建議值為 0.25傲霸。這個值是這個算法中出彩的地方，也就是說眉反，它記錄了最新的 RTT 與當(dāng)前 SRTT 之間的差值昙啄，給我們在后續(xù)感知到 RTT 的變化提供了抓手。

第三步: 計算最終的RTO:

RTO = μ * SRTT + ? * RTTVAR

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

這個公式在 SRTT 的基礎(chǔ)上加上了最新 RTT 與它的偏移梳凛，從而很好的感知了 RTT 的變化，這種算法下梳杏，RTO 與 RTT 變化的差值關(guān)系更加密切韧拒。

009: 能不能說一說 TCP 的流量控制？

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

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

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

TCP 滑動窗口

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

發(fā)送窗口

發(fā)送端的滑動窗口結(jié)構(gòu)如下:

其中包含四大部分:

已發(fā)送且已確認

已發(fā)送但未確認

未發(fā)送但可以發(fā)送

未發(fā)送也不可以發(fā)送

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

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

接收窗口

接收端的窗口結(jié)構(gòu)如下:

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

流量控制過程

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

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

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

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

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

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

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

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

010: 能不能說說 TCP 的擁塞控制墩衙？

上一節(jié)所說的流量控制發(fā)生在發(fā)送端跟接收端之間务嫡，并沒有考慮到整個網(wǎng)絡(luò)環(huán)境的影響，如果說當(dāng)前網(wǎng)絡(luò)特別差漆改，特別容易丟包心铃，那么發(fā)送端就應(yīng)該注意一些了。而這挫剑，也正是擁塞控制需要處理的問題去扣。

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

擁塞窗口（Congestion Window樊破，cwnd）

慢啟動閾值（Slow Start Threshold愉棱，ssthresh）

涉及到的算法有這幾個:

慢啟動

擁塞避免

快速重傳和快速恢復(fù)

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

擁塞窗口

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

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

接收窗口(rwnd)是接收端給的限制

擁塞窗口(cwnd)是發(fā)送端的限制

限制誰呢令宿？

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

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

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

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

慢啟動

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

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

首先粱栖，三次握手，雙方宣告自己的接收窗口大小

雙方初始化自己的擁塞窗口(cwnd)大小

在開始傳輸?shù)囊欢螘r間脏毯，發(fā)送端每收到一個 ACK闹究，擁塞窗口大小加 1，也就是說食店，每經(jīng)過一個 RTT渣淤，cwnd 翻倍。如果說初始窗口為 10吉嫩，那么第一輪 10 個報文傳完且發(fā)送端收到 ACK 后砂代，cwnd 變?yōu)?20，第二輪變?yōu)?40率挣，第三輪變?yōu)?80，依次類推露戒。

難道就這么無止境地翻倍下去椒功？當(dāng)然不可能。它的閾值叫做慢啟動閾值智什，當(dāng) cwnd 到達這個閾值之后动漾，好比踩了下剎車，別漲了那么快了荠锭，老鐵旱眯，先 hold 住证九！

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

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

擁塞避免

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

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

當(dāng)然雹洗，慢啟動和擁塞避免是一起作用的香罐，是一體的。

快速重傳和快速恢復(fù)

快速重傳

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

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

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

選擇性重傳

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

當(dāng)然第 6匪燕、7 個都已經(jīng)到達了，TCP 的設(shè)計者也不傻喧笔，已經(jīng)傳過去干嘛還要傳帽驯？干脆記錄一下哪些包到了，哪些沒到书闸，針對性地重傳界拦。

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

快速恢復(fù)

當(dāng)然，發(fā)送端收到三次重復(fù) ACK 之后谈秫，發(fā)現(xiàn)丟包扒寄，覺得現(xiàn)在的網(wǎng)絡(luò)已經(jīng)有些擁塞了，自己會進入快速恢復(fù)階段拟烫。

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

擁塞閾值降低為 cwnd 的一半

cwnd 的大小變?yōu)閾砣撝?/p>

cwnd 線性增加

以上就是 TCP 擁塞控制的經(jīng)典算法:慢啟動、擁塞避免硕淑、快速重傳和快速恢復(fù)课竣。

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

Nagle 算法

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

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

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

當(dāng)?shù)谝淮伟l(fā)送數(shù)據(jù)時不用等待谒拴，就算是 1byte 的小包也立即發(fā)送

后面發(fā)送滿足下面條件之一就可以發(fā)了:

數(shù)據(jù)包大小達到最大段大小(Max Segment Size, 即 MSS)

之前所有包的 ACK 都已接收到

延遲確認

試想這樣一個場景尝江，當(dāng)我收到了發(fā)送端的一個包，然后在極短的時間內(nèi)又接收到了第二個包英上，那我是一個個地回復(fù)炭序，還是稍微等一下，把兩個包的 ACK 合并后一起回復(fù)呢苍日？

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

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

接收到了大于一個 frame 的報文扫俺，且需要調(diào)整窗口大小

TCP 處于 quickack 模式（通過tcp_in_quickack_mode設(shè)置）

發(fā)現(xiàn)了亂序包

兩者一起使用會怎樣苍苞？

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

012. 如何理解 TCP 的 keep-alive畸颅？

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

試想一個場景没炒，當(dāng)有一方因為網(wǎng)絡(luò)故障或者宕機導(dǎo)致連接失效涛癌，由于 TCP 并不是一個輪詢的協(xié)議，在下一個數(shù)據(jù)包到達之前送火，對端對連接失效的情況是一無所知的拳话。

這個時候就出現(xiàn)了 keep-alive, 它的作用就是探測對端的連接有沒有失效。

在 Linux 下种吸，可以這樣查看相關(guān)的配置:

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

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

站在應(yīng)用的角度:

7200s 也就是兩個小時檢測一次镜盯，時間太長

時間再短一些，也難以體現(xiàn)其設(shè)計的初衷, 即檢測長時間的死連接

因此是一個比較尷尬的設(shè)計猖败。

出處：juejin.im/post/5e527c58e51d4526c654bf41