[[394208]]

之前的文章一直在聊各種網(wǎng)絡(luò)協(xié)議，那么從這篇文章開始，我就會和你聊一聊關(guān)于 TCP 協(xié)議的種種特征，比如 TCP 連接管理(也是這篇文章主要討論的)、TCP 超時和重傳、TCP 擁塞控制、TCP 數(shù)據(jù)流和窗口管理。

TCP 是一種面向連接的單播協(xié)議，在 TCP 中，并不存在多播、廣播的這種行為，因為 TCP 報文段中能明確發(fā)送方和接受方的 IP 地址。

在發(fā)送數(shù)據(jù)前，相互通信的雙方(即發(fā)送方和接受方)需要建立一條連接，在發(fā)送數(shù)據(jù)后，通信雙方需要斷開連接，這就是 TCP 連接的建立和終止。

TCP 連接的建立和終止

如果你看過我之前寫的關(guān)于網(wǎng)絡(luò)層的一篇文章，你應(yīng)該知道 TCP 的基本元素有四個：即發(fā)送方的 IP 地址、發(fā)送方的端口號、接收方的 IP 地址、接收方的端口號。而每一方的 IP + 端口號都可以看作是一個套接字，套接字能夠被唯一標示。套接字就相當(dāng)于是門，出了這個門，就要進行數(shù)據(jù)傳輸了。

TCP 的連接建立 -> 終止總共分為三個階段

下面我們所討論的重點也是集中在這三個層面。

下圖是一個非常典型的 TCP 連接的建立和關(guān)閉過程，其中不包括數(shù)據(jù)傳輸?shù)牟糠帧?/p>

TCP 建立連接 - 三次握手

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

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

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

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

服務(wù)器收到客戶的確認后，也進入 ESTABLISHED 狀態(tài)。

這是一個典型的三次握手過程，通過上面 3 個報文段就能夠完成一個 TCP 連接的建立。三次握手的的目的不僅僅在于讓通信雙方知曉正在建立一個連接，也在于利用數(shù)據(jù)包中的選項字段來交換一些特殊信息，交換初始序列號。

一般首個發(fā)送 SYN 報文的一方被認為是主動打開一個連接，而這一方通常也被稱為客戶端。而 SYN 的接收方通常被稱為服務(wù)端，它用于接收這個 SYN，并發(fā)送下面的 SYN，因此這種打開方式是被動打開。

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

TCP 斷開連接 - 四次揮手數(shù)據(jù)

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

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

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

服務(wù)器主機接受到客戶端發(fā)出的報文段后，即發(fā)出確認應(yīng)答報文，確認應(yīng)答報文中 ACK = 1，生成自己的序號位 seq = v，ack = u + 1，然后服務(wù)器主機就進入 CLOSE-WAIT(關(guān)閉等待) 狀態(tài)。

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

這時服務(wù)端主機會發(fā)出斷開連接的報文段，報文段中 ACK = 1，序列號 seq = v，ack = u + 1，在發(fā)送完斷開請求的報文后，服務(wù)端主機就進入了 LAST-ACK(最后確認)的階段。

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

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

TCP 連接的任意一方都可以發(fā)起關(guān)閉操作，只不過通常情況下發(fā)起關(guān)閉連接操作一般都是客戶端。然而，一些服務(wù)器比如 Web 服務(wù)器在對請求作出相應(yīng)后也會發(fā)起關(guān)閉連接的操作。TCP 協(xié)議規(guī)定通過發(fā)送一個 FIN 報文來發(fā)起關(guān)閉操作。

所以綜上所述，建立一個 TCP 連接需要三個報文段，而關(guān)閉一個 TCP 連接需要四個報文段。TCP 協(xié)議還支持一種半開啟(half-open) 狀態(tài)，雖然這種情況并不多見。

TCP 半開啟

TCP 連接處于半開啟的這種狀態(tài)是因為連接的一方關(guān)閉或者終止了這個 TCP 連接卻沒有通知另一方，也就是說兩個人正在微信聊天，cxuan 你下線了你不告訴我，我還在跟你侃八卦呢。此時就認為這條連接處于半開啟狀態(tài)。這種情況發(fā)生在通信中的一方處于主機崩潰的情況下，你 xxx 的，我電腦死機了我咋告訴你?只要處于半連接狀態(tài)的一方不傳輸數(shù)據(jù)的話，那么是無法檢測出來對方主機已經(jīng)下線的。

另外一種處于半開啟狀態(tài)的原因是通信的一方關(guān)閉了主機電源 而不是正常關(guān)機。這種情況下會導(dǎo)致服務(wù)器上有很多半開啟的 TCP 連接。

TCP 半關(guān)閉

既然 TCP 支持半開啟操作，那么我們可以設(shè)想 TCP 也支持半關(guān)閉操作。同樣的，TCP 半關(guān)閉也并不常見。TCP 的半關(guān)閉操作是指僅僅關(guān)閉數(shù)據(jù)流的一個傳輸方向。兩個半關(guān)閉操作合在一起就能夠關(guān)閉整個連接。在一般情況下，通信雙方會通過應(yīng)用程序互相發(fā)送 FIN 報文段來結(jié)束連接，但是在 TCP 半關(guān)閉的情況下，應(yīng)用程序會表明自己的想法："我已經(jīng)完成了數(shù)據(jù)的發(fā)送發(fā)送，并發(fā)送了一個 FIN 報文段給對方，但是我依然希望接收來自對方的數(shù)據(jù)直到它發(fā)送一個 FIN 報文段給我"。下面是一個 TCP 半關(guān)閉的示意圖。

解釋一下這個過程：

首先客戶端主機和服務(wù)器主機一直在進行數(shù)據(jù)傳輸，一段時間后，客戶端發(fā)起了 FIN 報文，要求主動斷開連接，服務(wù)器收到 FIN 后，回應(yīng) ACK ，由于此時發(fā)起半關(guān)閉的一方也就是客戶端仍然希望服務(wù)器發(fā)送數(shù)據(jù)，所以服務(wù)器會繼續(xù)發(fā)送數(shù)據(jù)，一段時間后服務(wù)器發(fā)送另外一條 FIN 報文，在客戶端收到 FIN 報文回應(yīng) ACK 給服務(wù)器后，斷開連接。

TCP 的半關(guān)閉操作中，連接的一個方向被關(guān)閉，而另一個方向仍在傳輸數(shù)據(jù)直到它被關(guān)閉為止。只不過很少有應(yīng)用程序使用這一特性。

同時打開和同時關(guān)閉

還有一種比較非常規(guī)的操作，這就是兩個應(yīng)用程序同時主動打開連接。雖然這種情況看起來不太可能，但是在特定的安排下卻是有可能發(fā)生的。我們主要講述這個過程。

通信雙方在接收到來自對方的 SYN 之前會首先發(fā)送一個 SYN，這個場景還要求通信雙方都知道對方的 IP 地址 + 端口號。

比如戀愛中的一對男女，他倆都同時說出了我愛你這個神圣的誓言，然后他倆對彼此的響應(yīng)進行么么噠，這就是同時打開。

下面是同時打開的例子

如上圖所示，通信雙方都在收到對方報文前主動發(fā)送了 SYN 報文，都在收到彼此的報文后回復(fù)了一個 ACK 報文。

一個同時打開過程需要交換四個報文段，比普通的三次握手增加了一個，由于同時打開沒有客戶端和服務(wù)器一說，所以這里我用了通信雙方來稱呼。

像同時打開一樣，同時關(guān)閉也是通信雙方同時提出主動關(guān)閉請求，發(fā)送 FIN 報文，下圖顯示了一個同時關(guān)閉的過程。

同時關(guān)閉過程中需要交換和正常關(guān)閉相同數(shù)量的報文段，只不過同時關(guān)閉不像四次揮手那樣順序進行，而是交叉進行的。

聊一聊初始序列號

也許是我上面圖示或者文字描述的不專業(yè)，初始序列號它是有專業(yè)術(shù)語表示的，初始序列號的英文名稱是Initial sequence numbers (ISN)，所以我們上面表示的 seq = v，其實就表示的 ISN。

在發(fā)送 SYN 之前，通信雙方會選擇一個初始序列號。初始序列號是隨機生成的，每一個 TCP 連接都會有一個不同的初始序列號。RFC 文檔指出初始序列號是一個 32 位的計數(shù)器，每 4 us(微秒) + 1。因為每個 TCP 連接都是一個不同的實例，這么安排的目的就是為了防止出現(xiàn)序列號重疊的情況。

當(dāng)一個 TCP 連接建立的過程中，只有正確的 TCP 四元組和正確的序列號才會被對方接收。這也反應(yīng)了 TCP 報文段容易被偽造 的脆弱性，因為只要我偽造了一個相同的四元組和初始序列號就能夠偽造 TCP 連接，從而打斷 TCP 的正常連接，所以抵御這種攻擊的一種方式就是使用初始序列號，另外一種方法就是加密序列號。

TCP 狀態(tài)轉(zhuǎn)換

我們上面聊到了三次握手和四次揮手，提到了一些關(guān)于 TCP 連接之間的狀態(tài)轉(zhuǎn)換，那么下面我就從頭開始和你好好梳理一下這些狀態(tài)之間的轉(zhuǎn)換。

首先第一步，剛開始時服務(wù)器和客戶端都處于 CLOSED 狀態(tài)，這時需要判斷是主動打開還是被動打開，如果是主動打開，那么客戶端向服務(wù)器發(fā)送 SYN 報文，此時客戶端處于 SYN-SEND 狀態(tài)，SYN-SEND 表示發(fā)送連接請求后等待匹配的連接請求，服務(wù)器被動打開會處于 LISTEN 狀態(tài)，用于監(jiān)聽 SYN 報文。如果客戶端調(diào)用了 close 方法或者經(jīng)過一段時間沒有操作，就會重新變?yōu)?CLOSED 狀態(tài)，這一步轉(zhuǎn)換圖如下

這里有個疑問，為什么處于 LISTEN 狀態(tài)下的客戶端還會發(fā)送 SYN 變?yōu)?SYN_SENT 狀態(tài)呢?

知乎看到了車小胖大佬的回答，這種情況可能出現(xiàn)在 FTP 中，LISTEN -> SYN_SENT 是因為這個連接可能是由于服務(wù)器端的應(yīng)用有數(shù)據(jù)發(fā)送給客戶端所觸發(fā)的，客戶端被動接受連接，連接建立后，開始傳輸文件。也就是說，處于 LISTEN 狀態(tài)的服務(wù)器也是有可能發(fā)送 SYN 報文的，只不過這種情況非常少見。

處于 SYN_SEND 狀態(tài)的服務(wù)器會接收 SYN 并發(fā)送 SYN 和 ACK 轉(zhuǎn)換成為 SYN_RCVD 狀態(tài)，同樣的，處于 LISTEN 狀態(tài)的客戶端也會接收 SYN 并發(fā)送 SYN 和 ACK 轉(zhuǎn)換為 SYN_RCVD 狀態(tài)。如果處于 SYN_RCVD 狀態(tài)的客戶端收到 RST 就會變?yōu)? LISTEN 狀態(tài)。

這兩張圖一起看會比較好一些。

這里需要解釋下什么是 RST

這里有一種情況是當(dāng)主機收到 TCP 報文段后，其 IP 和端口號不匹配的情況。假設(shè)客戶端主機發(fā)送一個請求，而服務(wù)器主機經(jīng)過 IP 和端口號的判斷后發(fā)現(xiàn)不是給這個服務(wù)器的，那么服務(wù)器就會發(fā)出一個 RST 特殊報文段給客戶端。

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

RST：(Reset the connection)用于復(fù)位因某種原因引起出現(xiàn)的錯誤連接，也用來拒絕非法數(shù)據(jù)和請求。如果接收到 RST 位時候，通常發(fā)生了某些錯誤。

上面沒有識別正確的 IP 端口是一種導(dǎo)致 RST 出現(xiàn)的情況，除此之外，RST 還可能由于請求超時、取消一個已存在的連接等出現(xiàn)。

位于 SYN_RCVD 的服務(wù)器會接收 ACK 報文，SYN_SEND 的客戶端會接收 SYN 和 ACK 報文，并發(fā)送 ACK 報文，由此，客戶端和服務(wù)器之間的連接就建立了。

這里還要注意一點，同時打開的狀態(tài)我在上面沒有刻意表示出來，實際上，在同時打開的情況下，它的狀態(tài)變化是這樣的。

為什么會是這樣呢?因為你想，在同時打開的情況下，兩端主機都發(fā)起 SYN 報文，而主動發(fā)起 SYN 的主機會處于 SYN-SEND 狀態(tài)，發(fā)送完成后，會等待接收 SYN 和 ACK ， 在雙方主機都發(fā)送了 SYN + ACK 后，雙方都處于 SYN-RECEIVED(SYN-RCVD) 狀態(tài)，然后等待 SYN + ACK 的報文到達后，雙方就會處于 ESTABLISHED 狀態(tài)，開始傳輸數(shù)據(jù)。

好了，到現(xiàn)在為止，我給你敘述了一下 TCP 連接建立過程中的狀態(tài)轉(zhuǎn)換，現(xiàn)在你可以泡一壺茶喝點水，等著數(shù)據(jù)傳輸了。

好了，現(xiàn)在水喝夠了，這時候數(shù)據(jù)也傳輸完成了，數(shù)據(jù)傳輸完成后，這條 TCP 連接就可以斷開了。

現(xiàn)在我們把時鐘往前撥一下，調(diào)整到服務(wù)端處于 SYN_RCVD 狀態(tài)的時刻，因為剛收到了 SYN 包并發(fā)送了 SYN + ACK 包，此時服務(wù)端很開心，但是這時，服務(wù)端應(yīng)用進程關(guān)閉了，然后應(yīng)用進程發(fā)了一個 FIN 包，就會讓服務(wù)器從 SYN_RCVD -> FIN_WAIT_1 狀態(tài)。

然后把時鐘調(diào)到現(xiàn)在，客戶端和服務(wù)器現(xiàn)在已經(jīng)傳輸完數(shù)據(jù)了 ，此時客戶端發(fā)送了一條 FIN 報文希望斷開連接，此時客戶端也會變?yōu)?FIN_WAIT_1 狀態(tài)，對于服務(wù)器來說，它接收到了 FIN 報文段并回復(fù)了 ACK 報文，就會從 ESTABLISHED -> CLOSE_WAIT 狀態(tài)。

位于 CLOSE_WAIT 狀態(tài)的服務(wù)端會發(fā)送 FIN 報文，然后把自己置于 LAST_ACK 狀態(tài)。處于 FIN_WAIT_1 的客戶端接收 ACK 消息就會變?yōu)?FIN_WAIT_2 狀態(tài)。

這里需要先解釋一下 CLOSING 這個狀態(tài)，F(xiàn)IN_WAIT_1 -> CLOSING 的轉(zhuǎn)換比較特殊

CLOSING 這種狀態(tài)比較特殊，實際情況中應(yīng)該是很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當(dāng)你發(fā)送FIN 報文后，按理來說是應(yīng)該先收到(或同時收到)對方的 ACK 報文，再收到對方的 FIN 報文。但是 CLOSING 狀態(tài)表示你發(fā)送 FIN 報文后，并沒有收到對方的 ACK 報文，反而卻也收到了對方的 FIN 報文。

什么情況下會出現(xiàn)此種情況呢?其實細想一下，也不難得出結(jié)論：那就是如果雙方在同時關(guān)閉一個鏈接的話，那么就出現(xiàn)了同時發(fā)送 FIN 報文的情況，也即會出現(xiàn) CLOSING 狀態(tài)，表示雙方都正在關(guān)閉連接。

FIN_WAIT_2 狀態(tài)的客戶端接收服務(wù)端主機發(fā)送的 FIN + ACK 消息，并發(fā)送 ACK 響應(yīng)后，會變?yōu)?TIME_WAIT 狀態(tài)。處于 CLOSE_WAIT 的客戶端發(fā)送 FIN 會處于 LAST_ACK 狀態(tài)。

這里不少圖和博客雖然在圖上畫的是 FIN + ACK 報文后才會處于 LAST_ACK 狀態(tài)，但是描述的時候，一般通常只對于 FIN 進行描述。也就是說 CLOSE_WAIT 發(fā)送 FIN 才會處于 LAST_ACK 狀態(tài)。

所以這里 FIN_WAIT_1 -> TIME_WAIT 的狀態(tài)也就是接收 FIN 和 ACK 并發(fā)送 ACK 之后，客戶端處于的狀態(tài)。

然后位于 CLOSINIG 狀態(tài)的客戶端這時候還有 ACK 接收的話，會繼續(xù)處于 TIME_WAIT 狀態(tài)，可以看到，TIME_WAIT 狀態(tài)相當(dāng)于是客戶端在關(guān)閉前的最后一個狀態(tài)，它是一種主動關(guān)閉的狀態(tài);而 LAST_ACK 是服務(wù)端在關(guān)閉前的最后一個狀態(tài)，它是一種被動打開的狀態(tài)。

上面有幾個狀態(tài)比較特殊，這里我們向西解釋下。

TIME_WAIT 狀態(tài)

通信雙方建立 TCP 連接后，主動關(guān)閉連接的一方就會進入 TIME_WAIT 狀態(tài)。TIME_WAIT 狀態(tài)也稱為 2MSL 的等待狀態(tài)。在這個狀態(tài)下，TCP 將會等待最大段生存期(Maximum Segment Lifetime, MSL) 時間的兩倍。

這里需要解釋下 MSL

MSL 是 TCP 段期望的最大生存時間，也就是在網(wǎng)絡(luò)中存在的最長時間。這個時間是有限制的，因為我們知道 TCP 是依靠 IP 數(shù)據(jù)段來進行傳輸?shù)?，IP 數(shù)據(jù)報中有 TTL 和跳數(shù)的字段，這兩個字段決定了 IP 的生存時間，一般情況下，TCP 的最大生存時間是 2 分鐘，不過這個數(shù)值是可以修改的，根據(jù)不同操作系統(tǒng)可以修改此值。

基于此，我們來探討 TIME_WAIT 的狀態(tài)。

當(dāng) TCP 執(zhí)行一個主動關(guān)閉并發(fā)送最終的 ACK 時，TIME_WAIT 應(yīng)該以 2 * 最大生存時間存在，這樣就能夠讓 TCP 重新發(fā)送最終的 ACK 以避免出現(xiàn)丟失的情況。重新發(fā)送最終的 ACK 并不是因為 TCP 重傳了 ACK，而是因為通信另一方重傳了 FIN，客戶端經(jīng)?；匕l(fā)送 FIN，因為它需要 ACK 的響應(yīng)才能夠關(guān)閉連接，如果生存時間超過了 2MSL 的話，客戶端就會發(fā)送 RST，使服務(wù)端出錯。