前言

文章參考：

• 《網(wǎng)絡(luò)是怎樣連接的》：https://book.douban.com/subject/26941639/
• 《圖解網(wǎng)絡(luò)》：https://www.xiaolincoding.com/network/

在開始閱讀該博客之前，先要好好了解一下TCP報(bào)文頭部到底有那些信息，閱讀后續(xù)內(nèi)容時(shí)有任何模糊的地方都可以回來這里查看梳理，接下來我來解釋一下：

• 發(fā)送方端口：發(fā)送網(wǎng)絡(luò)包程序的端口號(hào)
• 接收方端口：接收網(wǎng)絡(luò)包程序的端口號(hào)
• 序列號(hào)：也叫序號(hào)（seq），發(fā)送數(shù)據(jù)的順序編號(hào)。發(fā)送方告知接收方數(shù)據(jù)包有多少個(gè)字節(jié)。
• 確認(rèn)號(hào)：也叫ACK號(hào)（ack），接收數(shù)據(jù)的順序編號(hào)。接收方告知發(fā)送方已經(jīng)收到所有數(shù)據(jù)的第幾個(gè)字節(jié)。
• 首部長(zhǎng)度：也叫數(shù)據(jù)偏移量。表示數(shù)據(jù)部分的起始位置。
• 保留：暫時(shí)沒用
• 控制位：也叫標(biāo)志位。上圖中藍(lán)色部分，又叫標(biāo)志位。
  • URG：表示緊急指針字段有效
  • ACK：表示接收數(shù)據(jù)序號(hào)字段有效，一般表示數(shù)據(jù)被接收方接收。（注意：此ACK和上面的確認(rèn)號(hào)ACK不是一回事，不要混淆）
  • PSH：表示通過Flush操作發(fā)送數(shù)據(jù)
  • RST：強(qiáng)制斷開連接
  • SYN：發(fā)送方和接收方互相確認(rèn)，表示連接。
  • FIN：表示斷開連接。
• 窗口大小：表示接收方告知發(fā)送方窗口大小。
• 校驗(yàn)和：用于檢查是否出現(xiàn)錯(cuò)誤。
• 緊急指針：應(yīng)緊急處理的數(shù)據(jù)位置。
• 可選字段：除了連接操作，很少使用該部分。

除了可選字段，其余TCP頭部信息總大小固定為20字節(jié)。

1、連接管理

TCP協(xié)議是面向連接的協(xié)議。

我們使用瀏覽器向服務(wù)器發(fā)送HTTP請(qǐng)求時(shí)，傳輸層協(xié)議使用TCP協(xié)議的。所以瀏覽器如果想要通過網(wǎng)卡將數(shù)據(jù)包發(fā)送到服務(wù)器，我們需要先進(jìn)行連接管理，也就是大名鼎鼎的三次握手、四次揮手（面試愛問）。

• 連接建立：三次握手
• 連接釋放：四次揮手

1.1、三次握手

• 第一次握手：首先服務(wù)端暫時(shí)處于監(jiān)聽狀態(tài)，客戶端主動(dòng)發(fā)送第一次握手請(qǐng)求，TCP頭部標(biāo)志位SYN置為1，序列號(hào)seq置為隨機(jī)生成的數(shù)x，此時(shí)客戶端進(jìn)程狀態(tài)變成SYN_SENT，第一次握手發(fā)送完畢。（服務(wù)端確定：自己具備接收客戶端請(qǐng)求的能力）
• 第二次握手：服務(wù)端收到第一次握手的請(qǐng)求后，服務(wù)端進(jìn)行第二次握手請(qǐng)求的發(fā)送。首先先將標(biāo)志位SYN、ACK置為1，序列號(hào)seq置為隨機(jī)生成的數(shù)y，確認(rèn)號(hào)ack置為x + 1，然后完成第二次握手的發(fā)送，發(fā)送完畢后服務(wù)端進(jìn)程狀態(tài)變成SYN_RVCD，第二次握手完畢。（客戶端確定：自己具備接收、發(fā)送請(qǐng)求的能力）
• 第三次握手：客戶端收到服務(wù)端返回的響應(yīng)后，準(zhǔn)備發(fā)送第三次握手的請(qǐng)求包。其中標(biāo)志位ACK置為1，序列號(hào)seq置為x + 1，確認(rèn)號(hào)ack置為y + 1，第三次握手發(fā)送完畢，服務(wù)端接收后建立連接完畢，客戶端與服務(wù)端的進(jìn)程都進(jìn)入ESTABLISHED狀態(tài)。（服務(wù)端確定：自己具備發(fā)送請(qǐng)求給客戶端的能力）

1.2、四次揮手

• 第一次揮手：客戶端主動(dòng)發(fā)送標(biāo)志位ACK為1，序列號(hào)seq為x的數(shù)據(jù)包。此時(shí)客戶端進(jìn)程進(jìn)入FIN-WAIT-1狀態(tài)。
• 第二次揮手：服務(wù)端接收到客戶端第一次揮手請(qǐng)求，準(zhǔn)備發(fā)送第二次揮手，狀態(tài)位ACK置為1，序列號(hào)seq置為y，確認(rèn)號(hào)ack置為x + 1。發(fā)送完畢后服務(wù)端進(jìn)入CLOSE_WAIT狀態(tài)，客戶端接收到第二次揮手的請(qǐng)求進(jìn)入FIN_WAIT_2狀態(tài)，此時(shí)客戶端依舊可以接收服務(wù)端未發(fā)送完畢的數(shù)據(jù)。
• 第三次揮手：數(shù)據(jù)傳輸完畢后，服務(wù)端發(fā)起第三次揮手。狀態(tài)位SYN、ACK置為1，確認(rèn)號(hào)ack依舊是x，序列號(hào)seq置為z。第三次揮手發(fā)送完畢后，服務(wù)端進(jìn)入LAST_ACK狀態(tài)。
• 第四次揮手：客戶端收到第三次揮手，準(zhǔn)備發(fā)送第四次揮手請(qǐng)求，狀態(tài)位ACK置為1，序列號(hào)seq置為x + 1，確認(rèn)號(hào)ack置為z + 1，此時(shí)客戶端進(jìn)入TIME_WAIT狀態(tài)，等待2MSL后自動(dòng)進(jìn)入CLOSE狀態(tài)。服務(wù)端收到第四次揮手報(bào)文后會(huì)變成CLOSE狀態(tài)。（2MSL：報(bào)文段的最長(zhǎng)生存時(shí)間；用來等待在網(wǎng)絡(luò)中被丟棄或產(chǎn)生的延遲、重復(fù)數(shù)據(jù)包被清除）

2、校驗(yàn)和

TCP校驗(yàn)和（Checksum）是一個(gè)端到端的校驗(yàn)和，由發(fā)送端計(jì)算，然后由接收端驗(yàn)證。其目的是為了發(fā)現(xiàn)TCP首部和數(shù)據(jù)在發(fā)送端到接收端之間發(fā)生的任何改動(dòng)。如果接收方檢測(cè)到校驗(yàn)和有差錯(cuò)，則TCP段會(huì)被直接丟棄。

關(guān)于校驗(yàn)和不做過多解釋，詳細(xì)解釋請(qǐng)參考這篇文章：https://blog.csdn.net/qq_15437629/article/details/79183076

3、序列號(hào) + 確認(rèn)應(yīng)答

通過序號(hào)和確認(rèn)號(hào)可以確認(rèn)接收方是否接收到了網(wǎng)絡(luò)包。

最開始，在講解TCP頭部信息時(shí)，有個(gè)屬性叫做序列號(hào)（或者叫序號(hào)）。

TCP模塊會(huì)對(duì)應(yīng)用進(jìn)程傳遞來的請(qǐng)求報(bào)文信息進(jìn)行分組（根據(jù)MSS長(zhǎng)度為單位），然后為每個(gè)分組封裝對(duì)應(yīng)的TCP報(bào)文頭部信息，分組中的每一個(gè)字節(jié)信息都有對(duì)應(yīng)的序列號(hào)，此時(shí)TCP頭部中序列號(hào)屬性值 = 該分組中第一個(gè)字節(jié)數(shù)據(jù)的序列號(hào)。

TCP頭部有了序列號(hào)信息，接收方收到的數(shù)據(jù)就可以根據(jù)序列號(hào)進(jìn)行排序（防止亂序），出現(xiàn)重復(fù)序列號(hào)的分組數(shù)據(jù)就可以進(jìn)行去重操作（丟掉）。

關(guān)于確認(rèn)應(yīng)答其實(shí)就比較好理解，最開始講解三次握手、四次揮手時(shí)經(jīng)常提到一個(gè)ack，就是確認(rèn)號(hào)ack，確認(rèn)號(hào)就是：接收方告知發(fā)送方已經(jīng)收到所有數(shù)據(jù)的第幾個(gè)字節(jié)。這樣發(fā)送方就能夠得知接收方是否真的接收到的分組信息。

通過序列號(hào) + 確認(rèn)應(yīng)答這種回合制（一問一答）方式就能很好的保障雙方數(shù)據(jù)報(bào)文傳遞的可靠性！

4、重傳機(jī)制

特殊情況下，數(shù)據(jù)包會(huì)出現(xiàn)丟失和延遲等情況，例如：接收方暫時(shí)宕機(jī)、網(wǎng)絡(luò)抖動(dòng)等…
TCP協(xié)議作為可靠的傳輸協(xié)議自然要處理這些極端情況，總不能數(shù)據(jù)包丟失了就不要了吧？所以TCP有了重傳機(jī)制，常見的重傳方式主要分為4種（其中重點(diǎn)介紹前2種）：

• 超時(shí)重傳
• 快速重傳
• SACK
• D-SACK

4.1、超時(shí)重傳

超時(shí)重傳比較好理解，根據(jù)字面意思：如果發(fā)送方長(zhǎng)時(shí)間沒有收到接收方的確認(rèn)應(yīng)答就會(huì)將數(shù)據(jù)包進(jìn)行重傳操作，當(dāng)然超時(shí)重傳并不是只針對(duì)發(fā)送方重傳，接收方在返回響應(yīng)數(shù)據(jù)包時(shí)也可能丟失，也需要進(jìn)行超時(shí)重傳的操作。

具體來說就是發(fā)送方在發(fā)送數(shù)據(jù)包后，會(huì)設(shè)置一個(gè)定時(shí)器，定時(shí)器的時(shí)間叫做超時(shí)重傳時(shí)間（RTO），該時(shí)間范圍內(nèi)未收到接收方ACK標(biāo)志位的TCP數(shù)據(jù)包，就會(huì)進(jìn)行重傳操作。

當(dāng)然RTO時(shí)長(zhǎng)會(huì)影響到 TCP 的性能，應(yīng)該根據(jù)具體網(wǎng)絡(luò)的實(shí)際狀況動(dòng)態(tài)地進(jìn)行調(diào)整。

• RTO 設(shè)置太?。簳?huì)導(dǎo)致數(shù)據(jù)不必要重傳，增加網(wǎng)絡(luò)負(fù)擔(dān)。
• RTO 設(shè)置太大，會(huì)導(dǎo)致數(shù)據(jù)傳輸?shù)难舆t，降低吞吐量。

• 情況1：發(fā)送方請(qǐng)求數(shù)據(jù)包丟失。
  

• 情況2：接收方響應(yīng)數(shù)據(jù)包丟失。
  

特殊場(chǎng)景：即便觸發(fā)了超時(shí)重傳，重傳的數(shù)據(jù)包很有可能再次超時(shí)；此時(shí)TCP會(huì)將下一次重傳的超時(shí)時(shí)間設(shè)置為當(dāng)前RTO時(shí)長(zhǎng)2倍。這樣還是會(huì)極大的影響TCP傳輸?shù)恼w性能，所以有了快速重傳這種方式。

4.2、快速重傳

快速重傳不是通過時(shí)間來判斷是否該進(jìn)行重傳操作，而是通過冗余ACK報(bào)文確認(rèn)是否出現(xiàn)了問題，才考慮是否要觸發(fā)快速重傳。

如下圖所示，多次響應(yīng)的ACK報(bào)文確認(rèn)號(hào)都是報(bào)文段2的TCP頭部確認(rèn)號(hào)，這樣接收端就明白該報(bào)文信息是有問題的！就觸發(fā)了快速重傳功能。所以，快速重傳：是當(dāng)收到三個(gè)相同的 ACK確認(rèn)號(hào)報(bào)文時(shí)，會(huì)在定時(shí)器過期之前，重傳丟失的報(bào)文段（seq2）。

說到這里，特別解釋一下，上圖中跟之前提到的確認(rèn)應(yīng)答方式有些不同，上圖這種屬于連續(xù)發(fā)送請(qǐng)求，并不是必須等待應(yīng)答后再發(fā)送下一次請(qǐng)求，這種方式叫做累計(jì)應(yīng)答，是TCP的滑動(dòng)窗口機(jī)制提供的功能，后續(xù)會(huì)提到！

關(guān)于SACK和D-SACK重傳方案細(xì)節(jié)，這里就不做詳細(xì)介紹了，如果有興趣可以參考其他文章。

5、流量控制

TCP協(xié)議是通過滑動(dòng)窗口進(jìn)行流量控制，在介紹滑動(dòng)窗口之前，先通過一個(gè)場(chǎng)景了解一下什么是流量控制。發(fā)送方進(jìn)行數(shù)據(jù)發(fā)送操作需要考慮一下接收方的數(shù)據(jù)接收能力；如果發(fā)送方數(shù)據(jù)發(fā)送太快，接收方來不及接受處理，那就會(huì)導(dǎo)致接收方把大量數(shù)據(jù)包存放到緩沖區(qū)中，緩沖區(qū)如果放慢那就將多余的數(shù)據(jù)包扔掉，這樣勢(shì)必會(huì)導(dǎo)致網(wǎng)絡(luò)帶寬資源的浪費(fèi)。

所以，TCP通過滑動(dòng)窗口來控制發(fā)送的發(fā)送速率（窗口大小），從而讓接收方更從容的接收處理數(shù)據(jù)包！

5.1、累計(jì)應(yīng)答

在講解3.2、快速重傳時(shí)有個(gè)場(chǎng)景，不知道大家注意到?jīng)]有，就是當(dāng)我們發(fā)送一次seq數(shù)據(jù)包時(shí)還未等到拿到確認(rèn)號(hào)報(bào)文就可以再次發(fā)送下一次seq數(shù)據(jù)包，這跟我們之前提到的確認(rèn)應(yīng)答好像有點(diǎn)沖突！

其實(shí)確認(rèn)應(yīng)答這種回合制交互方式效率還是很低的…如果往返時(shí)間（RTT）過長(zhǎng)，網(wǎng)絡(luò)的使用效率勢(shì)必會(huì)受到極大的影響！所以能不能連續(xù)發(fā)送多次TCP分組，不需要等待響應(yīng)再進(jìn)行下次發(fā)送操作呢？所以TCP報(bào)文頭中有個(gè)窗口大小屬性，該屬性開辟一個(gè)緩沖區(qū)（或者叫窗口），本質(zhì)就是操作系統(tǒng)一塊內(nèi)存區(qū)域，用于存放發(fā)送出去的分組數(shù)據(jù)，不需要讓發(fā)送方等待接收方的確認(rèn)應(yīng)答數(shù)據(jù)包，發(fā)送方可以連續(xù)發(fā)送數(shù)據(jù)，只要不超出緩沖區(qū)（窗口）大小。

如果連續(xù)發(fā)送數(shù)據(jù)包過程中，個(gè)別數(shù)據(jù)包發(fā)送失敗，可以通過下一次應(yīng)答來確認(rèn)，根本不需要重發(fā)！這種連續(xù)發(fā)送TCP分組的機(jī)制，我們稱之為累計(jì)應(yīng)答（通過窗口大小限制），如下圖：

5.2、滑動(dòng)窗口

滑動(dòng)窗口是操作系統(tǒng)開辟的一個(gè)緩存區(qū)，發(fā)送方如果沒收到確認(rèn)應(yīng)答TCP數(shù)據(jù)包，需要緩沖區(qū)中保留已發(fā)送的數(shù)據(jù)。收到應(yīng)答后從緩存區(qū)清除數(shù)據(jù)。

滑動(dòng)窗口的大?。?code>rwnd）由接收方來掌控主導(dǎo)的。畢竟能接收處理多少字節(jié)數(shù)據(jù)，接收方自己是心知肚明的，總不能吃飽了繼續(xù)喂吧，那不得撐壞咯。如果發(fā)送方的窗口大小rwnd為0，那就不允許繼續(xù)發(fā)送數(shù)據(jù)了（說明接收方還沒處理完畢呢?。?，那么發(fā)送方會(huì)不斷的向接收方進(jìn)行詢問：你還有空間接收處理嗎？如果接收方有可用窗口了，就會(huì)告訴發(fā)送方，發(fā)送方會(huì)根據(jù)接收方的響應(yīng)調(diào)整維護(hù)接收方自己的滑動(dòng)窗口，繼續(xù)快樂的進(jìn)行發(fā)送了！

發(fā)送方、接收方窗口調(diào)整流程如下（圖片來自：小林Coding）。

• 發(fā)送方窗口：
  
  
  
• 接收方窗口：
  

雙方彼此進(jìn)行交互，各自不斷調(diào)整維護(hù)滑動(dòng)窗口緩沖區(qū)大小，這樣就不會(huì)出現(xiàn)發(fā)送方發(fā)送能力遠(yuǎn)遠(yuǎn)大于接收方處理能力的場(chǎng)景，從而達(dá)到了流量控制的目的！

6、擁塞控制

該小節(jié)圖片均來自于小林Coding！

上面解釋完了流量控制，接下來先來看看這二者有哪些相似、不同之處。

• 關(guān)于二者作用：
  • 流量控制：防止發(fā)送方發(fā)送數(shù)據(jù)量大于接收方接收處理數(shù)據(jù)的速度，從而導(dǎo)致數(shù)據(jù)丟失、重傳，造成網(wǎng)絡(luò)效率低下。
  • 擁塞控制：防止發(fā)送方將大量數(shù)據(jù)輸入到網(wǎng)絡(luò)鏈路中，從而導(dǎo)致網(wǎng)絡(luò)傳輸鏈路擁擠堵塞，傳輸速率降低、延遲，同樣會(huì)導(dǎo)致數(shù)據(jù)丟失、重傳，網(wǎng)絡(luò)效率低下。
• 關(guān)于二者窗口：
  • 流量控制：滑動(dòng)窗口rwnd，窗口大小為1 = 能傳1字節(jié)數(shù)據(jù)
  • 擁塞控制：擁塞窗口cwnd，窗口大小為1 = 能傳1個(gè)數(shù)據(jù)包

擁塞控制主要就是為了防止：大量的數(shù)據(jù)包輸入到網(wǎng)絡(luò)中，讓網(wǎng)絡(luò)傳輸負(fù)載過大，導(dǎo)致大量的丟包、重傳，惡性循環(huán)！
所以我們就需要控制發(fā)送方，通過擁塞窗口cwnd根據(jù)當(dāng)前網(wǎng)絡(luò)狀態(tài)動(dòng)態(tài)調(diào)整窗口大小，從而避免當(dāng)網(wǎng)絡(luò)鏈路阻塞時(shí)，還大量的將數(shù)據(jù)包發(fā)送給接收方！一般情況下，在規(guī)定時(shí)間內(nèi)沒有收到接收方的確認(rèn)TCP報(bào)文，就可以認(rèn)為當(dāng)前網(wǎng)絡(luò)狀況較為阻塞。

擁塞控制主要分為以下4種算法，接下來依次詳細(xì)解釋一下：

• 慢啟動(dòng)（慢開始）
• 擁塞避免
• 擁塞發(fā)生
• 快速恢復(fù)

6.1、慢啟動(dòng)

聽名字就能理解：剛開始啟動(dòng)時(shí)候，要慢點(diǎn)向網(wǎng)絡(luò)鏈路中輸入數(shù)據(jù)，剛開始不能用力過猛，應(yīng)該先輸入少量數(shù)據(jù)，然后判斷網(wǎng)絡(luò)擁塞狀況不斷的調(diào)整擁塞窗口cwnd的大小。如果起初就直接注入大量的數(shù)據(jù)到網(wǎng)絡(luò)中，很有可能直接導(dǎo)致網(wǎng)絡(luò)擁塞堵塞的情況發(fā)生。關(guān)于窗口大小擴(kuò)容：發(fā)送方每收到一個(gè) ACK 確認(rèn)報(bào)文，擁塞窗口 cwnd 的大小就會(huì)雙倍增長(zhǎng)：1，2，4，8，16.....

6.2、擁塞避免

但是慢啟動(dòng)這種成倍增長(zhǎng)并不是一直生效的，慢啟動(dòng)持續(xù)增長(zhǎng)到一定階段會(huì)進(jìn)入到擁塞避免階段。那么什么時(shí)候進(jìn)行切換呢？
這里要引出一個(gè)概念叫做慢啟動(dòng)門限 ssthresh。

• 當(dāng) cwnd < ssthresh ，就使用慢啟動(dòng)算法。
• 當(dāng) cwnd >= ssthresh ，就會(huì)切換擁塞避免算法

例如：當(dāng)前的ssthresh = 8，那么當(dāng)擁塞窗口cwnd大小達(dá)到慢啟動(dòng)門限ssthresh ，就從指數(shù)增長(zhǎng)變成線性增長(zhǎng)（慢啟動(dòng)變成擁塞避免）

6.3、擁塞發(fā)生

可惜好景不長(zhǎng)，擁塞避免的線性增長(zhǎng)慢慢也會(huì)導(dǎo)致網(wǎng)絡(luò)進(jìn)入擁塞狀態(tài)，從而導(dǎo)致丟包現(xiàn)象的發(fā)生。之前提到過丟包時(shí)TCP會(huì)觸發(fā)重傳機(jī)制（超時(shí)重傳 + 快速重傳）。

• 當(dāng)發(fā)生超時(shí)重傳時(shí)的擁塞發(fā)生算法：直接變成了慢啟動(dòng)階段…慘不忍睹！
  • ssthresh 設(shè)為 cwnd/2，
  • cwnd 重置為 1 （恢復(fù)為 cwnd 初始值，假定初始值 1）

• 當(dāng)發(fā)生快速重傳時(shí)的擁塞發(fā)生算法：接收方接收到之前數(shù)據(jù)包三次相同的ACK觸發(fā)
  • cwnd = cwnd/2
  • ssthresh = cwnd
  • 進(jìn)入快速恢復(fù)算法

6.4、快速恢復(fù)

TCP會(huì)認(rèn)為超時(shí)重傳比快速重傳的網(wǎng)絡(luò)擁塞狀況更嚴(yán)重，畢竟快速重傳的觸發(fā)條件是：接收方收到三次相同的ACK包。

當(dāng)發(fā)生快速重傳后會(huì)直接切換到快速恢復(fù)算法：文章來源地址http://www.zghlxwxcb.cn/news/detail-828875.html

• cwnd = ssthresh + 3
• 重傳丟失的數(shù)據(jù)包
• 如果收到重復(fù)的 ACK，那么 cwnd 增加 1
• 如果收到新的 ACK，把 cwnd 設(shè)置為第一步中的 ssthresh（原因是該 ACK 確認(rèn)了新的數(shù)據(jù)，說明從 duplicated ACK 時(shí)的數(shù)據(jù)都已收到，可以回到恢復(fù)之前的狀態(tài)，即再次進(jìn)入擁塞避免）
  

到了這里，關(guān)于TCP如何保證傳輸可靠性？的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！