TCP的三次握手與四次揮手過程，各個狀態名稱與含義

三次握手

第一次握手：主機A發送位碼爲syn＝1,隨機產生seq number=10001的數據包到服務器，主機B由SYN=1知道，A要求創建聯機，此時狀態爲SYN_SENT； 
第二次握手：主機B收到請求後要確認聯機信息，向A發送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=20001的包，此時狀態由LISTEN變爲SYN_RECV； 
第三次握手：主機A收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則鏈接創建成功，雙方狀態ESTABLISHED。

完成三次握手，主機A與主機B開始傳送數據

• 各個狀態名稱與含義

  CLOSED: 這個沒什麼好說的了，表示初始狀態。 
  LISTEN: 這個也是很是容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，能夠接受鏈接了。 
  SYN_RECV: 這個狀態表示接受到了SYN報文，在正常狀況下，這個狀態是服務器端的SOCKET在創建TCP鏈接時的三次握手會話過程當中的一箇中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特地寫了一個客戶端測試程序，故意將三次TCP握手過程當中最後一個ACK報文不予發送。所以這種狀態 時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。 
  SYN_SENT: 這個狀態與SYN_RECV遙想呼應，當客戶端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狀態下的SOCKET當收到SYN報文的建連請求後，它能夠把ACK和SYN（ACK起應答做用，而SYN起同步做用）放在一 個報文裏來發送。但關閉鏈接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你全部的數據都所有發送給對方了，因此你能夠未 必會立刻會關閉SOCKET,也即你可能還須要發送一些數據給對方以後，再發送FIN報文給對方來表示你贊成如今能夠關閉鏈接了，因此它這裏的ACK報文 和FIN報文多數狀況下都是分開發送的。

• 爲何TIME_WAIT狀態還須要等2MSL後才能返回到CLOSED狀態？ 
  由於雖然雙方都贊成關閉鏈接了，並且握手的4個報文也都發送完畢，按理能夠直接回到CLOSED 狀態(就比如從SYN_SENT 狀態到ESTABLISH 狀態那樣)，可是咱們必須假想網絡是不可靠的，你沒法保證你(客戶端)最後發送的ACK報文必定會被對方收到，就是說對方處於LAST_ACK 狀態下的SOCKET可能會由於超時未收到ACK報文，而重發FIN報文，因此這個TIME_WAIT 狀態的做用就是用來重發可能丟失的ACK報文。

• 關閉TCP鏈接必定須要4次揮手嗎? 
  不必定，4次揮手關閉TCP鏈接是最安全的作法。但在有些時候，咱們不喜歡TIME_WAIT 狀態(如當MSL數值設置過大致使服務器端有太多TIME_WAIT狀態的TCP鏈接，減小這些條目數能夠更快地關閉鏈接，爲新鏈接釋放更多資源)，這時咱們能夠經過設置SOCKET變量的SO_LINGER標誌來避免SOCKET在close()以後進入TIME_WAIT狀態，這時將經過發送RST強制終止TCP鏈接(取代正常的TCP四次握手的終止方式)。但這並非一個很好的主意，TIME_WAIT 對於咱們來講每每是有利的。