轉(zhuǎn)自公眾號(hào)

https://mp.weixin.qq.com/s/xppRFyAX8ncFOP_D4R3wNA

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

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

TCP是一個(gè)面向連接的、可靠的沾谜、基于字節(jié)流的傳輸層協(xié)議膊毁。

而UDP是一個(gè)面向無連接的傳輸層協(xié)議。(就這么簡(jiǎn)單基跑，其它TCP的特性也就沒有了)婚温。

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

面向連接栅螟。所謂的連接荆秦，指的是客戶端和服務(wù)器的連接，在雙方互相通信之前力图，TCP 需要三次握手建立連接步绸，而 UDP 沒有相應(yīng)建立連接的過程。

可靠性搪哪。TCP 花了非常多的功夫保證連接的可靠候醒，這個(gè)可靠性體現(xiàn)在哪些方面呢操骡？一個(gè)是有狀態(tài)展蒂，另一個(gè)是可控制呢簸。

TCP 會(huì)精準(zhǔn)記錄哪些數(shù)據(jù)發(fā)送了，哪些數(shù)據(jù)被對(duì)方接收了漓概，哪些沒有被接收到漾月，而且保證數(shù)據(jù)包按序到達(dá)，不允許半點(diǎn)差錯(cuò)胃珍。這是有狀態(tài)梁肿。

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

相應(yīng)的填抬，UDP 就是無狀態(tài), 不可控的烛芬。

面向字節(jié)流。UDP 的數(shù)據(jù)傳輸是基于數(shù)據(jù)報(bào)的飒责，這是因?yàn)閮H僅只是繼承了 IP 層的特性赘娄，而 TCP 為了維護(hù)狀態(tài)，將一個(gè)個(gè) IP 包變成了字節(jié)流宏蛉。

002: 說說 TCP 三次握手的過程遣臼？為什么是三次而不是兩次、四次拾并？

真實(shí)握手

TCP 的三次握手揍堰，是需要確認(rèn)雙方的兩樣能力: 發(fā)送的能力和接收的能力。于是便會(huì)有下面的三次握手的過程:

從最開始雙方都處于CLOSED狀態(tài)嗅义。然后服務(wù)端開始監(jiān)聽某個(gè)端口个榕，進(jìn)入了LISTEN狀態(tài)。

然后客戶端主動(dòng)發(fā)起連接芥喇，發(fā)送 SYN , 自己變成了SYN-SENT狀態(tài)。

服務(wù)端接收到凰萨，返回SYN和ACK(對(duì)應(yīng)客戶端發(fā)來的SYN)继控，自己變成了SYN-REVD械馆。

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

另外需要提醒你注意的是冶忱，從圖中可以看出尾菇，SYN 是需要消耗一個(gè)序列號(hào)的，下次發(fā)送對(duì)應(yīng)的 ACK 序列號(hào)要加1囚枪，為什么呢派诬？只需要記住一個(gè)規(guī)則:

凡是需要對(duì)端確認(rèn)的，一定消耗TCP報(bào)文的序列號(hào)链沼。

SYN 需要對(duì)端的確認(rèn)默赂， 而 ACK 并不需要，因此 SYN 消耗一個(gè)序列號(hào)而 ACK 不需要括勺。

為什么不是兩次缆八？

根本原因: 無法確認(rèn)客戶端的接收能力。

分析如下:

如果是兩次疾捍，你現(xiàn)在發(fā)了 SYN 報(bào)文想握手奈辰，但是這個(gè)包滯留在了當(dāng)前的網(wǎng)絡(luò)中遲遲沒有到達(dá)，TCP 以為這是丟了包乱豆，于是重傳奖恰，兩次握手建立好了連接。

看似沒有問題咙鞍，但是連接關(guān)閉后房官，如果這個(gè)滯留在網(wǎng)路中的包到達(dá)了服務(wù)端呢？這時(shí)候由于是兩次握手续滋，服務(wù)端只要接收到然后發(fā)送相應(yīng)的數(shù)據(jù)包翰守，就默認(rèn)建立連接，但是現(xiàn)在客戶端已經(jīng)斷開了疲酌。

看到問題的吧蜡峰，這就帶來了連接資源的浪費(fèi)。

為什么不是四次朗恳？

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

當(dāng)然可以粥诫，100 次都可以油航。但為了解決問題，三次就足夠了怀浆，再多用處就不大了谊囚。

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

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

如果前兩次握手能夠攜帶數(shù)據(jù)，那么一旦有人想攻擊服務(wù)器奠伪，那么他只需要在第一次握手中的 SYN 報(bào)文中放大量數(shù)據(jù)跌帐，那么服務(wù)器勢(shì)必會(huì)消耗更多的時(shí)間和內(nèi)存空間去處理這些數(shù)據(jù)，增大了服務(wù)器被攻擊的風(fēng)險(xiǎn)绊率。

第三次握手的時(shí)候谨敛，客戶端已經(jīng)處于ESTABLISHED狀態(tài)，并且已經(jīng)能夠確認(rèn)服務(wù)器的接收即舌、發(fā)送能力正常佣盒，這個(gè)時(shí)候相對(duì)安全了，可以攜帶數(shù)據(jù)顽聂。

同時(shí)打開會(huì)怎樣肥惭？

如果雙方同時(shí)發(fā) SYN報(bào)文，狀態(tài)變化會(huì)是怎樣的呢紊搪？

這是一個(gè)可能會(huì)發(fā)生的情況蜜葱。

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

在發(fā)送方給接收方發(fā)SYN報(bào)文的同時(shí)，接收方也給發(fā)送方發(fā)SYN報(bào)文耀石，兩個(gè)人杠上了!

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

在各自收到對(duì)方的SYN后滞伟，兩者狀態(tài)都變?yōu)镾YN-REVD揭鳞。

接著會(huì)回復(fù)對(duì)應(yīng)的ACK + SYN，這個(gè)報(bào)文在對(duì)方接收之后梆奈，兩者狀態(tài)一起變?yōu)镋STABLISHED野崇。

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

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

過程拆解

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

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

發(fā)送后客戶端變成了FIN-WAIT-1狀態(tài)清酥。注意, 這時(shí)候客戶端同時(shí)也變成了half-close(半關(guān)閉)狀態(tài)扶镀，即無法向服務(wù)端發(fā)送報(bào)文，只能接收焰轻。

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

客戶端接收到了服務(wù)端的確認(rèn)，變成了FIN-WAIT2狀態(tài)蝠筑。

隨后忆肾，服務(wù)端向客戶端發(fā)送FIN，自己進(jìn)入LAST-ACK狀態(tài)菱肖，

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

注意了，這個(gè)時(shí)候和悦，客戶端需要等待足夠長(zhǎng)的時(shí)間退疫，具體來說，是 2 個(gè) MSL(Maximum Segment Lifetime鸽素，報(bào)文最大生存時(shí)間), 在這段時(shí)間內(nèi)如果客戶端沒有收到服務(wù)端的重發(fā)請(qǐng)求褒繁，那么表示 ACK 成功到達(dá)，揮手結(jié)束馍忽，否則客戶端重發(fā) ACK棒坏。

等待2MSL的意義

如果不等待會(huì)怎樣？

如果不等待遭笋，客戶端直接跑路坝冕，當(dāng)服務(wù)端還有很多數(shù)據(jù)包要給客戶端發(fā)，且還在路上的時(shí)候瓦呼，若客戶端的端口此時(shí)剛好被新的應(yīng)用占用喂窟，那么就接收到了無用數(shù)據(jù)包，造成數(shù)據(jù)包混亂央串。所以磨澡，最保險(xiǎn)的做法是等服務(wù)器發(fā)來的數(shù)據(jù)包都死翹翹再啟動(dòng)新的應(yīng)用。

那质和，照這樣說一個(gè) MSL 不就不夠了嗎稳摄，為什么要等待 2 MSL?

1 個(gè) MSL 確保四次揮手中主動(dòng)關(guān)閉方最后的 ACK 報(bào)文最終能達(dá)到對(duì)端

1 個(gè) MSL 確保對(duì)端沒有收到 ACK 重傳的 FIN 報(bào)文可以到達(dá)

這就是等待 2MSL 的意義。

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

因?yàn)榉?wù)端在接收到FIN, 往往不會(huì)立即返回FIN, 必須等到服務(wù)端所有的報(bào)文都發(fā)送完畢了秩命，才能發(fā)FIN。因此先發(fā)一個(gè)ACK表示已經(jīng)收到客戶端的FIN褒傅，延遲一段時(shí)間才發(fā)FIN弃锐。這就造成了四次揮手。

如果是三次揮手會(huì)有什么問題殿托？

等于說服務(wù)端將ACK和FIN的發(fā)送合并為一次揮手霹菊，這個(gè)時(shí)候長(zhǎng)時(shí)間的延遲可能會(huì)導(dǎo)致客戶端誤以為FIN沒有到達(dá)客戶端，從而讓客戶端不斷的重發(fā)FIN。

同時(shí)關(guān)閉會(huì)怎樣旋廷？

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

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

三次握手前饶碘，服務(wù)端的狀態(tài)從CLOSED變?yōu)長(zhǎng)ISTEN, 同時(shí)在內(nèi)部創(chuàng)建了兩個(gè)隊(duì)列：半連接隊(duì)列和全連接隊(duì)列目尖，即SYN隊(duì)列和ACCEPT隊(duì)列。

半連接隊(duì)列

當(dāng)客戶端發(fā)送SYN到服務(wù)端扎运，服務(wù)端收到以后回復(fù)ACK和SYN瑟曲，狀態(tài)由LISTEN變?yōu)镾YN_RCVD，此時(shí)這個(gè)連接就被推入了SYN隊(duì)列豪治，也就是半連接隊(duì)列洞拨。

全連接隊(duì)列

當(dāng)客戶端返回ACK, 服務(wù)端接收后，三次握手完成负拟。這個(gè)時(shí)候連接等待被具體的應(yīng)用取走烦衣，在被取走之前，它會(huì)被推入另外一個(gè) TCP 維護(hù)的隊(duì)列掩浙，也就是全連接隊(duì)列(Accept Queue)花吟。

SYN Flood 攻擊原理

SYN Flood 屬于典型的 DoS/DDoS 攻擊。其攻擊的原理很簡(jiǎn)單涣脚，就是用客戶端在短時(shí)間內(nèi)偽造大量不存在的 IP 地址示辈，并向服務(wù)端瘋狂發(fā)送SYN。對(duì)于服務(wù)端而言遣蚀，會(huì)產(chǎn)生兩個(gè)危險(xiǎn)的后果:

處理大量的SYN包并返回對(duì)應(yīng)ACK, 勢(shì)必有大量連接處于SYN_RCVD狀態(tài)矾麻，從而占滿整個(gè)半連接隊(duì)列，無法處理正常的請(qǐng)求芭梯。

由于是不存在的 IP险耀，服務(wù)端長(zhǎng)時(shí)間收不到客戶端的ACK，會(huì)導(dǎo)致服務(wù)端不斷重發(fā)數(shù)據(jù)玖喘，直到耗盡服務(wù)端的資源甩牺。

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

增加 SYN 連接累奈，也就是增加半連接隊(duì)列的容量贬派。

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

利用 SYN Cookie 技術(shù)搞乏，在服務(wù)端接收到SYN后不立即分配連接資源，而是根據(jù)這個(gè)SYN計(jì)算出一個(gè)Cookie戒努，連同第二次握手回復(fù)給客戶端请敦，在客戶端回復(fù)ACK的時(shí)候帶上這個(gè)Cookie值，服務(wù)端驗(yàn)證 Cookie 合法之后才分配連接資源。

005: 介紹一下 TCP 報(bào)文頭部的字段

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

請(qǐng)大家牢記這張圖侍筛！

源端口萤皂、目標(biāo)端口

如何標(biāo)識(shí)唯一標(biāo)識(shí)一個(gè)連接？答案是 TCP 連接的四元組——源 IP匣椰、源端口裆熙、目標(biāo) IP 和目標(biāo)端口。

那 TCP 報(bào)文怎么沒有源 IP 和目標(biāo) IP 呢禽笑？這是因?yàn)樵?IP 層就已經(jīng)處理了 IP 弛车。TCP 只需要記錄兩者的端口即可。

序列號(hào)

即Sequence number, 指的是本報(bào)文段第一個(gè)字節(jié)的序列號(hào)蒲每。

從圖中可以看出，序列號(hào)是一個(gè)長(zhǎng)為 4 個(gè)字節(jié)喻括，也就是 32 位的無符號(hào)整數(shù)邀杏，表示范圍為 0 ~ 2^32 - 1。如果到達(dá)最大值了后就循環(huán)到0唬血。

序列號(hào)在 TCP 通信的過程中有兩個(gè)作用:

在 SYN 報(bào)文中交換彼此的初始序列號(hào)望蜡。

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

ISN

即Initial Sequence Number（初始序列號(hào)）,在三次握手的過程當(dāng)中拷恨，雙方會(huì)用過SYN報(bào)文來交換彼此的 ISN脖律。

ISN 并不是一個(gè)固定的值，而是每 4 ms 加一腕侄，溢出則回到 0小泉，這個(gè)算法使得猜測(cè) ISN 變得很困難。那為什么要這么做冕杠？

如果 ISN 被攻擊者預(yù)測(cè)到微姊，要知道源 IP 和源端口號(hào)都是很容易偽造的，當(dāng)攻擊者猜測(cè) ISN 之后分预，直接偽造一個(gè) RST 后兢交，就可以強(qiáng)制連接關(guān)閉的，這是非常危險(xiǎn)的笼痹。

而動(dòng)態(tài)增長(zhǎng)的 ISN 大大提高了猜測(cè) ISN 的難度配喳。

確認(rèn)號(hào)

即ACK(Acknowledgment number)。用來告知對(duì)方下一個(gè)期望接收的序列號(hào)凳干，小于ACK的所有字節(jié)已經(jīng)全部收到晴裹。

標(biāo)記位

常見的標(biāo)記位有SYN,ACK,FIN,RST,PSH。

SYN 和 ACK 已經(jīng)在上文說過纺座，后三個(gè)解釋如下: FIN：即 Finish息拜，表示發(fā)送方準(zhǔn)備斷開連接。

RST：即 Reset，用來強(qiáng)制斷開連接少欺。

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

窗口大小

占用兩個(gè)字節(jié)赞别，也就是 16 位畏陕，但實(shí)際上是不夠用的。因此 TCP 引入了窗口縮放的選項(xiàng)仿滔，作為窗口縮放的比例因子惠毁，這個(gè)比例因子的范圍在 0 ~ 14，比例因子可以將窗口的值擴(kuò)大為原來的 2 ^ n 次方崎页。

校驗(yàn)和

占用兩個(gè)字節(jié)鞠绰，防止傳輸過程中數(shù)據(jù)包有損壞，如果遇到校驗(yàn)和有差錯(cuò)的報(bào)文飒焦，TCP 直接丟棄之蜈膨，等待重傳。

可選項(xiàng)

可選項(xiàng)的格式如下:

常用的可選項(xiàng)有以下幾個(gè):

TimeStamp: TCP 時(shí)間戳牺荠，后面詳細(xì)介紹翁巍。

MSS: 指的是 TCP 允許的從對(duì)方接收的最大報(bào)文段。

SACK: 選擇確認(rèn)選項(xiàng)休雌。

Window Scale：窗口縮放選項(xiàng)灶壶。

006: 說說 TCP 快速打開的原理(TFO)

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

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

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

TFO 流程

首輪三次握手

首先客戶端發(fā)送SYN給服務(wù)端洁奈，服務(wù)端接收到间唉。

注意哦！現(xiàn)在服務(wù)端不是立刻回復(fù) SYN + ACK利术，而是通過計(jì)算得到一個(gè)SYN Cookie, 將這個(gè)Cookie放到 TCP 報(bào)文的 Fast Open選項(xiàng)中呈野，然后才給客戶端返回。

客戶端拿到這個(gè) Cookie 的值緩存下來印叁。后面正常完成三次握手被冒。

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

后面的三次握手

在后面的三次握手中昨悼，客戶端會(huì)將之前緩存的 Cookie蝗锥、SYN 和HTTP請(qǐng)求(是的，你沒看錯(cuò))發(fā)送給服務(wù)端率触，服務(wù)端驗(yàn)證了 Cookie 的合法性终议，如果不合法直接丟棄；如果是合法的葱蝗，那么就正常返回SYN + ACK穴张。

重點(diǎn)來了，現(xiàn)在服務(wù)端能向客戶端發(fā) HTTP 響應(yīng)了两曼！這是最顯著的改變皂甘，三次握手還沒建立，僅僅驗(yàn)證了 Cookie 的合法性悼凑，就可以返回 HTTP 響應(yīng)了叮贩。

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

流程如下:

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

TFO 的優(yōu)勢(shì)

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

007: 能不能說說TCP報(bào)文中時(shí)間戳的作用盐数？

timestamp是 TCP 報(bào)文首部的一個(gè)可選項(xiàng)棒拂，一共占 10 個(gè)字節(jié)，格式如下:

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

其中 kind = 8玫氢， length = 10帚屉， info 有兩部分構(gòu)成: timestamp和timestamp echo，各占 4 個(gè)字節(jié)漾峡。

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

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

計(jì)算往返時(shí)延 RTT(Round-Trip Time)

防止序列號(hào)的回繞問題

計(jì)算往返時(shí)延 RTT

在沒有時(shí)間戳的時(shí)候牢屋，計(jì)算 RTT 會(huì)遇到的問題如下圖所示:

如果以第一次發(fā)包為開始時(shí)間的話且预，就會(huì)出現(xiàn)左圖的問題，RTT 明顯偏大烙无，開始時(shí)間應(yīng)該采用第二次的锋谐；

如果以第二次發(fā)包為開始時(shí)間的話，就會(huì)導(dǎo)致右圖的問題皱炉，RTT 明顯偏小怀估，開始時(shí)間應(yīng)該采用第一次發(fā)包的。

實(shí)際上無論開始時(shí)間以第一次發(fā)包還是第二次發(fā)包為準(zhǔn)合搅，都是不準(zhǔn)確的多搀。

那這個(gè)時(shí)候引入時(shí)間戳就很好的解決了這個(gè)問題。

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

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

step 2: b 向 a 回復(fù) s2 報(bào)文的時(shí)候赌髓，timestamp 中存放的是 b 主機(jī)的時(shí)刻 tb, timestamp echo字段為從 s1 報(bào)文中解析出來的 ta1从藤。

step 3: a 收到 b 的 s2 報(bào)文之后，此時(shí) a 主機(jī)的內(nèi)核時(shí)刻是 ta2, 而在 s2 報(bào)文中的 timestamp echo 選項(xiàng)中可以得到 ta1, 也就是 s2 對(duì)應(yīng)的報(bào)文最初的發(fā)送時(shí)刻锁蠕。然后直接采用 ta2 - ta1 就得到了 RTT 的值夷野。

防止序列號(hào)回繞問題

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

序列號(hào)的范圍其實(shí)是在0 ~ 2 ^ 32 - 1, 為了方便演示荣倾，我們縮小一下這個(gè)區(qū)間悯搔，假設(shè)范圍是 0 ~ 4，那么到達(dá) 4 的時(shí)候會(huì)回到 0舌仍。

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

10 ~ 10 ~ 1成功接收

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

32 ~ 32 ~ 3成功接收

43 ~ 43 ~ 4成功接收

54 ~ 50 ~ 1成功接收妒貌，序列號(hào)從0開始

65 ~ 61 ~ 2？铸豁？灌曙？

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

那么用 timestamp 就能很好地解決這個(gè)問題增炭，因?yàn)槊看伟l(fā)包的時(shí)候都是將發(fā)包機(jī)器當(dāng)時(shí)的內(nèi)核時(shí)間記錄在報(bào)文中，那么兩次發(fā)包序列號(hào)即使相同拧晕，時(shí)間戳也不可能相同隙姿，這樣就能夠區(qū)分開兩個(gè)數(shù)據(jù)包了。

008: TCP 的超時(shí)重傳時(shí)間是如何計(jì)算的厂捞？

TCP 具有超時(shí)重傳機(jī)制输玷，即間隔一段時(shí)間沒有等到數(shù)據(jù)包的回復(fù)時(shí)队丝，重傳這個(gè)數(shù)據(jù)包。

那么這個(gè)重傳間隔是如何來計(jì)算的呢欲鹏？

今天我們就來討論一下這個(gè)問題机久。

這個(gè)重傳間隔也叫做超時(shí)重傳時(shí)間(Retransmission TimeOut, 簡(jiǎn)稱RTO)，它的計(jì)算跟上一節(jié)提到的 RTT 密切相關(guān)赔嚎。這里我們將介紹兩種主要的方法膘盖，一個(gè)是經(jīng)典方法，一個(gè)是標(biāo)準(zhǔn)方法尤误。

經(jīng)典方法

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

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

其中，α 是平滑因子尤勋，建議值是0.8喘落，范圍是0.8 ~ 0.9。

拿到 SRTT最冰，我們就可以計(jì)算 RTO 的值了:

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

β 是加權(quán)因子瘦棋，一般為1.3 ~ 2.0， lbound 是下界暖哨，ubound 是上界赌朋。

其實(shí)這個(gè)算法過程還是很簡(jiǎn)單的，但是也存在一定的局限鹿蜀，就是在 RTT 穩(wěn)定的地方表現(xiàn)還可以，而在 RTT 變化較大的地方就不行了服球，因?yàn)槠交蜃?α 的范圍是0.8 ~ 0.9, RTT 對(duì)于 RTO 的影響太小茴恰。

標(biāo)準(zhǔn)方法

為了解決經(jīng)典方法對(duì)于 RTT 變化不敏感的問題，后面又引出了標(biāo)準(zhǔn)方法斩熊，也叫Jacobson / Karels 算法往枣。

一共有三步。

第一步: 計(jì)算SRTT粉渠，公式如下:

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

注意這個(gè)時(shí)候的 α跟經(jīng)典方法中的α取值不一樣了分冈，建議值是1/8，也就是0.125霸株。

第二步: 計(jì)算RTTVAR(round-trip time variation)這個(gè)中間變量雕沉。

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

β 建議值為 0.25。這個(gè)值是這個(gè)算法中出彩的地方去件，也就是說坡椒，它記錄了最新的 RTT 與當(dāng)前 SRTT 之間的差值扰路，給我們?cè)诤罄m(xù)感知到 RTT 的變化提供了抓手。

第三步: 計(jì)算最終的RTO:

RTO = μ * SRTT + ? * RTTVAR

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

這個(gè)公式在 SRTT 的基礎(chǔ)上加上了最新 RTT 與它的偏移汗唱，從而很好的感知了 RTT 的變化，這種算法下丈攒，RTO 與 RTT 變化的差值關(guān)系更加密切哩罪。

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

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

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

要具體理解流量控制功咒，首先需要了解滑動(dòng)窗口的概念。

TCP 滑動(dòng)窗口

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

發(fā)送窗口

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

其中包含四大部分:

已發(fā)送且已確認(rèn)

已發(fā)送但未確認(rèn)

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

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

其中有一些重要的概念力奋，我標(biāo)注在圖中:

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

接收窗口

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

REV 即 receive，NXT 表示下一個(gè)接收的位置澡屡，WND 表示接收窗口大小猿挚。

流量控制過程

這里我們不用太復(fù)雜的例子，以一個(gè)最簡(jiǎn)單的來回來模擬一下流量控制的過程驶鹉，方便大家理解绩蜻。

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

假如當(dāng)前發(fā)送端給接收端發(fā)送 100 個(gè)字節(jié)，那么此時(shí)對(duì)于發(fā)送端而言姚淆，SND.NXT 當(dāng)然要右移 100 個(gè)字節(jié)孕蝉，也就是說當(dāng)前的可用窗口減少了 100 個(gè)字節(jié)，這很好理解腌逢。

現(xiàn)在這 100 個(gè)到達(dá)了接收端降淮，被放到接收端的緩沖隊(duì)列中。不過此時(shí)由于大量負(fù)載的原因搏讶，接收端處理不了這么多字節(jié)骤肛，只能處理 40 個(gè)字節(jié)纳本，剩下的 60 個(gè)字節(jié)被留在了緩沖隊(duì)列中。

注意了腋颠，此時(shí)接收端的情況是處理能力不夠用啦繁成，你發(fā)送端給我少發(fā)點(diǎn)，所以此時(shí)接收端的接收窗口應(yīng)該縮小淑玫，具體來說巾腕，縮小 60 個(gè)字節(jié)，由 200 個(gè)字節(jié)變成了 140 字節(jié)絮蒿，因?yàn)榫彌_隊(duì)列還有 60 個(gè)字節(jié)沒被應(yīng)用拿走尊搬。

因此，接收端會(huì)在 ACK 的報(bào)文首部帶上縮小后的滑動(dòng)窗口 140 字節(jié)土涝，發(fā)送端對(duì)應(yīng)地調(diào)整發(fā)送窗口的大小為 140 個(gè)字節(jié)佛寿。

此時(shí)對(duì)于發(fā)送端而言，已經(jīng)發(fā)送且確認(rèn)的部分增加 40 字節(jié)但壮，也就是 SND.UNA 右移 40 個(gè)字節(jié)冀泻，同時(shí)發(fā)送窗口縮小為 140 個(gè)字節(jié)。

這也就是流量控制的過程蜡饵。盡管回合再多弹渔，整個(gè)控制的過程和原理是一樣的。

010: 能不能說說 TCP 的擁塞控制溯祸？

上一節(jié)所說的流量控制發(fā)生在發(fā)送端跟接收端之間肢专，并沒有考慮到整個(gè)網(wǎng)絡(luò)環(huán)境的影響，如果說當(dāng)前網(wǎng)絡(luò)特別差焦辅，特別容易丟包博杖，那么發(fā)送端就應(yīng)該注意一些了。而這筷登，也正是擁塞控制需要處理的問題剃根。

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

擁塞窗口（Congestion Window仆抵，cwnd）

慢啟動(dòng)閾值（Slow Start Threshold跟继，ssthresh）

涉及到的算法有這幾個(gè):

慢啟動(dòng)

擁塞避免

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

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

擁塞窗口

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

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

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

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

限制誰呢摇庙？

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

有了這兩個(gè)窗口遥缕，如何來計(jì)算發(fā)送窗口卫袒？

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

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

慢啟動(dòng)

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

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

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

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

在開始傳輸?shù)囊欢螘r(shí)間礁竞，發(fā)送端每收到一個(gè) ACK，擁塞窗口大小加 1杉辙，也就是說模捂，每經(jīng)過一個(gè) RTT，cwnd 翻倍蜘矢。如果說初始窗口為 10狂男，那么第一輪 10 個(gè)報(bào)文傳完且發(fā)送端收到 ACK 后，cwnd 變?yōu)?20品腹，第二輪變?yōu)?40岖食，第三輪變?yōu)?80，依次類推舞吭。

難道就這么無止境地翻倍下去泡垃？當(dāng)然不可能。它的閾值叫做慢啟動(dòng)閾值羡鸥，當(dāng) cwnd 到達(dá)這個(gè)閾值之后蔑穴，好比踩了下剎車，別漲了那么快了惧浴，老鐵存和，先 hold 住！

在到達(dá)閾值后捐腿，如何來控制 cwnd 的大小呢纵朋？

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

擁塞避免

原來每收到一個(gè) ACK茄袖，cwnd 加1操软，現(xiàn)在到達(dá)閾值了，cwnd 只能加這么一點(diǎn): 1 / cwnd宪祥。那你仔細(xì)算算寺鸥，一輪 RTT 下來，收到 cwnd 個(gè) ACK, 那最后擁塞窗口的大小 cwnd 總共才增加 1。

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

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

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

快速重傳

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

比如第 5 個(gè)包丟了，即使第 6效诅、7 個(gè)包到達(dá)的接收端胀滚，接收端也一律返回第 4 個(gè)包的 ACK。當(dāng)發(fā)送端收到 3 個(gè)重復(fù)的 ACK 時(shí)乱投，意識(shí)到丟包了咽笼，于是馬上進(jìn)行重傳，不用等到一個(gè) RTO 的時(shí)間到了才重傳戚炫。

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

選擇性重傳

那你可能會(huì)問了双肤，既然要重傳施掏，那么只重傳第 5 個(gè)包還是第5、6茅糜、7 個(gè)包都重傳呢七芭？

當(dāng)然第 6、7 個(gè)都已經(jīng)到達(dá)了限匣，TCP 的設(shè)計(jì)者也不傻抖苦，已經(jīng)傳過去干嘛還要傳？干脆記錄一下哪些包到了米死，哪些沒到锌历，針對(duì)性地重傳。

在收到發(fā)送端的報(bào)文后峦筒，接收端回復(fù)一個(gè) ACK 報(bào)文究西，那么在這個(gè)報(bào)文首部的可選項(xiàng)中，就可以加上SACK這個(gè)屬性物喷，通過left edge和right edge告知發(fā)送端已經(jīng)收到了哪些區(qū)間的數(shù)據(jù)報(bào)卤材。因此，即使第 5 個(gè)包丟包了峦失，當(dāng)收到第 6扇丛、7 個(gè)包之后，接收端依然會(huì)告訴發(fā)送端尉辑，這兩個(gè)包到了帆精。剩下第 5 個(gè)包沒到，就重傳這個(gè)包隧魄。這個(gè)過程也叫做選擇性重傳(SACK卓练，Selective Acknowledgment)，它解決的是如何重傳的問題购啄。

快速恢復(fù)

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

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

擁塞閾值降低為 cwnd 的一半

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

cwnd 線性增加

以上就是 TCP 擁塞控制的經(jīng)典算法: 慢啟動(dòng)表蝙、擁塞避免、快速重傳和快速恢復(fù)乓旗。

011: 能不能說說 Nagle 算法和延遲確認(rèn)府蛇？

Nagle 算法

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

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

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

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

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

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

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

延遲確認(rèn)

試想這樣一個(gè)場(chǎng)景抒寂，當(dāng)我收到了發(fā)送端的一個(gè)包，然后在極短的時(shí)間內(nèi)又接收到了第二個(gè)包掠剑，那我是一個(gè)個(gè)地回復(fù)屈芜，還是稍微等一下，把兩個(gè)包的 ACK 合并后一起回復(fù)呢朴译？

延遲確認(rèn)(delayed ack)所做的事情井佑，就是后者，稍稍延遲眠寿，然后合并 ACK躬翁，最后才回復(fù)給發(fā)送端。TCP 要求這個(gè)延遲的時(shí)延必須小于500ms盯拱，一般操作系統(tǒng)實(shí)現(xiàn)都不會(huì)超過200ms姆另。

不過需要主要的是，有一些場(chǎng)景是不能延遲確認(rèn)的坟乾，收到了就要馬上回復(fù):

接收到了大于一個(gè) frame 的報(bào)文迹辐，且需要調(diào)整窗口大小

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

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

兩者一起使用會(huì)怎樣？

前者意味著延遲發(fā)甚侣，后者意味著延遲接收明吩，會(huì)造成更大的延遲，產(chǎn)生性能問題殷费。

012. 如何理解 TCP 的 keep-alive印荔？

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

試想一個(gè)場(chǎng)景仍律，當(dāng)有一方因?yàn)榫W(wǎng)絡(luò)故障或者宕機(jī)導(dǎo)致連接失效，由于 TCP 并不是一個(gè)輪詢的協(xié)議实柠，在下一個(gè)數(shù)據(jù)包到達(dá)之前水泉，對(duì)端對(duì)連接失效的情況是一無所知的。

這個(gè)時(shí)候就出現(xiàn)了 keep-alive, 它的作用就是探測(cè)對(duì)端的連接有沒有失效窒盐。

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

sudo sysctl -a | grep keepalive

// 每隔 7200 s 檢測(cè)一次

net.ipv4.tcp_keepalive_time = 7200

// 一次最多重傳 9 個(gè)包

net.ipv4.tcp_keepalive_probes = 9

// 每個(gè)包的間隔重傳間隔 75 s

net.ipv4.tcp_keepalive_intvl = 75

不過，現(xiàn)狀是大部分的應(yīng)用并沒有默認(rèn)開啟 TCP 的keep-alive選項(xiàng)蟹漓，為什么炕横？

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

7200s 也就是兩個(gè)小時(shí)檢測(cè)一次，時(shí)間太長(zhǎng)

時(shí)間再短一些葡粒，也難以體現(xiàn)其設(shè)計(jì)的初衷, 即檢測(cè)長(zhǎng)時(shí)間的死連接

因此是一個(gè)比較尷尬的設(shè)計(jì)份殿。