TCP協(xié)議靈魂 12 問(wèn)做弱電的你一定會(huì)用得到

TCP協(xié)議靈魂12問(wèn)，做弱電的你一定會(huì)用得到先亮出這篇文章的思維導(dǎo)圖TCP作為傳輸層的協(xié)議，是一個(gè)軟件工程師素養(yǎng)的體現(xiàn)，也是面試中經(jīng)常被問(wèn)到的知識(shí)點(diǎn)。在此，我將TCP核心的一些問(wèn)題梳理了一下，希望能幫到各位。001.能不能說(shuō)一說(shuō)TCP和UDP的區(qū)別？首先概括一下基本的區(qū)別:TCP是一個(gè)面向連接的、可靠的、基于字節(jié)流的傳輸層協(xié)議。而UDP是一個(gè)面向無(wú)連接的傳輸層協(xié)議。(就這么簡(jiǎn)單，其它TCP的特性也就沒(méi)有了)。具體來(lái)分析，和

UDP

相比，TCP

有三大核心特性:面向連接。所謂的連接，指的是客戶(hù)端和服務(wù)器的連接，在雙方互相通信之前，TCP需要三次握手建立連接，而UDP沒(méi)有相應(yīng)建立連接的過(guò)程。可靠性。TCP花了非常多的功夫保證連接的可靠，這個(gè)可靠性體現(xiàn)在哪些方面呢？一個(gè)是有狀態(tài)，另一個(gè)是可控制。TCP會(huì)精準(zhǔn)記錄哪些數(shù)據(jù)發(fā)送了，哪些數(shù)據(jù)被對(duì)方接收了，哪些沒(méi)有被接收到，而且保證數(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就是無(wú)狀態(tài),

不可控的。面向字節(jié)流。UDP的數(shù)據(jù)傳輸是基于數(shù)據(jù)報(bào)的，這是因?yàn)閮H僅只是繼承了IP層的特性，而TCP為了維護(hù)狀態(tài)，將一個(gè)個(gè)IP包變成了字節(jié)流。002:說(shuō)說(shuō)TCP三次握手的過(guò)程？為什么是三次而不是兩次、四次？戀愛(ài)模擬以談戀愛(ài)為例，兩個(gè)人能夠在一起最重要的事情是首先確認(rèn)各自愛(ài)和被愛(ài)的能力。接下來(lái)我們以此來(lái)模擬三次握手的過(guò)程。第一次:男:

我愛(ài)你。女方收到。由此證明男方擁有愛(ài)的能力。第二次:女:

我收到了你的愛(ài)，我也愛(ài)你。男方收到。OK，現(xiàn)在的情況說(shuō)明，女方擁有愛(ài)和被愛(ài)的能力。第三次:男:

我收到了你的愛(ài)。女方收到?，F(xiàn)在能夠保證男方具備被愛(ài)的能力。由此完整地確認(rèn)了雙方愛(ài)和被愛(ài)的能力，兩人開(kāi)始一段甜蜜的愛(ài)情。真實(shí)握手當(dāng)然剛剛那段屬于扯淡，不代表本人價(jià)值觀，目的是讓大家理解整個(gè)握手過(guò)程的意義，因?yàn)閮蓚€(gè)過(guò)程非常相似。對(duì)應(yīng)到TCP的三次握手，也是需要確認(rèn)雙方的兩樣能力:

發(fā)送的能力和接收的能力。于是便會(huì)有下面的三次握手的過(guò)程:從最開(kāi)始雙方都處于CLOSED狀態(tài)。然后服務(wù)端開(kāi)始監(jiān)聽(tīng)某個(gè)端口，進(jìn)入了LISTEN狀態(tài)。然后客戶(hù)端主動(dòng)發(fā)起連接，發(fā)送SYN,自己變成了SYN-SENT狀態(tài)。服務(wù)端接收到，返回SYN和ACK(對(duì)應(yīng)客戶(hù)端發(fā)來(lái)的SYN)，自己變成了SYN-REVD。之后客戶(hù)端再發(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不需要。為什么不是兩次？根本原因:無(wú)法確認(rèn)客戶(hù)端的接收能力。分析如下:如果是兩次，你現(xiàn)在發(fā)了SYN報(bào)文想握手，但是這個(gè)包滯留在了當(dāng)前的網(wǎng)絡(luò)中遲遲沒(méi)有到達(dá)，TCP以為這是丟了包，于是重傳，兩次握手建立好了連接?？此茮](méi)有問(wèn)題，但是連接關(guān)閉后，如果這個(gè)滯留在網(wǎng)路中的包到達(dá)了服務(wù)端呢？這時(shí)候由于是兩次握手，服務(wù)端只要接收到然后發(fā)送相應(yīng)的數(shù)據(jù)包，就默認(rèn)建立連接，但是現(xiàn)在客戶(hù)端已經(jīng)斷開(kāi)了?？吹絾?wèn)題的吧，這就帶來(lái)了連接資源的浪費(fèi)。為什么不是四次？三次握手的目的是確認(rèn)雙方發(fā)送和接收的能力，那四次握手可以嘛？當(dāng)然可以，100次都可以。但為了解決問(wèn)題，三次就足夠了，再多用處就不大了。三次握手過(guò)程中可以攜帶數(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í)候，客戶(hù)端已經(jīng)處于ESTABLISHED狀態(tài)，并且已經(jīng)能夠確認(rèn)服務(wù)器的接收、發(fā)送能力正常，這個(gè)時(shí)候相對(duì)安全了，可以攜帶數(shù)據(jù)。同時(shí)打開(kāi)會(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í)打開(kāi)情況下的狀態(tài)變遷。003:說(shuō)說(shuō)TCP四次揮手的過(guò)程過(guò)程拆解剛開(kāi)始雙方處于ESTABLISHED狀態(tài)?？蛻?hù)端要斷開(kāi)了，向服務(wù)器發(fā)送

FIN

報(bào)文，在TCP報(bào)文中的位置如下圖:發(fā)送后客戶(hù)端變成了FIN-WAIT-1狀態(tài)。注意,這時(shí)候客戶(hù)端同時(shí)也變成了half-close(半關(guān)閉)狀態(tài)，即無(wú)法向服務(wù)端發(fā)送報(bào)文，只能接收。服務(wù)端接收后向客戶(hù)端確認(rèn)，變成了CLOSED-WAIT狀態(tài)?？蛻?hù)端接收到了服務(wù)端的確認(rèn)，變成了FIN-WAIT2狀態(tài)。隨后，服務(wù)端向客戶(hù)端發(fā)送FIN，自己進(jìn)入LAST-ACK狀態(tài)，客戶(hù)端收到服務(wù)端發(fā)來(lái)的FIN后，自己變成了TIME-WAIT狀態(tài)，然后發(fā)送ACK給服務(wù)端。注意了，這個(gè)時(shí)候，客戶(hù)端需要等待足夠長(zhǎng)的時(shí)間，具體來(lái)說(shuō)，是2個(gè)

MSL(MaximumSegmentLifetime，報(bào)文最大生存時(shí)間),在這段時(shí)間內(nèi)如果客戶(hù)端沒(méi)有收到服務(wù)端的重發(fā)請(qǐng)求，那么表示ACK成功到達(dá)，揮手結(jié)束，否則客戶(hù)端重發(fā)ACK。等待2MSL的意義如果不等待會(huì)怎樣？如果不等待，客戶(hù)端直接跑路，當(dāng)服務(wù)端還有很多數(shù)據(jù)包要給客戶(hù)端發(fā)，且還在路上的時(shí)候，若客戶(hù)端的端口此時(shí)剛好被新的應(yīng)用占用，那么就接收到了無(wú)用數(shù)據(jù)包，造成數(shù)據(jù)包混亂。所以，最保險(xiǎn)的做法是等服務(wù)器發(fā)來(lái)的數(shù)據(jù)包都死翹翹再啟動(dòng)新的應(yīng)用。那，照這樣說(shuō)一個(gè)MSL不就不夠了嗎，為什么要等待2MSL?1個(gè)MSL確保四次揮手中主動(dòng)關(guān)閉方最后的ACK報(bào)文最終能達(dá)到對(duì)端1個(gè)MSL確保對(duì)端沒(méi)有收到ACK重傳的FIN報(bào)文可以到達(dá)這就是等待2MSL的意義。為什么是四次揮手而不是三次？因?yàn)榉?wù)端在接收到FIN,往往不會(huì)立即返回FIN,必須等到服務(wù)端所有的報(bào)文都發(fā)送完畢了，才能發(fā)FIN。因此先發(fā)一個(gè)ACK表示已經(jīng)收到客戶(hù)端的FIN，延遲一段時(shí)間才發(fā)FIN。這就造成了四次揮手。如果是三次揮手會(huì)有什么問(wèn)題？等于說(shuō)服務(wù)端將ACK和FIN的發(fā)送合并為一次揮手，這個(gè)時(shí)候長(zhǎng)時(shí)間的延遲可能會(huì)導(dǎo)致客戶(hù)端誤以為FIN沒(méi)有到達(dá)客戶(hù)端，從而讓客戶(hù)端不斷的重發(fā)FIN。同時(shí)關(guān)閉會(huì)怎樣？如果客戶(hù)端和服務(wù)端同時(shí)發(fā)送FIN，狀態(tài)會(huì)如何變化？如圖所示:004:說(shuō)說(shuō)半連接隊(duì)列和SYNFlood攻擊的關(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)客戶(hù)端發(fā)送SYN到服務(wù)端，服務(wù)端收到以后回復(fù)ACK和SYN，狀態(tài)由LISTEN變?yōu)镾YN_RCVD，此時(shí)這個(gè)連接就被推入了SYN隊(duì)列，也就是半連接隊(duì)列。全連接隊(duì)列當(dāng)客戶(hù)端返回ACK,服務(wù)端接收后，三次握手完成。這個(gè)時(shí)候連接等待被具體的應(yīng)用取走，在被取走之前，它會(huì)被推入另外一個(gè)TCP維護(hù)的隊(duì)列，也就是全連接隊(duì)列(AcceptQueue)。SYNFlood攻擊原理SYNFlood屬于典型的DoS/DDoS攻擊。其攻擊的原理很簡(jiǎn)單，就是用客戶(hù)端在短時(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)，從而占滿(mǎn)整個(gè)半連接隊(duì)列，無(wú)法處理正常的請(qǐng)求。由于是不存在的IP，服務(wù)端長(zhǎng)時(shí)間收不到客戶(hù)端的ACK，會(huì)導(dǎo)致服務(wù)端不斷重發(fā)數(shù)據(jù)，直到耗盡服務(wù)端的資源。如何應(yīng)對(duì)SYNFlood攻擊？增加SYN連接，也就是增加半連接隊(duì)列的容量。減少SYN+ACK重試次數(shù)，避免大量的超時(shí)重發(fā)。利用SYNCookie技術(shù)，在服務(wù)端接收到SYN后不立即分配連接資源，而是根據(jù)這個(gè)SYN計(jì)算出一個(gè)Cookie，連同第二次握手回復(fù)給客戶(hù)端，在客戶(hù)端回復(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)文怎么沒(méi)有源IP和目標(biāo)IP呢？這是因?yàn)樵贗P層就已經(jīng)處理了IP。TCP只需要記錄兩者的端口即可。序列號(hào)即Sequencenumber,指的是本報(bào)文段第一個(gè)字節(jié)的序列號(hào)。從圖中可以看出，序列號(hào)是一個(gè)長(zhǎng)為4個(gè)字節(jié)，也就是32位的無(wú)符號(hào)整數(shù)，表示范圍為0~2^32-1。如果到達(dá)最大值了后就循環(huán)到0。序列號(hào)在TCP通信的過(guò)程中有兩個(gè)作用:在SYN報(bào)文中交換彼此的初始序列號(hào)。保證數(shù)據(jù)包按正確的順序組裝。ISN即InitialSequenceNumber（初始序列號(hào)）,在三次握手的過(guò)程當(dāng)中，雙方會(huì)用過(guò)SYN報(bào)文來(lái)交換彼此的

ISN。ISN并不是一個(gè)固定的值，而是每4ms加一，溢出則回到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(Acknowledgmentnumber)。用來(lái)告知對(duì)方下一個(gè)期望接收的序列號(hào)，小于ACK的所有字節(jié)已經(jīng)全部收到。標(biāo)記位常見(jiàn)的標(biāo)記位有SYN,ACK,FIN,RST,PSH。SYN和ACK已經(jīng)在上文說(shuō)過(guò)，后三個(gè)解釋如下:

FIN：即Finish，表示發(fā)送方準(zhǔn)備斷開(kāi)連接。RST：即Reset，用來(lái)強(qiáng)制斷開(kāi)連接。PSH：即Push,告知對(duì)方這些數(shù)據(jù)包收到后應(yīng)該馬上交給上層的應(yīng)用，不能緩存。窗口大小占用兩個(gè)字節(jié)，也就是16位，但實(shí)際上是不夠用的。因此TCP引入了窗口縮放的選項(xiàng)，作為窗口縮放的比例因子，這個(gè)比例因子的范圍在0~14，比例因子可以將窗口的值擴(kuò)大為原來(lái)的2^n次方。校驗(yàn)和占用兩個(gè)字節(jié)，防止傳輸過(guò)程中數(shù)據(jù)包有損壞，如果遇到校驗(yàn)和有差錯(cuò)的報(bào)文，TCP直接丟棄之，等待重傳?？蛇x項(xiàng)可選項(xiàng)的格式如下:常用的可選項(xiàng)有以下幾個(gè):TimeStamp:TCP時(shí)間戳，后面詳細(xì)介紹。MSS:指的是TCP允許的從對(duì)方接收的最大報(bào)文段。SACK:選擇確認(rèn)選項(xiàng)。WindowScale：窗口縮放選項(xiàng)。006:說(shuō)說(shuō)TCP快速打開(kāi)的原理(TFO)第一節(jié)講了TCP三次握手，可能有人會(huì)說(shuō)，每次都三次握手好麻煩呀！能不能優(yōu)化一點(diǎn)？可以啊。今天來(lái)說(shuō)說(shuō)這個(gè)優(yōu)化后的TCP握手流程，也就是TCP快速打開(kāi)(TCPFastOpen,即TFO)的原理。優(yōu)化的過(guò)程是這樣的，還記得我們說(shuō)SYNFlood攻擊時(shí)提到的SYNCookie嗎？這個(gè)Cookie可不是瀏覽器的Cookie,用它同樣可以實(shí)現(xiàn)TFO。TFO流程首輪三次握手首先客戶(hù)端發(fā)送SYN給服務(wù)端，服務(wù)端接收到。注意哦！現(xiàn)在服務(wù)端不是立刻回復(fù)SYN+ACK，而是通過(guò)計(jì)算得到一個(gè)SYNCookie,將這個(gè)Cookie放到TCP報(bào)文的

FastOpen選項(xiàng)中，然后才給客戶(hù)端返回?？蛻?hù)端拿到這個(gè)Cookie的值緩存下來(lái)。后面正常完成三次握手。首輪三次握手就是這樣的流程。而后面的三次握手就不一樣啦！后面的三次握手在后面的三次握手中，客戶(hù)端會(huì)將之前緩存的

Cookie、SYN

和HTTP請(qǐng)求(是的，你沒(méi)看錯(cuò))發(fā)送給服務(wù)端，服務(wù)端驗(yàn)證了Cookie的合法性，如果不合法直接丟棄；如果是合法的，那么就正常返回SYN+ACK。重點(diǎn)來(lái)了，現(xiàn)在服務(wù)端能向客戶(hù)端發(fā)HTTP響應(yīng)了！這是最顯著的改變，三次握手還沒(méi)建立，僅僅驗(yàn)證了Cookie的合法性，就可以返回HTTP響應(yīng)了。當(dāng)然，客戶(hù)端的ACK還得正常傳過(guò)來(lái)，不然怎么叫三次握手嘛。流程如下:注意:客戶(hù)端最后握手的ACK不一定要等到服務(wù)端的HTTP響應(yīng)到達(dá)才發(fā)送，兩個(gè)過(guò)程沒(méi)有任何關(guān)系。TFO的優(yōu)勢(shì)TFO的優(yōu)勢(shì)并不在與首輪三次握手，而在于后面的握手，在拿到客戶(hù)端的Cookie并驗(yàn)證通過(guò)以后，可以直接返回HTTP響應(yīng)，充分利用了1個(gè)RTT(Round-TripTime，往返時(shí)延)的時(shí)間提前進(jìn)行數(shù)據(jù)傳輸，積累起來(lái)還是一個(gè)比較大的優(yōu)勢(shì)。007:能不能說(shuō)說(shuō)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和timestampecho，各占4個(gè)字節(jié)。那么這些字段都是干嘛的呢？它們用來(lái)解決那些問(wèn)題？接下來(lái)我們就來(lái)一一梳理，TCP的時(shí)間戳主要解決兩大問(wèn)題:計(jì)算往返時(shí)延RTT(Round-TripTime)防止序列號(hào)的回繞問(wèn)題計(jì)算往返時(shí)延RTT在沒(méi)有時(shí)間戳的時(shí)候，計(jì)算RTT會(huì)遇到的問(wèn)題如下圖所示:如果以第一次發(fā)包為開(kāi)始時(shí)間的話(huà)，就會(huì)出現(xiàn)左圖的問(wèn)題，RTT明顯偏大，開(kāi)始時(shí)間應(yīng)該采用第二次的；如果以第二次發(fā)包為開(kāi)始時(shí)間的話(huà)，就會(huì)導(dǎo)致右圖的問(wèn)題，RTT明顯偏小，開(kāi)始時(shí)間應(yīng)該采用第一次發(fā)包的。實(shí)際上無(wú)論開(kāi)始時(shí)間以第一次發(fā)包還是第二次發(fā)包為準(zhǔn)，都是不準(zhǔn)確的。那這個(gè)時(shí)候引入時(shí)間戳就很好的解決了這個(gè)問(wèn)題。比如現(xiàn)在a向b發(fā)送一個(gè)報(bào)文s1，b向a回復(fù)一個(gè)含ACK的報(bào)文s2那么：step1:

a向b發(fā)送的時(shí)候，timestamp

中存放的內(nèi)容就是a主機(jī)發(fā)送時(shí)的內(nèi)核時(shí)刻

ta1。step2:

b向a回復(fù)s2報(bào)文的時(shí)候，timestamp

中存放的是b主機(jī)的時(shí)刻

tb,

timestampecho字段為從s1報(bào)文中解析出來(lái)的ta1。step3:

a收到b的s2報(bào)文之后，此時(shí)a主機(jī)的內(nèi)核時(shí)刻是ta2,而在s2報(bào)文中的timestampecho選項(xiàng)中可以得到

ta1,也就是s2對(duì)應(yīng)的報(bào)文最初的發(fā)送時(shí)刻。然后直接采用ta2-ta1就得到了RTT的值。防止序列號(hào)回繞問(wèn)題現(xiàn)在我們來(lái)模擬一下這個(gè)問(wèn)題。序列號(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開(kāi)始65~61~2？？？假設(shè)在第6次的時(shí)候，之前還滯留在網(wǎng)路中的包回來(lái)了，那么就有兩個(gè)序列號(hào)為1~2的數(shù)據(jù)包了，怎么區(qū)分誰(shuí)是誰(shuí)呢？這個(gè)時(shí)候就產(chǎn)生了序列號(hào)回繞的問(wèn)題。那么用timestamp就能很好地解決這個(gè)問(wèn)題，因?yàn)槊看伟l(fā)包的時(shí)候都是將發(fā)包機(jī)器當(dāng)時(shí)的內(nèi)核時(shí)間記錄在報(bào)文中，那么兩次發(fā)包序列號(hào)即使相同，時(shí)間戳也不可能相同，這樣就能夠區(qū)分開(kāi)兩個(gè)數(shù)據(jù)包了。008:TCP的超時(shí)重傳時(shí)間是如何計(jì)算的？TCP具有超時(shí)重傳機(jī)制，即間隔一段時(shí)間沒(méi)有等到數(shù)據(jù)包的回復(fù)時(shí)，重傳這個(gè)數(shù)據(jù)包。那么這個(gè)重傳間隔是如何來(lái)計(jì)算的呢？今天我們就來(lái)討論一下這個(gè)問(wèn)題。這個(gè)重傳間隔也叫做超時(shí)重傳時(shí)間(RetransmissionTimeOut,簡(jiǎn)稱(chēng)RTO)，它的計(jì)算跟上一節(jié)提到的RTT密切相關(guān)。這里我們將介紹兩種主要的方法，一個(gè)是經(jīng)典方法，一個(gè)是標(biāo)準(zhǔn)方法。經(jīng)典方法經(jīng)典方法引入了一個(gè)新的概念——SRTT(Smoothedroundtriptime，即平滑往返時(shí)間)，沒(méi)產(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è)算法過(guò)程還是很簡(jiǎn)單的，但是也存在一定的局限，就是在RTT穩(wěn)定的地方表現(xiàn)還可以，而在RTT變化較大的地方就不行了，因?yàn)槠交蜃应恋姆秶?.8~0.9,RTT對(duì)于RTO的影響太小。標(biāo)準(zhǔn)方法為了解決經(jīng)典方法對(duì)于RTT變化不敏感的問(wèn)題，后面又引出了標(biāo)準(zhǔn)方法，也叫Jacobson/Karels算法。一共有三步。第一步:計(jì)算SRTT，公式如下:SRTT=(1-α)*SRTT+α*RTT注意這個(gè)時(shí)候的

α跟經(jīng)典方法中的α取值不一樣了，建議值是1/8，也就是0.125。第二步:計(jì)算RTTVAR(round-triptimevariation)這個(gè)中間變量。RTTVAR=(1-β)*RTTVAR+β*(|RTT-SRTT|)β建議值為0.25。這個(gè)值是這個(gè)算法中出彩的地方，也就是說(shuō)，它記錄了最新的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:能不能說(shuō)一說(shuō)TCP的流量控制？對(duì)于發(fā)送端和接收端而言，TCP需要把發(fā)送的數(shù)據(jù)放到發(fā)送緩存區(qū),將接收的數(shù)據(jù)放到接收緩存區(qū)。而流量控制索要做的事情，就是在通過(guò)接收緩存區(qū)的大小，控制發(fā)送端的發(fā)送。如果對(duì)方的接收緩存區(qū)滿(mǎn)了，就不能再繼續(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表示接收窗口大小。流量控制過(guò)程這里我們不用太復(fù)雜的例子，以一個(gè)最簡(jiǎn)單的來(lái)回來(lái)模擬一下流量控制的過(guò)程，方便大家理解。首先雙方三次握手，初始化各自的窗口大小，均為200個(gè)字節(jié)。假如當(dāng)前發(fā)送端給接收端發(fā)送100個(gè)字節(jié)，那么此時(shí)對(duì)于發(fā)送端而言，SND.NXT當(dāng)然要右移100個(gè)字節(jié)，也就是說(shuō)當(dāng)前的可用窗口減少了100個(gè)字節(jié)，這很好理解?，F(xiàn)在這100個(gè)到達(dá)了接收端，被放到接收端的緩沖隊(duì)列中。不過(guò)此時(shí)由于大量負(fù)載的原因，接收端處理不了這么多字節(jié)，只能處理40個(gè)字節(jié)，剩下的

60

個(gè)字節(jié)被留在了緩沖隊(duì)列中。注意了，此時(shí)接收端的情況是處理能力不夠用啦，你發(fā)送端給我少發(fā)點(diǎn)，所以此時(shí)接收端的接收窗口應(yīng)該縮小，具體來(lái)說(shuō)，縮小60個(gè)字節(jié)，由200個(gè)字節(jié)變成了140字節(jié)，因?yàn)榫彌_隊(duì)列還有60個(gè)字節(jié)沒(méi)被應(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é)。這也就是流量控制的過(guò)程。盡管回合再多，整個(gè)控制的過(guò)程和原理是一樣的。010:能不能說(shuō)說(shuō)TCP的擁塞控制？上一節(jié)所說(shuō)的流量控制發(fā)生在發(fā)送端跟接收端之間，并沒(méi)有考慮到整個(gè)網(wǎng)絡(luò)環(huán)境的影響，如果說(shuō)當(dāng)前網(wǎng)絡(luò)特別差，特別容易丟包，那么發(fā)送端就應(yīng)該注意一些了。而這，也正是擁塞控制需要處理的問(wèn)題。對(duì)于擁塞控制來(lái)說(shuō)，TCP每條連接都需要維護(hù)兩個(gè)核心狀態(tài):擁塞窗口（CongestionWindow，cwnd）慢啟動(dòng)閾值（SlowStartThreshold，ssthresh）涉及到的算法有這幾個(gè):慢啟動(dòng)擁塞避免快速重傳和快速恢復(fù)接下來(lái)，我們就來(lái)一一拆解這些狀態(tài)和算法。首先，從擁塞窗口說(shuō)起。擁塞窗口擁塞窗口（CongestionWindow，cwnd）是指目前自己還能傳輸?shù)臄?shù)據(jù)量大小。那么之前介紹了接收窗口的概念，兩者有什么區(qū)別呢？接收窗口(rwnd)是接收端給的限制擁塞窗口(cwnd)是發(fā)送端的限制限制誰(shuí)呢？限制的是發(fā)送窗口的大小。有了這兩個(gè)窗口，如何來(lái)計(jì)算發(fā)送窗口？發(fā)送窗口大小=min(rwnd,cwnd)取兩者的較小值。而擁塞控制，就是來(lái)控制cwnd的變化。慢啟動(dòng)剛開(kāi)始進(jìn)入傳輸數(shù)據(jù)的時(shí)候，你是不知道現(xiàn)在的網(wǎng)路到底是穩(wěn)定還是擁堵的，如果做的太激進(jìn)，發(fā)包太急，那么瘋狂丟包，造成雪崩式的網(wǎng)絡(luò)災(zāi)難。因此，擁塞控制首先就是要采用一種保守的算法來(lái)慢慢地適應(yīng)整個(gè)網(wǎng)路，這種算法叫慢啟動(dòng)。運(yùn)作過(guò)程如下:首先，三次握手，雙方宣告自己的接收窗口大小雙方初始化自己的擁塞窗口(cwnd)大小在開(kāi)始傳輸?shù)囊欢螘r(shí)間，發(fā)送端每收到一個(gè)ACK，擁塞窗口大小加1，也就是說(shuō)，每經(jīng)過(guò)一個(gè)RTT，cwnd翻倍。如果說(shuō)初始窗口為10，那么第一輪10個(gè)報(bào)文傳完且發(fā)送端收到ACK后，cwnd變?yōu)?0，第二輪變?yōu)?0，第三輪變?yōu)?0，依次類(lèi)推。難道就這么無(wú)止境地翻倍下去？當(dāng)然不可能。它的閾值叫做慢啟動(dòng)閾值，當(dāng)cwnd到達(dá)這個(gè)閾值之后，好比踩了下剎車(chē)，別漲了那么快了，老鐵，先hold??！在到達(dá)閾值后，如何來(lái)控制cwnd的大小呢？這就是擁塞避免做的事情了。擁塞避免原來(lái)每收到一個(gè)ACK，cwnd加1，現(xiàn)在到達(dá)閾值了，cwnd只能加這么一點(diǎn):

1/cwnd。那你仔細(xì)算算，一輪RTT下來(lái)，收到cwnd個(gè)ACK,那最后擁塞窗口的大小cwnd總共才增加1。也就是說(shuō)，以前一個(gè)RTT下來(lái)，cwnd翻倍，現(xiàn)在cwnd只是增加1而已。當(dāng)然，慢啟動(dòng)和擁塞避免是一起作用的，是一體的?？焖僦貍骱涂焖倩謴?fù)快速重傳在TCP傳輸?shù)倪^(guò)程中，如果發(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í)間到了才重傳。這就是快速重傳，它解決的是是否需要重傳的問(wèn)題。選擇性重傳那你可能會(huì)問(wèn)了，既然要重傳，那么只重傳第5個(gè)包還是第5、6、7個(gè)包都重傳呢？當(dāng)然第6、7個(gè)都已經(jīng)到達(dá)了，TCP的設(shè)計(jì)者也不傻，已經(jīng)傳過(guò)去干嘛還要傳？干脆記錄一下哪些包到了，哪些沒(méi)到，針對(duì)性地重傳。在收到發(fā)送端的報(bào)文后，接收端回復(fù)一個(gè)ACK報(bào)文，那么在這個(gè)報(bào)文首部的可選項(xiàng)中，就可以加上SACK這個(gè)屬性，通過(guò)leftedge和rightedge告知發(fā)送端已經(jīng)收到了哪些區(qū)間的數(shù)據(jù)報(bào)。因此，即使第5個(gè)包丟包了，當(dāng)收到第6、7個(gè)包之后，接收端依然會(huì)告訴發(fā)送端，這兩個(gè)包到了。剩下第5個(gè)包沒(méi)到，就重傳這個(gè)包。這個(gè)過(guò)程也叫做選擇性重傳(SACK，SelectiveAcknowledgment)，它解決的是如何重傳的問(wèn)題?？焖倩謴?fù)當(dāng)然，發(fā)送端收到三次重復(fù)ACK之后，發(fā)現(xiàn)丟包，覺(jué)得現(xiàn)在的網(wǎng)絡(luò)已經(jīng)有些擁塞了，自己會(huì)進(jìn)入快速恢復(fù)階段。在這個(gè)階段，發(fā)送端如下改變：擁塞閾值降低為cwnd的一半cwnd的大小變?yōu)閾砣撝礳wnd線性增加以上就是TCP擁塞控制的經(jīng)典算法:

慢啟動(dòng)、擁塞避免、快速重傳和快速恢復(fù)。011:能