TCP 報文段結(jié)構(gòu)

在簡單聊了聊 TCP 連接后，下面我們就來聊一下 TCP 的報文段結(jié)構(gòu)，如下圖所示

TCP 報文段結(jié)構(gòu)相比 UDP 報文結(jié)構(gòu)多了很多內(nèi)容。但是前兩個 32 比特的字段是一樣的。它們是?源端口號?和?目標(biāo)端口號，我們知道，這兩個字段是用于多路復(fù)用和多路分解的。另外，和 UDP 一樣，TCP 也包含校驗和(checksum field)?，除此之外，TCP 報文段首部還有下面這些

• 32 比特的序號字段(sequence number field)?和 32 比特的確認(rèn)號字段(acknowledgment number field)?。這些字段被 TCP 發(fā)送方和接收方用來實現(xiàn)可靠的數(shù)據(jù)傳輸。

• 4 比特的首部字段長度字段(header length field)，這個字段指示了以 32 比特的字為單位的 TCP 首部長度。TCP 首部的長度是可變的，但是通常情況下，選項字段為空，所以 TCP 首部字段的長度是 20 字節(jié)。

• 16 比特的?接受窗口字段(receive window field)?，這個字段用于流量控制。它用于指示接收方能夠/愿意接受的字節(jié)數(shù)量

• 可變的選項字段(options field)，這個字段用于發(fā)送方和接收方協(xié)商最大報文長度，也就是 MSS 時使用

• 6 比特的?標(biāo)志字段(flag field)，?ACK?標(biāo)志用于指示確認(rèn)字段中的值是有效的，這個報文段包括一個對已被成功接收報文段的確認(rèn)；RST、SYN、FIN?標(biāo)志用于連接的建立和關(guān)閉；CWR?和?ECE?用于擁塞控制；PSH?標(biāo)志用于表示立刻將數(shù)據(jù)交給上層處理；URG?標(biāo)志用來表示數(shù)據(jù)中存在需要被上層處理的?緊急?數(shù)據(jù)。緊急數(shù)據(jù)最后一個字節(jié)由 16 比特的緊急數(shù)據(jù)指針字段(urgeent data pointer field)?指出。一般情況下，PSH 和 URG 并沒有使用。

TCP 的各種功能和特點都是通過 TCP 報文結(jié)構(gòu)來體現(xiàn)的，在聊完 TCP 報文結(jié)構(gòu)之后，我們下面就來聊一下 TCP 有哪些功能及其特點了。

序號、確認(rèn)號實現(xiàn)傳輸可靠性

TCP 報文段首部中兩個最重要的字段就是?序號?和?確認(rèn)號，這兩個字段是 TCP 實現(xiàn)可靠性的基礎(chǔ)，那么你肯定好奇如何實現(xiàn)可靠性呢？要了解這一點，首先我們得先知道這兩個字段里面存了哪些內(nèi)容吧？

一個報文段的序號就是數(shù)據(jù)流的字節(jié)編號?。因為 TCP 會把數(shù)據(jù)流分割成為一段一段的字節(jié)流，因為字節(jié)流本身是有序的，所以每一段的字節(jié)編號就是標(biāo)示是哪一段的字節(jié)流。比如，主機 A 要給主機 B 發(fā)送一條數(shù)據(jù)。數(shù)據(jù)經(jīng)過應(yīng)用層產(chǎn)生后會有一串?dāng)?shù)據(jù)流，數(shù)據(jù)流會經(jīng)過 TCP 分割，分割的依據(jù)就是 MSS，假設(shè)數(shù)據(jù)是 10000 字節(jié)，MSS 是 2000 字節(jié)，那么 TCP 就會把數(shù)據(jù)拆分成 0 - 1999 , 2000 - 3999 的段，依次類推。

所以，第一個數(shù)據(jù) 0 - 1999 的首字節(jié)編號就是 0 ，2000 - 3999 的首字節(jié)編號就是 2000 。

然后，每個序號都會被填入 TCP 報文段首部的序號字段中。

至于確認(rèn)號的話，會比序號要稍微麻煩一些。這里我們先拓展下幾種通信模型。

• 單工通信：單工數(shù)據(jù)傳輸只支持?jǐn)?shù)據(jù)在一個方向上傳輸；在同一時間只有一方能接受或發(fā)送信息，不能實現(xiàn)雙向通信，比如廣播、電視等。

• 雙工通信是一種點對點系統(tǒng)，由兩個或者多個在兩個方向上相互通信的連接方或者設(shè)備組成。雙工通信模型有兩種：全雙工(FDX)和半雙工(HDX)

• 全雙工：在全雙工系統(tǒng)中，連接雙方可以相互通信，一個最常見的例子就是電話通信。全雙工通信是兩個單工通信方式的結(jié)合，它要求發(fā)送設(shè)備和接收設(shè)備都有獨立的接收和發(fā)送能力。

• 半雙工：在半雙工系統(tǒng)中，連接雙方可以彼此通信，但不能同時通信，比如對講機，只有把按鈕按住的人才能夠講話，只有一個人講完話后另外一個人才能講話。

單工、半雙工、全雙工通信如下圖所示

TCP 是一種全雙工的通信協(xié)議，因此主機 A 在向主機 B 發(fā)送消息的過程中，也在接受來自主機 B 的數(shù)據(jù)。主機 A 填充進(jìn)報文段的確認(rèn)號是期望從主機 B 收到的下一字節(jié)的序號。稍微有點繞，我們來舉個例子看一下。比如主機 A 收到了來自主機 B 發(fā)送的編號為 0 - 999 字節(jié)的報文段，這個報文段會寫入序號中，隨后主機 A 期望能夠從主機 B 收到 1000 - 剩下的報文段，因此，主機 A 發(fā)送到主機 B 的報文段中，它的確認(rèn)號就是 1000 。

累積確認(rèn)

這里再舉出一個例子，比如主機 A 在發(fā)送 0 - 999 報文段后，期望能夠接受到 1000 之后的報文段，但是主機 B 卻給主機 A 發(fā)送了一個 1500 之后的報文段，那么主機 A 是否還會繼續(xù)進(jìn)行等待呢？

答案顯然是會的，因為 TCP 只會確認(rèn)流中至第一個丟失字節(jié)為止的字節(jié)，因為 1500 雖然屬于 1000 之后的字節(jié)，但是主機 B 沒有給主機 A 發(fā)送 1000 - 1499 之間的字節(jié)，所以主機 A 會繼續(xù)等待。

在了解完序號和確認(rèn)號之后，我們下面來聊一下 TCP 的發(fā)送過程。下面是一個正常的發(fā)送過程

TCP 通過肯定的確認(rèn)應(yīng)答(ACK)?來實現(xiàn)可靠的數(shù)據(jù)傳輸，當(dāng)主機 A將數(shù)據(jù)發(fā)出之后會等待主機 B 的響應(yīng)。如果有確認(rèn)應(yīng)答(ACK)，說明數(shù)據(jù)已經(jīng)成功到達(dá)對端。反之，則數(shù)據(jù)很可能會丟失。

如下圖所示，如果在一定時間內(nèi)主機 A 沒有等到確認(rèn)應(yīng)答，則認(rèn)為主機 B 發(fā)送的報文段已經(jīng)丟失，并進(jìn)行重發(fā)。

主機 A 給主機 B 的響應(yīng)可能由于網(wǎng)絡(luò)抖動等原因無法到達(dá)，那么在經(jīng)過特定的時間間隔后，主機 A 將重新發(fā)送報文段。

主機 A 沒有收到主機 B 的響應(yīng)還可能是因為主機 B 在發(fā)送給主機 A 的過程中丟失。

如上圖所示，由主機 B 返回的確認(rèn)應(yīng)答，由于網(wǎng)絡(luò)擁堵等原因在傳送的過程中丟失，并沒有到達(dá)主機 A。主機 A 會等待一段時間，如果在這段時間內(nèi)主機 A 仍沒有等到主機 B 的響應(yīng)，那么主機 A 會重新發(fā)送報文段。

那么現(xiàn)在就存在一個問題，如果主機 A 給主機 B 發(fā)送了一個報文段后，主機 B 接受到報文段發(fā)送響應(yīng)，此刻由于網(wǎng)絡(luò)原因，這個報文段并未到達(dá)，等到一段時間后主機 A 重新發(fā)送報文段，然后此時主機 B 發(fā)送的響應(yīng)在主機 A 第二次發(fā)送后失序到達(dá)主機 A，那么主機 A 應(yīng)該如何處理呢？

TCP RFC 并未為此做任何規(guī)定，也就是說，我們可以自己決定如何處理失序到達(dá)的報文段。一般處理方式有兩種

• 接收方立刻丟棄失序的報文段

• 接收方接受失序到達(dá)的報文段，并等待后續(xù)的報文段

一般來說通常采取的做法是第二種。

傳輸控制

利用窗口控制提高速度

前面我們介紹了 TCP 是以數(shù)據(jù)段的形式進(jìn)行發(fā)送，如果經(jīng)過一段時間內(nèi)主機 A 等不到主機 B 的響應(yīng)，主機 A 就會重新發(fā)送報文段，接受到主機 B 的響應(yīng)，再會繼續(xù)發(fā)送后面的報文段，我們現(xiàn)在看到，這一問一答的形式還存在許多條件，比如響應(yīng)未收到、等待響應(yīng)等，那么對崇尚性能的互聯(lián)網(wǎng)來說，這種形式的性能應(yīng)該不會很高。

那么如何提升性能呢？

為了解決這個問題，TCP 引入了?窗口?這個概念，即使在往返時間較長、頻次很多的情況下，它也能控制網(wǎng)絡(luò)性能的下降，聽起來很牛批，那它是如何實現(xiàn)的呢？

如下圖所示

我們之前每次請求發(fā)送都是以報文段的形式進(jìn)行的，引入窗口后，每次請求都可以發(fā)送多個報文段，也就是說一個窗口可以發(fā)送多個報文段。窗口大小就是指無需等待確認(rèn)應(yīng)答就可以繼續(xù)發(fā)送報文段的最大值。

在這個窗口機制中，大量使用了?緩沖區(qū)?，通過對多個段同時進(jìn)行確認(rèn)應(yīng)答的功能。

如下圖所示，發(fā)送報文段中高亮部分即是我們提到的窗口，在窗口內(nèi)，即使沒有收到確認(rèn)應(yīng)答也可以把請求發(fā)送出去。不過，在整個窗口的確認(rèn)應(yīng)答沒有到達(dá)之前，如果部分報文段丟失，那么主機 A 將仍會重傳。為此，主機 A 需要設(shè)置緩存來保留這些需要重傳的報文段，直到收到他們的確認(rèn)應(yīng)答。

在滑動窗口以外的部分是尚未發(fā)送的報文段和已經(jīng)接受到的報文段，如果報文段已經(jīng)收到確認(rèn)則不可進(jìn)行重發(fā)，此時報文段就可以從緩沖區(qū)中清除。

在收到確認(rèn)的情況下，會將窗口滑動到確認(rèn)應(yīng)答中確認(rèn)號的位置，如上圖所示，這樣可以順序的將多個段同時發(fā)送，用以提高通信性能，這種窗口也叫做?滑動窗口(Sliding window)。

窗口控制和重發(fā)

報文段的發(fā)送和接收，必然伴隨著報文段的丟失和重發(fā)，窗口也是同樣如此，如果在窗口中報文段發(fā)送過程中出現(xiàn)丟失怎么辦？

首先我們先考慮確認(rèn)應(yīng)答沒有返回的情況。在這種情況下，主機 A 發(fā)送的報文段到達(dá)主機 B，是不需要再進(jìn)行重發(fā)的。這和單個報文段的發(fā)送不一樣，如果發(fā)送單個報文段，即使確認(rèn)應(yīng)答沒有返回，也要進(jìn)行重發(fā)。

窗口在一定程度上比較大時，即使有少部分確認(rèn)應(yīng)答的丟失，也不會重新發(fā)送報文段。

我們知道，如果在某個情況下由于發(fā)送的報文段丟失，導(dǎo)致接受主機未收到請求，或者主機返回的響應(yīng)未到達(dá)客戶端的話，會經(jīng)過一段時間重傳報文。那么在使用窗口的情況下，報文段丟失會怎么樣呢？

如下圖所示，報文段 0 - 999 丟失后，但是主機 A 并不會等待，主機 A 會繼續(xù)發(fā)送余下的報文段，主機 B 發(fā)送的確認(rèn)應(yīng)答卻一直是 1000，同一個確認(rèn)號的應(yīng)答報文會被持續(xù)不斷的返回，如果發(fā)送端主機在連續(xù) 3 次收到同一個確認(rèn)應(yīng)答后，就會將其所對應(yīng)的數(shù)據(jù)重發(fā)，這種機制要比之前提到的超時重發(fā)更加高效，這種機制也被稱為?高速重發(fā)控制。這種重發(fā)的確認(rèn)應(yīng)答也被稱為?冗余 ACK(響應(yīng))。

主機 B 在沒有接收到自己期望序列號的報文段時，會對之前收到的數(shù)據(jù)進(jìn)行確認(rèn)應(yīng)答。發(fā)送端則一旦收到某個確認(rèn)應(yīng)答后，又連續(xù)三次收到同樣的確認(rèn)應(yīng)答，那么就會認(rèn)為報文段已經(jīng)丟失。需要進(jìn)行重發(fā)。使用這種機制可以提供更為快速的重發(fā)服務(wù)。

流量控制

前面聊的是傳輸控制，下面 cxuan 再和你聊一下?流量控制。我們知道，在每個 TCP 連接的一側(cè)主機都會有一個 socket 緩沖區(qū)，緩沖區(qū)會為每個連接設(shè)置接收緩存和發(fā)送緩存，當(dāng) TCP 建立連接后，從應(yīng)用程序產(chǎn)生的數(shù)據(jù)就會到達(dá)接收方的接收緩沖區(qū)中，接收方的應(yīng)用程序并不一定會馬上讀取緩沖區(qū)的數(shù)據(jù)，它需要等待操作系統(tǒng)分配時間片。如果此時發(fā)送方的應(yīng)用程序產(chǎn)生數(shù)據(jù)過快，而接收方讀取接受緩沖區(qū)的數(shù)據(jù)相對較慢的話，那么接收方中緩沖區(qū)的數(shù)據(jù)將會溢出。

但是還好，TCP 有?流量控制服務(wù)(flow-control service)?用于消除緩沖區(qū)溢出的情況。流量控制是一個速度匹配服務(wù)，即發(fā)送方的發(fā)送速率與接受方應(yīng)用程序的讀取速率相匹配。

TCP 通過使用一個?接收窗口(receive window)?的變量來提供流量控制。接受窗口會給發(fā)送方一個指示到底還有多少可用的緩存空間。發(fā)送端會根據(jù)接收端的實際接受能力來控制發(fā)送的數(shù)據(jù)量。

接收端主機向發(fā)送端主機通知自己可以接收數(shù)據(jù)的大小，發(fā)送端會發(fā)送不超過這個限度的數(shù)據(jù)，這個大小限度就是窗口大小，還記得 TCP 的首部么，有一個接收窗口，我們上面聊的時候說這個字段用于流量控制。它用于指示接收方能夠/愿意接受的字節(jié)數(shù)量。

那么只知道這個字段用于流量控制，那么如何控制呢？

發(fā)送端主機會定期發(fā)送一個窗口探測包，這個包用于探測接收端主機是否還能夠接受數(shù)據(jù)，當(dāng)接收端的緩沖區(qū)一旦面臨數(shù)據(jù)溢出的風(fēng)險時，窗口大小的值也隨之被設(shè)置為一個更小的值通知發(fā)送端，從而控制數(shù)據(jù)發(fā)送量。

下面是一個流量控制示意圖

發(fā)送端主機根據(jù)接收端主機的窗口大小進(jìn)行流量控制。由此也可以防止發(fā)送端主機一次發(fā)送過大數(shù)據(jù)導(dǎo)致接收端主機無法處理。

如上圖所示，當(dāng)主機 B 收到報文段 2000 - 2999 之后緩沖區(qū)已滿，不得不暫時停止接收數(shù)據(jù)。然后主機 A 發(fā)送窗口探測包，窗口探測包非常小僅僅一個字節(jié)。然后主機 B 更新緩沖區(qū)接收窗口大小并發(fā)送窗口更新通知給主機 A，然后主機 A 再繼續(xù)發(fā)送報文段。

在上面的發(fā)送過程中，窗口更新通知可能會丟失，一旦丟失發(fā)送端就不會發(fā)送數(shù)據(jù)，所以窗口探測包會隨機發(fā)送，以避免這種情況發(fā)生。

連接管理

在繼續(xù)介紹下面有意思的特性之前，我們先來把關(guān)注點放在 TCP 的連接管理上，因為沒有 TCP 連接，也就沒有后續(xù)的一系列 TCP 特性什么事兒了。假設(shè)運行在一臺主機上的進(jìn)程想要和另一臺主機上的進(jìn)程建立一條 TCP 連接，那么客戶中的 TCP 會使用下面這些步驟與服務(wù)器中的 TCP 建立連接。

• 首先，客戶端首先向服務(wù)器發(fā)送一個特殊的 TCP 報文段。這個報文段首部不包含應(yīng)用層數(shù)據(jù)，但是在報文段的首部中有一個?SYN 標(biāo)志位?被置為 1。因此，這個特殊的報文段也可以叫做 SYN 報文段。然后，客戶端隨機選擇一個初始序列號(client_isn)?，并將此數(shù)字放入初始 TCP SYN 段的序列號字段中，SYN 段又被封裝在 IP 數(shù)據(jù)段中發(fā)送給服務(wù)器。

• 一旦包含 IP 數(shù)據(jù)段到達(dá)服務(wù)器后，服務(wù)端會從 IP 數(shù)據(jù)段中提取 TCP SYN 段，將 TCP 緩沖區(qū)和變量分配給連接，然后給客戶端發(fā)送一個連接所允許的報文段。這個連接所允許的報文段也不包括任何應(yīng)用層數(shù)據(jù)。然而，它卻包含了三個非常重要的信息。

這些緩沖區(qū)和變量的分配使 TCP 容易受到稱為 SYN 泛洪的拒絕服務(wù)攻擊。

• 首先，SYN 比特被置為 1 。

• 然后，TCP 報文段的首部確認(rèn)號被設(shè)置為?client_isn + 1。

• 最后，服務(wù)器選擇自己的初始序號(server_isn)，并將其放置到 TCP 報文段首部的序號字段中。

  如果用大白話解釋下就是，我收到了你發(fā)起建立連接的 SYN 報文段，這個報文段具有首部字段 client_isn。我同意建立該連接，我自己的初始序號是 server_isn。這個允許連接的報文段被稱為?SYNACK 報文段

• 第三步，在收到 SYNACK 報文段后，客戶端也要為該連接分配緩沖區(qū)和變量。客戶端主機向服務(wù)器發(fā)送另外一個報文段，最后一個報文段對服務(wù)器發(fā)送的響應(yīng)報文做了確認(rèn)，確認(rèn)的標(biāo)準(zhǔn)是客戶端發(fā)送的數(shù)據(jù)段中確認(rèn)號為 server_isn + 1，因為連接已經(jīng)建立，所以 SYN 比特被置為 0 。以上就是 TCP 建立連接的三次數(shù)據(jù)段發(fā)送過程，也被稱為?三次握手。

一旦完成這三個步驟，客戶和服務(wù)器主機就可以相互發(fā)送報文段了，在以后的每一個報文段中，SYN 比特都被置為 0 ，整個過程描述如下圖所示

在客戶端主機和服務(wù)端主機建立連接后，參與一條 TCP 連接的兩個進(jìn)程中的任何一個都能終止 TCP 連接。連接結(jié)束后，主機中的緩存和變量將會被釋放。假設(shè)客戶端主機想要終止 TCP 連接，它會經(jīng)歷如下過程

客戶應(yīng)用進(jìn)程發(fā)出一個關(guān)閉命令，客戶 TCP 向服務(wù)器進(jìn)程發(fā)送一個特殊的 TCP 報文段，這個特殊的報文段的首部標(biāo)志 FIN 被設(shè)置為 1 。當(dāng)服務(wù)器收到這個報文段后，就會向發(fā)送方發(fā)送一個確認(rèn)報文段。然后，服務(wù)器發(fā)送它自己的終止報文段，F(xiàn)IN 位被設(shè)置為 1 。客戶端對這個終止報文段進(jìn)行確認(rèn)。此時，在兩臺主機上用于該連接的所有資源都被釋放了，如下圖所示

在一個 TCP 連接的生命周期內(nèi)，運行在每臺主機中的 TCP 協(xié)議都會在各種?TCP 狀態(tài)(TCP State)?之間進(jìn)行變化，TCP 的狀態(tài)主要有?LISTEN、SYN-SEND、SYN-RECEIVED、ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT 和 CLOSED?。這些狀態(tài)的解釋如下

• LISTEN: 表示等待任何來自遠(yuǎn)程 TCP 和端口的連接請求。

• SYN-SEND: 表示發(fā)送連接請求后等待匹配的連接請求。

• SYN-RECEIVED: 表示已接收并發(fā)送連接請求后等待連接確認(rèn)，也就是 TCP 三次握手中第二步后服務(wù)端的狀態(tài)

• ESTABLISHED: 表示已經(jīng)連接已經(jīng)建立，可以將應(yīng)用數(shù)據(jù)發(fā)送給其他主機

上面這四種狀態(tài)是 TCP 三次握手所涉及的。

• FIN-WAIT-1: 表示等待來自遠(yuǎn)程 TCP 的連接終止請求，或者等待先前發(fā)送的連接終止請求的確認(rèn)。

• FIN-WAIT-2: 表示等待來自遠(yuǎn)程 TCP 的連接終止請求。

• CLOSE-WAIT: 表示等待本地用戶的連接終止請求。

• CLOSING: 表示等待來自遠(yuǎn)程 TCP 的連接終止請求確認(rèn)。

• LAST-ACK: 表示等待先前發(fā)送給遠(yuǎn)程 TCP 的連接終止請求的確認(rèn)（包括對它的連接終止請求的確認(rèn)）。

• TIME-WAIT: 表示等待足夠的時間以確保遠(yuǎn)程 TCP 收到其連接終止請求的確認(rèn)。

• CLOSED: 表示連接已經(jīng)關(guān)閉，無連接狀態(tài)。

上面 7 種狀態(tài)是 TCP 四次揮手，也就是斷開鏈接所設(shè)計的。

TCP 的連接狀態(tài)會進(jìn)行各種切換，這些 TCP 連接的切換是根據(jù)事件進(jìn)行的，這些事件由用戶調(diào)用：OPEN、SEND、RECEIVE、CLOSE、ABORT 和 STATUS。涉及到 TCP 報文段的標(biāo)志有?SYN、ACK、RST 和 FIN?，當(dāng)然，還有超時。

我們下面加上 TCP 連接狀態(tài)后，再來看一下三次握手和四次揮手的過程。

三次握手建立連接

下圖畫出了 TCP 連接建立的過程。假設(shè)圖中左端是客戶端主機，右端是服務(wù)端主機，一開始，兩端都處于CLOSED（關(guān)閉）狀態(tài)。

1. 服務(wù)端進(jìn)程準(zhǔn)備好接收來自外部的 TCP 連接，一般情況下是調(diào)用 bind、listen、socket 三個函數(shù)完成。這種打開方式被認(rèn)為是?被動打開(passive open)。然后服務(wù)端進(jìn)程處于?LISTEN?狀態(tài)，等待客戶端連接請求。

2. 客戶端通過?connect?發(fā)起主動打開(active open)，向服務(wù)器發(fā)出連接請求，請求中首部同步位 SYN = 1，同時選擇一個初始序號 sequence ，簡寫 seq = x。SYN 報文段不允許攜帶數(shù)據(jù)，只消耗一個序號。此時，客戶端進(jìn)入?SYN-SEND?狀態(tài)。

3. 服務(wù)器收到客戶端連接后，，需要確認(rèn)客戶端的報文段。在確認(rèn)報文段中，把 SYN 和 ACK 位都置為 1 。確認(rèn)號是 ack = x + 1，同時也為自己選擇一個初始序號 seq = y。請注意，這個報文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個序號。此時，TCP 服務(wù)器進(jìn)入?SYN-RECEIVED(同步收到)?狀態(tài)。

4. 客戶端在收到服務(wù)器發(fā)出的響應(yīng)后，還需要給出確認(rèn)連接。確認(rèn)連接中的 ACK 置為 1 ，序號為 seq = x + 1，確認(rèn)號為 ack = y + 1。TCP 規(guī)定，這個報文段可以攜帶數(shù)據(jù)也可以不攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)，那么下一個數(shù)據(jù)報文段的序號仍是 seq = x + 1。這時，客戶端進(jìn)入?ESTABLISHED (已連接)?狀態(tài)

5. 服務(wù)器收到客戶的確認(rèn)后，也進(jìn)入?ESTABLISHED?狀態(tài)。

TCP 建立一個連接需要三個報文段，釋放一個連接卻需要四個報文段。

四次揮手

數(shù)據(jù)傳輸結(jié)束后，通信的雙方可以釋放連接。數(shù)據(jù)傳輸結(jié)束后的客戶端主機和服務(wù)端主機都處于 ESTABLISHED 狀態(tài)，然后進(jìn)入釋放連接的過程。

TCP 斷開連接需要歷經(jīng)的過程如下

1. 客戶端應(yīng)用程序發(fā)出釋放連接的報文段，并停止發(fā)送數(shù)據(jù)，主動關(guān)閉 TCP 連接?？蛻舳酥鳈C發(fā)送釋放連接的報文段，報文段中首部 FIN 位置為 1 ，不包含數(shù)據(jù)，序列號位 seq = u，此時客戶端主機進(jìn)入?FIN-WAIT-1(終止等待 1)?階段。

2. 服務(wù)器主機接受到客戶端發(fā)出的報文段后，即發(fā)出確認(rèn)應(yīng)答報文，確認(rèn)應(yīng)答報文中 ACK = 1，生成自己的序號位 seq = v，ack = u + 1，然后服務(wù)器主機就進(jìn)入?CLOSE-WAIT(關(guān)閉等待)?狀態(tài)，這個時候客戶端主機 -> 服務(wù)器主機這條方向的連接就釋放了，客戶端主機沒有數(shù)據(jù)需要發(fā)送，此時服務(wù)器主機是一種半連接的狀態(tài)，但是服務(wù)器主機仍然可以發(fā)送數(shù)據(jù)。

3. 客戶端主機收到服務(wù)端主機的確認(rèn)應(yīng)答后，即進(jìn)入?FIN-WAIT-2(終止等待2)?的狀態(tài)。等待客戶端發(fā)出連接釋放的報文段。

4. 當(dāng)服務(wù)器主機沒有數(shù)據(jù)發(fā)送后，應(yīng)用進(jìn)程就會通知 TCP 釋放連接。這時服務(wù)端主機會發(fā)出斷開連接的報文段，報文段中 ACK = 1，序列號 seq = w，因為在這之間可能已經(jīng)發(fā)送了一些數(shù)據(jù)，所以 seq 不一定等于 v + 1。ack = u + 1，在發(fā)送完斷開請求的報文后，服務(wù)端主機就進(jìn)入了?LAST-ACK(最后確認(rèn))的階段。

5. 客戶端收到服務(wù)端的斷開連接請求后，客戶端需要作出響應(yīng)，客戶端發(fā)出斷開連接的報文段，在報文段中，ACK = 1, 序列號 seq = u + 1，因為客戶端從連接開始斷開后就沒有再發(fā)送數(shù)據(jù)，ack = w + 1，然后進(jìn)入到?TIME-WAIT(時間等待)?狀態(tài)，請注意，這個時候 TCP 連接還沒有釋放。必須經(jīng)過時間等待的設(shè)置，也就是?2MSL?后，客戶端才會進(jìn)入?CLOSED?狀態(tài)，時間 MSL 叫做最長報文段壽命（Maximum Segment Lifetime）。

6. 服務(wù)端主要收到了客戶端的斷開連接確認(rèn)后，就會進(jìn)入 CLOSED 狀態(tài)。因為服務(wù)端結(jié)束 TCP 連接時間要比客戶端早，而整個連接斷開過程需要發(fā)送四個報文段，因此釋放連接的過程也被稱為四次揮手。

什么是 TIME-WAIT

我上面只是簡單提到了一下 TIME-WAIT 狀態(tài)和 2MSL 是啥，下面來聊一下這兩個概念。

MSL?是 TCP 報文段可以存活或者駐留在網(wǎng)絡(luò)中的最長時間。RFC 793 定義了 MSL 的時間是兩分鐘，但是具體的實現(xiàn)還要根據(jù)程序員來指定，一些實現(xiàn)采用了 30 秒的這個最大存活時間。

那么為什么要等待?2MSL?呢？

主要是因為兩個理由

• 為了保證最后一個響應(yīng)能夠到達(dá)服務(wù)器，因為在計算機網(wǎng)絡(luò)中，最后一個 ACK 報文段可能會丟失，從而致使客戶端一直處于?LAST-ACK?狀態(tài)等待客戶端響應(yīng)。這時候服務(wù)器會重傳一次?FINACK?斷開連接報文，客戶端接收后再重新確認(rèn)，重啟定時器。如果客戶端不是 2MSL ，在客戶端發(fā)送 ACK 后直接關(guān)閉的話，如果報文丟失，那么雙方主機會無法進(jìn)入 CLOSED 狀態(tài)。

• 還可以防止已失效的報文段?？蛻舳嗽诎l(fā)送最后一個 ACK 之后，再經(jīng)過經(jīng)過 2MSL，就可以使本鏈接持續(xù)時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。從而保證在關(guān)閉連接后不會有還在網(wǎng)絡(luò)中滯留的報文段去騷擾服務(wù)器。

這里注意一點：在服務(wù)器發(fā)送了 FIN-ACK 之后，會立即啟動超時重傳計時器。客戶端在發(fā)送最后一個 ACK 之后會立即啟動時間等待計時器。

說好的 RST 呢

說好的?RST、SYN、FIN?標(biāo)志用于連接的建立和關(guān)閉，那么 SYN 和 FIN 都現(xiàn)身了，那 RST 呢？也是啊，我們上面探討的都是一種理想的情況，就是客戶端服務(wù)器雙方都會接受傳輸報文段的情況，還有一種情況是當(dāng)主機收到 TCP 報文段后，其 IP 和端口號不匹配的情況。假設(shè)客戶端主機發(fā)送一個請求，而服務(wù)器主機經(jīng)過 IP 和端口號的判斷后發(fā)現(xiàn)不是給這個服務(wù)器的，那么服務(wù)器就會發(fā)出一個?RST?特殊報文段給客戶端。

因此，當(dāng)服務(wù)端發(fā)送一個 RST 特殊報文段給客戶端的時候，它就會告訴客戶端沒有匹配的套接字連接，請不要再繼續(xù)發(fā)送了。

上面探討的是 TCP 的情況，那么 UDP 呢？

使用 UDP 作為傳輸協(xié)議后，如果套接字不匹配的話，UDP 主機就會發(fā)送一個特殊的 ICMP 數(shù)據(jù)報。

SYN 洪泛攻擊

下面我們來討論一下什么是?SYN 洪泛攻擊。

我們在 TCP 的三次握手中已經(jīng)看到，服務(wù)器為了響應(yīng)一個收到的 SYN，分配并初始化變量連接和緩存，然后服務(wù)器發(fā)送一個 SYNACK 作為響應(yīng)，然后等待來自于客戶端的 ACK 報文。如果客戶端不發(fā)送 ACK 來完成最后一步的話，那么這個連接就處在一個掛起的狀態(tài)，也就是半連接狀態(tài)。

攻擊者通常在這種情況下發(fā)送大量的 TCP SYN 報文段，服務(wù)端繼續(xù)響應(yīng)，但是每個連接都完不成三次握手的步驟。隨著 SYN 的不斷增加，服務(wù)器會不斷的為這些半開連接分配資源，導(dǎo)致服務(wù)器的連接最終被消耗殆盡。這種攻擊也是屬于?Dos?攻擊的一種。

抵御這種攻擊的方式是使用?SYN cookie?，下面是它的工作流程介紹

• 當(dāng)服務(wù)器收到一個 SYN 報文段時，它并不知道這個報文段是來自哪里，是來自攻擊者主機還是客戶端主機(雖然攻擊者也是客戶端，不過這么說更便于區(qū)分) 。因此服務(wù)器不會為報文段生成一個半開連接。與此相反，服務(wù)器生成一個初始的 TCP 序列號，這個序列號是 SYN 報文段的源和目的 IP 地址與端口號這個四元組構(gòu)造的一個復(fù)雜的散列函數(shù)，這個散列函數(shù)生成的 TCP 序列號就是?SYN Cookie，用于緩存 SYN 請求。然后，服務(wù)器會發(fā)送帶著 SYN Cookie 的 SYNACK 分組。有一點需要注意的是，服務(wù)器不會記憶這個 Cookie 或 SYN 的其他狀態(tài)信息。

• 如果客戶端不是攻擊者的話，它就會返回一個 ACK 報文段。當(dāng)服務(wù)器收到這個 ACK 后，需要驗證這個 ACK 與 SYN 發(fā)送的是否相同，驗證的標(biāo)準(zhǔn)就是確認(rèn)字段中的確認(rèn)號和序列號，源和目的 IP 地址與端口號以及和散列函數(shù)的是否一致，散列函數(shù)的結(jié)果 + 1 是否和 SYNACK 中的確認(rèn)值相同。(大致是這樣，說的不對還請讀者糾正) 。如果有興趣讀者可以自行深入了解。如果是合法的，服務(wù)器就會生成一個具有套接字的全開連接。

• 如果客戶端沒有返回 ACK，即認(rèn)為是攻擊者，那么這樣也沒關(guān)系，服務(wù)器沒有收到 ACK，不會分配變量和緩存資源，不會對服務(wù)器產(chǎn)生危害。

擁塞控制

有了 TCP 的窗口控制后，使計算機網(wǎng)絡(luò)中兩個主機之間不再是以單個數(shù)據(jù)段的形式發(fā)送了，而是能夠連續(xù)發(fā)送大量的數(shù)據(jù)包。然而，大量數(shù)據(jù)包同時也伴隨著其他問題，比如網(wǎng)絡(luò)負(fù)載、網(wǎng)絡(luò)擁堵等問題。TCP 為了防止這類問題的出現(xiàn)，使用了?擁塞控制?機制，擁塞控制機制會在面臨網(wǎng)絡(luò)擁塞時遏制發(fā)送方的數(shù)據(jù)發(fā)送。

擁塞控制主要有兩種方法

• 端到端的擁塞控制: 因為網(wǎng)絡(luò)層沒有為運輸層擁塞控制提供顯示支持。所以即使網(wǎng)絡(luò)中存在擁塞情況，端系統(tǒng)也要通過對網(wǎng)絡(luò)行為的觀察來推斷。TCP 就是使用了端到端的擁塞控制方式。IP 層不會向端系統(tǒng)提供有關(guān)網(wǎng)絡(luò)擁塞的反饋信息。那么 TCP 如何推斷網(wǎng)絡(luò)擁塞呢？如果超時或者三次冗余確認(rèn)就被認(rèn)為是網(wǎng)絡(luò)擁塞，TCP 會減小窗口的大小，或者增加往返時延來避免。

• 網(wǎng)絡(luò)輔助的擁塞控制: 在網(wǎng)絡(luò)輔助的擁塞控制中，路由器會向發(fā)送方提供關(guān)于網(wǎng)絡(luò)中擁塞狀態(tài)的反饋。這種反饋信息就是一個比特信息，它指示鏈路中的擁塞情況。

下圖描述了這兩種擁塞控制方式

TCP 擁塞控制

如果你看到這里，那我就暫定認(rèn)為你了解了 TCP 實現(xiàn)可靠性的基礎(chǔ)了，那就是使用序號和確認(rèn)號。除此之外，另外一個實現(xiàn) TCP 可靠性基礎(chǔ)的就是 TCP 的擁塞控制。如果說

TCP 所采用的方法是讓每一個發(fā)送方根據(jù)所感知到的網(wǎng)絡(luò)的擁塞程度來限制發(fā)出報文段的速率，如果 TCP 發(fā)送方感知到?jīng)]有什么擁塞，則 TCP 發(fā)送方會增加發(fā)送速率；如果發(fā)送方感知沿著路徑有阻塞，那么發(fā)送方就會降低發(fā)送速率。

但是這種方法有三個問題

1. TCP 發(fā)送方如何限制它向其他連接發(fā)送報文段的速率呢？

2. 一個 TCP 發(fā)送方是如何感知到網(wǎng)絡(luò)擁塞的呢？

3. 當(dāng)發(fā)送方感知到端到端的擁塞時，采用何種算法來改變其發(fā)送速率呢？

我們先來探討一下第一個問題，TCP 發(fā)送方如何限制它向其他連接發(fā)送報文段的速率呢？

我們知道 TCP 是由接收緩存、發(fā)送緩存和變量(LastByteRead, rwnd，等)組成。發(fā)送方的 TCP 擁塞控制機制會跟蹤一個變量，即?擁塞窗口(congestion window)?的變量，擁塞窗口表示為?cwnd，用于限制 TCP 在接收到 ACK 之前可以發(fā)送到網(wǎng)絡(luò)的數(shù)據(jù)量。而接收窗口(rwnd)?是一個用于告訴接收方能夠接受的數(shù)據(jù)量。

一般來說，發(fā)送方未確認(rèn)的數(shù)據(jù)量不得超過 cwnd 和 rwnd 的最小值，也就是

LastByteSent - LastByteAcked <= min(cwnd,rwnd)

由于每個數(shù)據(jù)包的往返時間是 RTT，我們假設(shè)接收端有足夠的緩存空間用于接收數(shù)據(jù)，我們就不用考慮 rwnd 了，只專注于 cwnd，那么，該發(fā)送方的發(fā)送速率大概是?cwnd/RTT 字節(jié)/秒?。通過調(diào)節(jié) cwnd，發(fā)送方因此能調(diào)整它向連接發(fā)送數(shù)據(jù)的速率。

一個 TCP 發(fā)送方是如何感知到網(wǎng)絡(luò)擁塞的呢？

這個我們上面討論過，是 TCP 根據(jù)超時或者 3 個冗余 ACK 來感知的。

當(dāng)發(fā)送方感知到端到端的擁塞時，采用何種算法來改變其發(fā)送速率呢??

這個問題比較復(fù)雜，且容我娓娓道來，一般來說，TCP 會遵循下面這幾種指導(dǎo)性原則

• 如果在報文段發(fā)送過程中丟失，那就意味著網(wǎng)絡(luò)擁堵，此時需要適當(dāng)降低 TCP 發(fā)送方的速率。

• 一個確認(rèn)報文段指示發(fā)送方正在向接收方傳遞報文段，因此，當(dāng)對先前未確認(rèn)報文段的確認(rèn)到達(dá)時，能夠增加發(fā)送方的速率。為啥呢？因為未確認(rèn)的報文段到達(dá)接收方也就表示著網(wǎng)絡(luò)不擁堵，能夠順利到達(dá)，因此發(fā)送方擁塞窗口長度會變大，所以發(fā)送速率會變快

• 帶寬探測，帶寬探測說的是 TCP 可以通過調(diào)節(jié)傳輸速率來增加/減小 ACK 到達(dá)的次數(shù)，如果出現(xiàn)丟包事件，就會減小傳輸速率。因此，為了探測擁塞開始出現(xiàn)的頻率， TCP 發(fā)送方應(yīng)該增加它的傳輸速率。然后慢慢使傳輸速率降低，進(jìn)而再次開始探測，看看擁塞開始速率是否發(fā)生了變化。

在了解完 TCP 擁塞控制后，下面我們就該聊一下 TCP 的?擁塞控制算法(TCP congestion control algorithm)?了。TCP 擁塞控制算法主要包含三個部分：慢啟動、擁塞避免、快速恢復(fù)，下面我們依次來看一下

慢啟動

當(dāng)一條 TCP 開始建立連接時，cwnd 的值就會初始化為一個 MSS 的較小值。這就使得初始發(fā)送速率大概是?MSS/RTT 字節(jié)/秒?，比如要傳輸 1000 字節(jié)的數(shù)據(jù)，RTT 為 200 ms ，那么得到的初始發(fā)送速率大概是 40 kb/s 。實際情況下可用帶寬要比這個 MSS/RTT 大得多，因此 TCP 想要找到最佳的發(fā)送速率，可以通過?慢啟動(slow-start)?的方式，在慢啟動的方式中，cwnd 的值會初始化為 1 個 MSS，并且每次傳輸報文確認(rèn)后就會增加一個 MSS，cwnd 的值會變?yōu)?2 個 MSS，這兩個報文段都傳輸成功后每個報文段 + 1，會變?yōu)?4 個 MSS，依此類推，每成功一次 cwnd 的值就會翻倍。如下圖所示

發(fā)送速率不可能會一直增長，增長總有結(jié)束的時候，那么何時結(jié)束呢？慢啟動通常會使用下面這幾種方式結(jié)束發(fā)送速率的增長。

• 如果在慢啟動的發(fā)送過程出現(xiàn)丟包的情況，那么 TCP 會將發(fā)送方的 cwnd 設(shè)置為 1 并重新開始慢啟動的過程，此時會引入一個?ssthresh(慢啟動閾值)?的概念，它的初始值就是產(chǎn)生丟包的 cwnd 的值 / 2，即當(dāng)檢測到擁塞時，ssthresh 的值就是窗口值的一半。

• 第二種方式是直接和 ssthresh 的值相關(guān)聯(lián)，因為當(dāng)檢測到擁塞時，ssthresh 的值就是窗口值的一半，那么當(dāng) cwnd > ssthresh 時，每次翻番都可能會出現(xiàn)丟包，所以最好的方式就是 cwnd 的值 = ssthresh ，這樣 TCP 就會轉(zhuǎn)為擁塞控制模式，結(jié)束慢啟動。

• 慢啟動結(jié)束的最后一種方式就是如果檢測到 3 個冗余 ACK，TCP 就會執(zhí)行一種快速重傳并進(jìn)入恢復(fù)狀態(tài)。

擁塞避免

當(dāng) TCP 進(jìn)入擁塞控制狀態(tài)后，cwnd 的值就等于擁塞時值的一半，也就是 ssthresh 的值。所以，無法每次報文段到達(dá)后都將 cwnd 的值再翻倍。而是采用了一種相對保守的方式，每次傳輸完成后只將 cwnd 的值增加一個 MSS，比如收到了 10 個報文段的確認(rèn)，但是 cwnd 的值只增加一個 MSS。這是一種線性增長模式，它也會有增長逾值，它的增長逾值和慢啟動一樣，如果出現(xiàn)丟包，那么 cwnd 的值就是一個 MSS，ssthresh 的值就等于 cwnd 的一半；或者是收到 3 個冗余的 ACK 響應(yīng)也能停止 MSS 增長。如果 TCP 將 cwnd 的值減半后，仍然會收到 3 個冗余 ACK，那么就會將 ssthresh 的值記錄為 cwnd 值的一半，進(jìn)入?快速恢復(fù)?狀態(tài)。

快速恢復(fù)

在快速恢復(fù)中，對于使 TCP 進(jìn)入快速恢復(fù)狀態(tài)缺失的報文段，對于每個收到的冗余 ACK，cwnd 的值都會增加一個 MSS 。當(dāng)對丟失報文段的一個 ACK 到達(dá)時，TCP 在降低 cwnd 后進(jìn)入擁塞避免狀態(tài)。如果在擁塞控制狀態(tài)后出現(xiàn)超時，那么就會遷移到慢啟動狀態(tài)，cwnd 的值被設(shè)置為 1 個 MSS，ssthresh 的值設(shè)置為 cwnd 的一半。

如果你能用心看到這里，我相信你定會有所收獲。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝