今天和大家先分享一篇關於TCP協議及三次握手的知識。
TCP協議相關文章回顧↓
一、三次握手
三次握手：在通信之前，會先通過三次握手的機制來確認兩端口之間的連接是否可用。而UDP不需要確認是否可用，直接傳。
三次握手機制
一開始客戶端和服務端都是關閉狀態，但是在某個時刻，客戶端需要和服務端進行通信，此時雙方都會各自準備好端口，服務器段的端口會處於監聽狀態，等待客戶端的連接。
客戶端可會知道自己的端口號，和目的進程的端口號，這樣才能發起請求。
第一次握手：客戶端想與服務器進行連接了，所以狀態變為主動打開，同時發送一個連接請求報文給服務器段SYN=1，並且會攜帶x個字節過去。
發送完請求連接報文後，客戶端的狀態就變為了SYN_SENT，可以說這個狀態是等待發送確認(為了發送第三次握手時的確認包)
第二次握手：服務端接收到連接請求報文後，從LSTTEN狀態變為被動打開狀態，然後給客戶端返回一個報文。這個報文有兩層意思，一是確認報文，而可以達到告訴客戶端，我也打開連接了。
發完後，變為SYN_RCVD狀態(也可以說是等待接受確認狀態，接受客戶端發過來的確認包)
第三次握手：客戶端得到服務器端的確認和知道服務器端也已經準備好了連接後，還會發一個確認報文到服務器端，告訴服務器端，我接到了你發送的報文，接下來就讓我們兩個進行連接了。
客戶端發送完確認報文後，進入ESTABLISHED，而服務器接到了，也變為ESTABLISHED
進入到ESTABLISHED狀態後，連接就已經完成了，可以進行通信了。
問題：為什麼需要第三次握手，有前面兩次不就已經可以了嗎？
假設沒有第三次握手，客戶端發送一個連接請求報文過去，但是因為網絡延遲，在等待了一個超時時間後，客戶端就會再重新發一個請求連接報文過去，然後正常的進行；
服務器端發回一個確認連接報文，然後就開始通訊，通訊結束後，那個第一次因為網絡延遲的請求連接報文到了服務器端，服務器端不知道這個報文已經失效，也發回了一個確認連接報文。
客戶端接收後，發現自己並沒有發送連接請求(因為超時了，所以就認為自己沒有發)，所以對這個確認連接請求就什麼也不做，但是此時客戶端不這麼認為，他認為連接已經建立了，就一直打開著等待客戶端傳數據過來，這就造成了極大的浪費。
如果有了第三次握手，那麼客戶端就可以通知服務器了，所以第三次握手也很重要！
二、四次揮手
四次揮手是用來斷開服務器和客戶端之間的通信的，之所以要斷開連接，是因為TCP/IP 協議是要佔用端口號的，而計算機的端口卻是有限的，不進行斷開的話，勢必會造成計算機資源的浪費。
1、在整個通信的過程中，誰先發起請求，誰就是客戶端。
當客戶端的數據傳輸到尾部時，客戶端向服務器發送帶有FIN標誌的數據包，使其明白自己準備斷開通信了。
2、因為TCP的通信是使用全雙工通信的WebSocket，所以在斷開連接的時候也應該是雙向的；當服務器收到帶有FIN標誌的數據包時，其必不會直接發送FIN標誌斷開通信的請求，而是先發送一個帶有ACK標誌的應答信息，使客戶端明白服務器還有數據要進行發送。
3、當 服務器的數據發送完成後，向客戶端發送帶有FIN標誌的數據包，通知客戶端斷開連接。
4、這一次揮手是我覺得四次揮手中設計的最巧妙的一次。
當客戶端收到FIN後，擔心網絡上某些不可控制的因素導致服務器不知道他要斷開連接，會發送ACK進行確認，同時把自己設置成TIME_WAIT狀態並啟動定時器，**在TCP的定時器到達後客戶端並沒有接收到請求，會重新發送；當服務器收到請求後就斷開連接；當客戶端等待2MLS（兩倍報文最大生存時間）後，沒有收到請求重傳的請求後，客戶端這邊就斷開連接，**整個TCP通信就結束了。
四次揮手的圖如下所示：
問題：關閉的時候為什麼會是四次揮手？
四次揮手不能像三次握手一樣，三次握手可以將ACK+SYN 一起發送，ACK用於確認信息，SYN卻是用來建立聯機的；
四次揮手中ACK是不能和FIN一起發送，ACK只是告訴客戶端確認我收到了，等我將數據發送完畢之後會向其發送FIN的標誌，所以四次揮手是不能夠改變的。
