目錄

一、簡述TCP連接和關(guān)閉的狀態(tài)轉(zhuǎn)移

二、簡述TCP慢啟動

三、簡述TCP如何保證有序

四、簡述TCP常見的擁塞控制算法

五、簡述TCP超時重傳

---

一、簡述TCP連接和關(guān)閉的狀態(tài)轉(zhuǎn)移

????????圖中上半部分是TCP的三次握手過程的狀態(tài)變遷，下半部分是TCP四次揮手過程的狀態(tài)變遷。

? ? ? ? 1、CLOSED。起始點，在超時或者連接關(guān)閉時進入此狀態(tài)，這并不是一個真正的狀態(tài)，而是這個狀態(tài)圖的假想起點和終點。

? ? ? ? 2、LISTEN。服務(wù)器端等待連接的狀態(tài)。服務(wù)器經(jīng)過socket，bind，listen函數(shù)之后進入此狀態(tài)，開始監(jiān)聽客戶端發(fā)過來的連接請求。這稱為應(yīng)用程序被動打開（等待客戶端連接請求）。

? ? ? ? 3、SYN_SENT。第一次握手發(fā)生階段，客戶端發(fā)起連接?？蛻舳苏{(diào)用connect，發(fā)送SYN給服務(wù)器端，然后進入SYN_SENT狀態(tài)，等待服務(wù)器端確認（三次握手中的第二個報文）。如果服務(wù)器端不能連接，則直接進入CLOSED狀態(tài)。

? ? ? ? 4、SYN_RCVD。第二次握手發(fā)生階段，與3相對應(yīng)，這里是服務(wù)器端接收到了客戶端的SYN，此時服務(wù)器由LISTEN進入SYN_RCVD狀態(tài)，同時服務(wù)器端回應(yīng)一個ACK，然后再發(fā)送一個SYN即SYN+ACK給客戶端。狀態(tài)圖中還描述了這樣一種情況，當(dāng)客戶端在發(fā)送SYN的同時也收到服務(wù)器端的SYN請求，即同時發(fā)起連接請求，那么客戶端就會從SYN_SENT轉(zhuǎn)換到SYN_RCVD狀態(tài)。

? ? ? ? 5、ESTABLISHED。第三次握手發(fā)生階段，客戶端接收到服務(wù)器端的ACK包（ACK，SYN）之后，也會發(fā)送一個ACK確認包，客戶端進入ESTABLISHED狀態(tài)，表明客戶端這邊已經(jīng)準備好，但TCP需要兩端都準備好才可以進行數(shù)據(jù)傳輸。服務(wù)器端收到客戶端的ACK之后會從SYN_RCVD狀態(tài)轉(zhuǎn)換到ESTABLISHED狀態(tài)，表明服務(wù)器端也準備好進行數(shù)據(jù)傳輸了。這樣客戶端和服務(wù)器端都是ESTABLISHED狀態(tài)，就可以進行后面的數(shù)據(jù)傳輸了。所以ESTABLISHED也可以說是一個數(shù)據(jù)傳送狀態(tài)。

? ? ? ? 下面介紹TCP四次揮手過程的狀態(tài)變遷：

? ? ? ? 1、FIN_WAIT_1。第一次揮手，主動關(guān)閉的一方（執(zhí)行主動關(guān)閉的一方既可以是客戶端，也可以是服務(wù)器端。這里以客戶端執(zhí)行主動關(guān)閉為例），終止連接時，發(fā)送FIN給對方，然后等待對方返回ACK。調(diào)用close()第一次揮手就進入此狀態(tài)。

? ? ? ? 2、CLOSE_WAIT。接收到FIN之后，被動關(guān)閉的一方進入此狀態(tài)。具體動作是接收到FIN，同時發(fā)送ACK。之所以叫CLOSE_WAIT，可以理解為被動關(guān)閉的一方此時正在等待上層應(yīng)用程序發(fā)出關(guān)閉連接指令。TCP關(guān)閉是全雙工過程，這里客戶端執(zhí)行了主動關(guān)閉，被動方服務(wù)器端接收到FIN后也需要調(diào)用close關(guān)閉，這個CLOSE_WAIT就是處于這個狀態(tài)，等待發(fā)送FIN，發(fā)送了FIN則進入LAST_ACK狀態(tài)。

? ? ? ? 3、FIN_WAIT_2。主動端（這里是客戶端）先執(zhí)行主動關(guān)閉發(fā)送FIN，然后接收到被動方返回的ACK后進入此狀態(tài)。

? ? ? ? 4、LAST_ACK。被動方（服務(wù)器端）發(fā)起關(guān)閉請求，由狀態(tài)2進入此狀態(tài)，具體動作是發(fā)送FIN給對方，同時在接收到ACK時進入CLOSED狀態(tài)。

? ? ? ? 5、CLOSING。兩邊同時發(fā)起關(guān)閉請求時（即主動方發(fā)送FIN，等待被動方返回ACK，同時被動方也發(fā)送了FIN，主動方接收到FIN之后，發(fā)送ACK給被動房），主動方會由FIN_WAIT_1進入此狀態(tài)，等待被動方返回ACK。

? ? ? ? 6、TIME_WAIT。從狀態(tài)變遷圖中看到，四次揮手操作最后都會經(jīng)過這樣一個狀態(tài)然后進入CLOSED狀態(tài)。

表1 狀態(tài)解析

*狀態(tài)*	描述
CLOSED	阻塞或關(guān)閉狀態(tài)，表示主機當(dāng)前沒有正在傳輸或者建立的鏈接
LISTEN	監(jiān)聽狀態(tài)，表示服務(wù)器做好準備，等待建立傳輸鏈接
SYN_RECV	收到第一次傳輸請求，還未進行確認
SYN_SENT	發(fā)送完第一個SYN報文，等待收到確認
ESTABLISHED	鏈接正常建立之后進入數(shù)據(jù)傳輸階段
FIN_WAIT_1	主動發(fā)送第一個FIN報文之后進入該狀態(tài)
FIN_WAIT_2	已經(jīng)收到第一個FIN的確認信號，等待對方發(fā)送關(guān)閉請求
TIMED_WAIT	完成雙向鏈接關(guān)閉，等待分組消失
CLOSING	雙方同時關(guān)閉請求，等待對方確認
CLOSING_WAIT	收到對方的關(guān)閉請求并進行確認進入該狀態(tài)
LAST_ACK	等待最后一次確認關(guān)閉的報文

二、簡述TCP慢啟動

????????慢啟動（Slow Start），是傳輸控制協(xié)議（TCP）使用的一種阻塞控制機制。慢啟動也叫做指數(shù)增長期。慢啟動是指每次TCP接收窗口收到確認時都會增長。增加的大小就是已確認段的數(shù)目。這種情況一直保持到要么沒有收到一些段，要么窗口大小到達預(yù)先定義的閾值。如果發(fā)生丟失事件，TCP就認為這是網(wǎng)絡(luò)阻塞，就會采取措施減輕網(wǎng)絡(luò)擁擠。一旦發(fā)生丟失事件或者到達閾值，TCP就會進入線性增長階段。這時，每經(jīng)過一個RTT窗口增長一個段。

三、簡述TCP如何保證有序

? ? ? ? 1、主機每次發(fā)送數(shù)據(jù)時，TCP就給每個數(shù)據(jù)包分配一個序列號并且在一個特定的時間內(nèi)等待接收主機對分配的這個序列號進行確認，如果發(fā)送主機在一個特定時間內(nèi)沒有收到接收主機的確認，則發(fā)送主機會重傳此數(shù)據(jù)包。接收主機利用序列號對接收數(shù)據(jù)進行確認，以便檢測對方發(fā)送的數(shù)據(jù)是否有丟失或者亂序等。接收主機一旦收到已經(jīng)順序化的數(shù)據(jù)，它就將這些數(shù)據(jù)按正確的順序重組成數(shù)據(jù)流并傳遞給高層進行處理。

? ? ? ? 2、具體的步驟為：

? ? ? ? （1）為了保證數(shù)據(jù)包的可靠傳遞，發(fā)送方必須把已經(jīng)發(fā)送的數(shù)據(jù)包保留在緩沖區(qū)；

? ? ? ? （2）并為每個已發(fā)送的數(shù)據(jù)包啟動一個超時定時器；

? ? ? ? （3）如在定時器超時之前收到了對方發(fā)來的應(yīng)答信息（可能是對本包的應(yīng)答，也可能是對本包后續(xù)包的應(yīng)答），則釋放該數(shù)據(jù)包占用的緩沖區(qū)；

? ? ? ? （4）否則，重傳數(shù)據(jù)包，直到收到應(yīng)答或重傳次數(shù)超過規(guī)定的最大次數(shù)為止；

? ? ? ? （5）接收方收到數(shù)據(jù)包后，先進行CRC校驗，如果正確則把數(shù)據(jù)交給上層協(xié)議，然后發(fā)送方發(fā)送一個累計應(yīng)答包，表明該數(shù)據(jù)已經(jīng)收到，如果接收方正好也有數(shù)據(jù)要發(fā)給發(fā)送方，應(yīng)答包也可以在數(shù)據(jù)包中捎帶過去。

四、簡述TCP常見的擁塞控制算法

? ? ? ? 1、TCP Tahoe/Reno

? ? ? ? 最初的實現(xiàn)，包括慢啟動、擁塞避免兩個部分?；谥貍鞒瑫r（retransmission timeout/RTO）和重復(fù)確認為條件判斷是否發(fā)生了丟包。兩者的區(qū)別在于：Tahoe算法下如果收到三次重復(fù)確認，就進入快重傳立即重發(fā)丟失的數(shù)據(jù)包，同時將慢啟動閾值設(shè)置為當(dāng)前擁塞窗口的一半，將擁塞窗口設(shè)置為1MSS，進入慢啟動狀態(tài)；而Reno算法如果收到三次重復(fù)確認，就進入快重傳，但不進入慢啟動狀態(tài)，而是直接將擁塞窗口減半，進入擁塞控制階段，這稱為“快恢復(fù)”。

? ? ? ? 2、TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）

? ? ? ? BBR是由Google設(shè)計，于2016年發(fā)布的擁塞算法。以往大部分擁塞算法是基于丟包來作為降低傳輸速率的信號，而BBR則基于模型主動探測。該算法使用網(wǎng)絡(luò)最近出站數(shù)據(jù)分組當(dāng)時的最大帶寬和往返時間來建立網(wǎng)絡(luò)的顯式模型。數(shù)據(jù)包傳輸?shù)拿總€累積或選擇性確認用于生成記錄在數(shù)據(jù)包傳輸過程和確認返回期間的時間內(nèi)所傳送數(shù)據(jù)量的采樣率。該算法認為隨著網(wǎng)絡(luò)接口控制器逐漸進入千兆速度時，分組丟失不應(yīng)該被認為是識別擁塞的主要決定因素，所以基于模型的擁塞控制算法能有更高的吞吐量和更低的延遲，可以用BBR來替代其它流行的擁塞算法，例如CUBIC。

五、簡述TCP超時重傳

? ? ? ? TCP可靠性中最重要的一個機制是處理數(shù)據(jù)超時和重傳。

????????TCP協(xié)議要求在發(fā)送端每發(fā)送一個報文段，就啟動一個定時器并等待確認信息。接收端成功接收到新數(shù)據(jù)后返回確認信息。若在定時器超時前數(shù)據(jù)未能被確認，TCP就認為報文段中的數(shù)據(jù)已丟失或損壞，需要對報文段中的數(shù)據(jù)重新組織和重傳。