前面兩篇文章介紹了TCP狀態(tài)變遷，以及通過實驗演示了客戶端和服務(wù)端的正常狀態(tài)變遷。

下面就來看看TCP狀態(tài)變遷過程中的幾個特殊狀態(tài)。

SYN_RCVD

在TCP連接建立的過程中，當(dāng)服務(wù)端接收到[SYN]包后，就會發(fā)送[SYN, ACK]包，然后進入SYN_RCVD狀態(tài)。

根據(jù)前面文章的介紹，服務(wù)器的上述行為被稱為被動打開，并且會等待來自客戶的的[ACK]包來完成TCP連接的建立。但是，如果此時客戶端沒有響應(yīng)，服務(wù)端就會超時重傳[SYN, ACK]包。

回想一下我們在"動手學(xué)習(xí)TCP: 環(huán)境搭建"一文中使用的例子，這個例子就只是客戶端向服務(wù)端發(fā)送一個TCP連接建立請求包，然后就進入等待狀態(tài)了。

讓我們再次運行這個例子，通過Wireshark抓包可以看到，虛擬機中的服務(wù)端進行了五次超時重傳，間隔為3s，6s，12s，24s，一共45s;但是，當(dāng)?shù)谖鍌€[SYN, ACK]包發(fā)送后，服務(wù)器將會繼續(xù)等待48s，最終第五次重傳也超時了。

在服務(wù)器重傳這段時間，通過虛擬機中的命令行運行 netstat -anp TCP | findstr "192.168.56" 命令，會看到服務(wù)器處于SYN_RCVD狀態(tài)。

SYN Flood攻擊

從上面的實驗結(jié)果可以看到，當(dāng)服務(wù)端收到客戶端的TCP連接請求后，會發(fā)送[SYN, ACK]包，進入SYN_RCVD狀態(tài)。如果沒有收到客戶端的確認，服務(wù)器會嘗試重傳，并保持SYN_RCVD狀態(tài)一段時間(通常是30秒到2分鐘)。

由于服務(wù)端的SYN_RCVD狀態(tài)，就有了SYN Flood攻擊。

所謂的SYN Flood攻擊就是，惡意的客戶端給服務(wù)端發(fā)了一個SYN后，就下線了，于是服務(wù)器需要默認等93s(通常是30秒到2分鐘，上面的例子是93s)才會斷開連接。

這樣，攻擊者就可以把服務(wù)器的SYN連接的隊列耗盡，讓正常的連接請求不能處理。

對于如何避免SYN Flood攻擊，服務(wù)端有很多設(shè)置方式，這里就不介紹了，有興趣可以網(wǎng)上查查。

TIME_WAIT

在客戶端的正常狀態(tài)變遷中，客戶端主動終止TCP連接，然后就會從TIME_WAIT狀態(tài)到CLOSED狀態(tài)。

TIME_WAIT狀態(tài)也稱為2MSL(Maximum Segment Lifetime)等待狀態(tài)，這個設(shè)置是TCP中4中定時器之一(另外的3個定時器后面介紹)。

RFC793定義了MSL為2分鐘，但是在實現(xiàn)中，MSL一般為30秒，1分鐘或者兩分鐘。

為什么有 TIME_WAIT

之所以有一個TIME_WAIT狀態(tài)，而不是直接轉(zhuǎn)換成CLOSED狀態(tài)，主要有下面兩個原因：

客戶端發(fā)送最后的確認[ACK]后進入TIME_WAIT狀態(tài)，但是這個[ACK]包可能會丟失;這種情況下服務(wù)端會重傳[FIN, ACK]。也就是說，TIME_WAIT停留2被的MSL就是為了讓TCP再次發(fā)送最后的[ACK]以方式這個[ACK]丟失。

防止上一次連接中的包，迷路后重新出現(xiàn)，影響新連接(經(jīng)過2MSL，上一次連接中所有的重復(fù)包都會消失)

TIME_WAIT的效果

當(dāng)一端進入TIME_WAIT狀態(tài)后，所產(chǎn)生的效果就是該端口在2MSL這段時間中不能被再次使用。

看一個實驗例子，由于 操作系統(tǒng)不能檢測到Pcap.Net實現(xiàn)的客戶端的TCP連接狀態(tài)，所以通過Python實現(xiàn)了一個簡單的socket客戶端，并強制指定客戶端的端口號為3333：

from socket import *
import time
Client_ADDR = ("192.168.56.101", 3333)
Server_ADDR = ("192.168.56.102", 8081)
BUFSIZ = 1024
client = socket(AF_INET, SOCK_STREAM)
client.bind(Client_ADDR)
client.connect(Server_ADDR)
print "client connect to server"
print "quit after 5 seconds"
time.sleep(5)
client.close()

當(dāng)程序運行后，可以通過netstat命令看到客戶端顯示進入"ESTABLISHED"狀態(tài)，當(dāng)終止連接后，就進入了"TIME_WAIT"狀態(tài)。

這時，當(dāng)再次運行客戶端程序的時候，就會遇到下面的異常，提示端口被占用：

TIME_WAIT的影響

從上面的介紹可以看到，主動終止TCP連接的一端會進入TIME_WAIT狀態(tài)，該端TCP連接的端口將在2MSL時間中不可用。

如果在大并發(fā)的短連接情況下，TIME_WAIT 就會很多，系統(tǒng)的可用端口資源就會面臨耗盡的情況。

這也就說明了HTTP的KeepAlive對HTTP服務(wù)器是多么的重要，在設(shè)置KeepAlive的情況下，瀏覽器會重用一個TCP連接來處理多個HTTP請求，減緩TIME_WAIT帶來的影響。

復(fù)位報文段

關(guān)于復(fù)位報文段，它不是一個TCP狀態(tài)，但是確實TCP狀態(tài)變遷中不可少的一部分，所以在這里進行簡單的介紹。

所謂復(fù)位報文段就是TCP首部中，設(shè)置RST標(biāo)志的TCP包。一般來說，無論何時一個報文段發(fā)送過程中遇到連接錯誤，TCP都會發(fā)出一個[RST]包來重置該TCP連接。

一般下面情況下會經(jīng)常碰到[RST]包：

請求不存在的端口

這次依然運行"動手學(xué)習(xí)TCP: 環(huán)境搭建"中的例子，只是把目標(biāo)端口改為"1234"。

EndPointInfo endPointInfo = new EndPointInfo();
endPointInfo.SourceMac = "08:00:27:00:C0:D5";
endPointInfo.DestinationMac = "08:00:27:70:A6:AE";
endPointInfo.SourceIp = "192.168.56.101";
endPointInfo.DestinationIp = "192.168.56.102";
endPointInfo.SourcePort = 3330;
//endPointInfo.DestinationPort = 8081;
endPointInfo.DestinationPort = 1234;

運行程序，由于虛擬機中的"1234"端口并不是一個TCP監(jiān)聽端口，所以就會收到來自虛擬機的[RST]包：

異常終止一個連接

前面已經(jīng)看到，正常終止一個TCP連接需要進行四次揮手，這也被稱為有序釋放(orderly release)。

但是，也有情況是通過[RST]包來釋放一個連接，這種情況被稱為異常釋放(abortive release)。

異常終止一個連接對應(yīng)用程序來說有兩個優(yōu)點：

丟棄任何帶發(fā)送數(shù)據(jù)并立即發(fā)送復(fù)位報文段

[RST]包的接收方能夠區(qū)分另一端執(zhí)行的是異常關(guān)閉還是正常關(guān)閉。

總結(jié)

本文介紹了TCP狀態(tài)轉(zhuǎn)換中的兩個特殊狀態(tài)：SYN_RCVD和TIME_WAIT。

SYN_RCVD狀態(tài)會使服務(wù)端的特定端口，在一段時間內(nèi)重傳[SYN, ACK]包，直到超時或者客戶端有相應(yīng);在該端時間內(nèi)，服務(wù)器的該端口被占用。TIME_WAIT狀態(tài)則是，主動關(guān)閉TCP連接的一端，會保持2MSL的時間后，才進入CLOSED狀態(tài)。

后半部分簡單介紹了復(fù)位報文段，以及復(fù)位報文段經(jīng)常使用的情況。