簡單理解TCP的三次握手與四次揮手

seq（消息序號）：第一次請求時，隨機生成一個值,然後每次+1
ack（確認序號）：接收上一條信息的seq+1
SYN：發起一個新鏈接的請求時，爲1
FIN：釋放一個鏈接的請求時，爲1
ACK:與ack不一樣，TCP協議規定，當鏈接創建後全部報文的ACK必須爲1

三次握手：

1. A-> ACK=0,SYN=1,seq=x;（請求鏈接）
2. B-> ACK=1,SYN=1,ack=x+1,seq=y;（響應請求鏈接）
3. A-> ACK=1,ack=y+1,seq=x+1（確認接收響應，創建鏈接）
   

四次揮手：

1. A-> ACK=0,FIN=1,seq=u;（請求釋放）
2. B-> ACK=1,seq=v,ack=u+1;（收到請求，響應等待）
3. B-> ACK=1,FIN=1,seq=w,ack=u+1 ;（完成，響應結束釋放）
4. A-> ACK=1,seq=u+1,ack=w+1;（響應完全釋放）
   

• 爲何要採用三次握手，兩次不行嗎？
  第三次握手用於確保服務端接收到的鏈接請求是有效的。那麼何時會出現「無效鏈接請求」呢？

  「已失效的鏈接請求報文段」的產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據，形成server的資源被浪費。

• 爲何TCP釋放鏈接時TIME_WAIT要等待2ms的時間

  第一，爲了保證A發送的最後一個ACK報文可以到達B。這個ACK報文段有可能丟失，於是使處在LAST-ACK狀態的B收不到對已發送的FIN+ACK報文段的確認。B會超時重傳這個FIN+ACK報文段，而A就能在2MSL時間內收到這個重傳的FIN+ACK報文段。若是A在TIME-WAIT狀態不等待一段時間，而是在發送完ACK報文段後就當即釋放鏈接，就沒法收到B重傳的FIN+ACK報文段，於是也不會再發送一次確認報文段。這樣，B就沒法按照正常的步驟進入CLOSED狀態。
  第二，A在發送完ACK報文段後，再通過2MSL時間，就可使本鏈接持續的時間所產生的全部報文段都從網絡中消失。這樣就可使下一個新的鏈接中不會出現這種舊的鏈接請求的報文段。

  摘自–《計算機網絡》第五版

https://zhuanlan.zhihu.com/p/21940234

推薦：
http://www.javashuo.com/article/p-nyzvsklm-gw.html
https://blog.csdn.net/sssnmnmjmf/article/details/68486261