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

下面就來看看TCP狀態變遷過程中的幾個特殊狀態。

SYN_RCVD

在TCP連接建立的過程中，當服務端接收到[SYN]包后，就會發送[SYN, ACK]包，然后進入SYN_RCVD狀態。

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

回想一下我們在"動手學習TCP: 環境搭建"一文中使用的例子，這個例子就只是客戶端向服務端發送一個TCP連接建立請求包，然后就進入等待狀態了。

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

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

SYN Flood攻擊

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

由于服務端的SYN_RCVD狀態，就有了SYN Flood攻擊。

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

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

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

TIME_WAIT

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

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

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

為什么有 TIME_WAIT

之所以有一個TIME_WAIT狀態，而不是直接轉換成CLOSED狀態，主要有下面兩個原因：

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

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

TIME_WAIT的效果

當一端進入TIME_WAIT狀態后，所產生的效果就是該端口在2MSL這段時間中不能被再次使用。

看一個實驗例子，由于 操作系統不能檢測到Pcap.Net實現的客戶端的TCP連接狀態，所以通過Python實現了一個簡單的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()

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

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

TIME_WAIT的影響

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

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

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

復位報文段

關于復位報文段，它不是一個TCP狀態，但是確實TCP狀態變遷中不可少的一部分，所以在這里進行簡單的介紹。

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

一般下面情況下會經常碰到[RST]包：

請求不存在的端口

這次依然運行"動手學習TCP: 環境搭建"中的例子，只是把目標端口改為"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監聽端口，所以就會收到來自虛擬機的[RST]包：

異常終止一個連接

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

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

異常終止一個連接對應用程序來說有兩個優點：

丟棄任何帶發送數據并立即發送復位報文段

[RST]包的接收方能夠區分另一端執行的是異常關閉還是正常關閉。

總結

本文介紹了TCP狀態轉換中的兩個特殊狀態：SYN_RCVD和TIME_WAIT。

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

后半部分簡單介紹了復位報文段，以及復位報文段經常使用的情況。