1、建立連接協議（三次握手）
三次握手過程說明：
1、 在最開始，客戶端和服務器都是處於CLOSED狀態
2、服務器會創建sockert開始監聽，服務器狀態LISTEN
3、客戶端向服務器端發送SYN，請求建立鏈接，發完之后自己的狀態變為SYN_CENT
4、服務器收到客戶端發來的SYN，然后會回復SYN和ACK，發完之后自己的狀態變為SYN_RECV RCVD
5、客戶端收到服務器發來的SYN和ACK之后會馬上回復ACK，回復完之后狀態變為ESTABLISHED
6、 服務器端收到客戶端發來的ACK之后會直接進入ESTABLISHED
至此，三次握手完成，連接建立
2、連接終止協議（四次揮手）
由於TCP連 接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終 止
這個方向的連接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接 在收到一個FIN后仍能發送數據。首先進行關閉的一
方將執行主動關閉，而另一方執行被動關閉。
揮手過程文字說明：
1、 客戶端先向服務器發送FIN報文，請求斷開連接，其狀態變為FIN_WAIT1.
2、 服務器收到FIN后向客戶端發送ACK，服務器狀態變為CLOSE_WAIT1
3、 客戶端收到ACK后進入FIN_WAIT2狀態。此時連接已經斷開了一半了，如果服務器還有數據要發送給客戶端，就會繼續發送
4、 直接發完了，就發送FIN報文，此時服務器進入LSAT_ACK狀態
5、 客戶端收到服務器的FIN后，馬上發送給ACK服務器，此時客戶端進入狀FIN_WAIT狀態
6、 再過了2MSL長的時間后進入CLOSED狀態。服務器收到客戶端的ACK就進入CLOSED狀態
至此，還有一個狀態沒有提及狀態CLOSIND狀態
CLOSIND狀態表示：
客戶端發生了FIN，但沒有收到服務器的ACK，卻收到了服務器的FIN。這種情況發生在服務器發送的丟包的時候，因為網絡傳輸有時會有意外
11種狀態總結表解：
11種狀態說明：
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可用狀態了。
各個狀態的意義如下：
LISTEN - 偵聽來自遠方TCP端口的連接請求； SYN-SENT -在發送連接請求后等待匹配的連接請求； SYN-RECEIVED - 在收到和發送一個連接請求后等待對連接請求的確認； ESTABLISHED- 代表一個打開的連接，數據可以傳送給用戶； FIN-WAIT-1 - 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認； FIN-WAIT-2 - 從遠程TCP等待連接中斷請求； CLOSE-WAIT - 等待從本地用戶發來的連接中斷請求； CLOSING -等待遠程TCP對連接中斷的確認； LAST-ACK - 等待原來發向遠程TCP的連接中斷請求的確認； TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認； CLOSED - 沒有任何連接狀態； TCP連接過程是狀態的轉換，促使發生狀態轉換的是用戶調用：
最后有2個問題 的回答，我自己分析后的結論（不一定保證100%正確）
1、 為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起 應答作用，而
SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文 通知時，它僅僅表示對方沒有數據發送給你
了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方
之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文 和FIN報文多數情況下都是分開發送的。
2、 為什么TIME_WAIT狀態還需要等2MSL后才能返回到CLOSED狀 態？
這是因為：雖然雙方 都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀 態（就
好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報
文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報 文，所以這
個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報 文，並保證於此。
斷開連接的時候， 當發起主動關閉的左邊這方發送一個FIN過去后，
右邊被動關閉的這方要回應一個ACK，這個ACK是TCP回應的，而不是應用程序發送的，
此時，被動關閉的一方就處於CLOSE_WAIT狀態了。
如果此時被動關閉的這一方不再繼續調用closesocket,那么他就不會發送接下來的FIN，導致自己老是處於CLOSE_WAIT。
只有被動關閉的這一方調用了 closesocket,才會發送一個FIN給主動關閉的這一方，同時也使得自己的狀態變遷為LAST_ACK。