TCP的連接建立於連接釋放分別採用的是三次握手協議與四次握手協議。對應的狀態有：
1.tcp的連接建立與釋放過程：
2.TCP的狀態：
LISTEN：偵聽來自遠方的TCP端口的連接請求
SYN-SENT：再發送連接請求後等待匹配的連接請求，客戶機在連接請求發送後，等待服務器端的確認狀態
SYN-RECEIVED：再收到和發送一個連接請求後等待對方對連接請求的確認，服務器端接受都客戶機的連接請求後的發出確認包後，進入SYN-RECEIVED狀態
ESTABLISHED：代表一個打開的連接
FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認，客戶端發送連接中斷請求後將FIN至一，並進入FIN-WAIT-1狀態
FIN-WAIT-2：從遠程TCP等待連接中斷請求，客戶端收到FIN報文
確認後進入此狀態
CLOSE-WAIT：等待從本地用戶發來的連接中斷請求，服務器對客戶機的連接中斷請求的確認後進入CLOSE-WAIT狀態
CLOSING：等待遠程TCP對連接中斷的確認
LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認
TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
CLOSED：沒有任何連接狀態
3.狀態剖析：
建立連接協議（三次握手）
（1）客戶端發送一個帶SYN標誌的TCP報文到服務器。這是三次握手過程中的報文
（2）服務器端迴應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ACK標誌和SYN標誌。因此它表示對剛纔客戶端SYN報文的迴應；同時又標誌SYN給客戶端，詢問客戶端是否準備好進行數據通訊。
（3）客戶必須再次迴應服務段一個ACK報文，這是報文段3。
連接終止協議（四次握手）
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的連接。收到一個FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（1）TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送（報文段4）。
（2）服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。
（3）服務器關閉客戶端的連接，發送一個FIN給客戶端（報文段6）。
（4）客戶段發回ACK報文確認，並將確認序號設置爲收到序號加1（報文段7）。
●CLOSED:這個沒什麼好說的了，表示初始狀態。
●LISTEN:這個也是非常容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，可以接受連接了。
●SYN_RCVD:這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一箇中間狀態，短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最後一個ACK報文不予發送。因此這種狀態時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。
●SYN_SENT:這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。
●ESTABLISHED：這個容易理解了，表示連接已經建立了。
●FIN_WAIT_1:這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在●ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即進入到●FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。
●FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你，稍後再關閉連接。
●TIME_WAIT:表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。
●CLOSING:這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文後，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。
●CLOSE_WAIT:這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後發送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那麼你也就可以close這個SOCKET，發送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。
●LAST_ACK:這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。
有人會問到兩個問題：
1.爲什麼在客戶端收到服務器端對於請求報文的確認後還要做一次確認呢？？？？
主要是爲了防止已經失效的連接請求報文段突然有傳到了服務器端，何爲“失效的連接請求報文段”。我們假設一種情況，如果A向B發送了請求報文，但是沒有發送到B而是在網絡中滯留了，A會重新發送此報文，併到達B並且建立了連接，傳輸數據完成後並釋放了連接。當此失效的報文再一次到達B後，服務器端就會又一次以爲A發送了建立連接的報文，併發送確認，如果沒有第三次握手，B發送完確認後，此TCP連接就會建立成功。而這並不是A所希望的，所以A會不予回覆，B會一直處於等待A發送數據的狀態，造成B資源的浪費。
2.爲什麼在釋放鏈接的過程中TIME-WAIT要設定爲2MSL時間？？？？
（1）。保證A發送的最後一個確認關閉的報文能夠到達B以實現B的正常退出。如果A對於B發送的FIN+ACK報文的確認在網絡中丟失，B會因超時重傳FIN+ack報文，A等待2MSL時間可以保證收到此重傳報文，並對此報文做出回覆。
（2）。防止已失效的報文出現在本次連接中。A等待2MSL時間可以保證在這段時間內產生的所有的報文都會在網絡中失效，這樣不會對下一次的連接造成影響。