TCP連接的三次握手與四次斷開

一直總以爲三次握手和四次斷開，以前老師講的有問題，通過本身再次琢磨，發現是的，老師講的沒毛病，此次也把本身的理解總結一下，讓對這個知識模糊的小夥伴再換種思路去理解

首先看一下TCP三次握手發生了哪些：

TCP三次握手

這是第一次用畫圖工具畫圖，有點low，細節處理的很差見諒

這是第一次設計三次握手的過程，實際上發生了四件事，其次你要清楚TCP連接創建的標準是雙向的，就像談戀愛表白同樣，你必須倆人相互喜歡才能表白成功啊

白話版:
TCP 連接創建就像談戀愛同樣，互相表白纔是表白成功
背景條件:某專業 某低富帥 和 某黑富美 表白過程
1，低富帥向本身愛慕依舊的黑富美表白說：俺喜歡你
2，黑富美聽到低富帥的告白，回覆：恩
-->到這一階段，看到這狀況也就是說這哥們已經涼了，可是做爲上帝的我確定要他表白成功啊
3，黑富美回答以後，又思考了一下畢竟門當戶對，因而隨即也向低富帥表白說：俺喜歡你
4，低富帥聽到黑富美的告白，激動地回覆：恩
-->到此，倆人恩愛的在了一塊兒，就像TCP同樣，通信連接創建成功

可是有一點很差的是TCP三次握手原型要創建四次連接，考慮到Server在第2步和第3步都要向Client分別創建一次請求，那麼顯然這是浪費流量，後來改良版後的就將三次握手改爲了如今的樣子，以下：

通過這樣的一次裁剪和優化順利的將四次握手變成了如今的三次握手

TCP四次斷開

什麼是四次斷開呢，那麼既然能告白在一塊兒，也能性格不合而分手，而四次斷開就是發生在Client和Server數據傳輸完成時所發生的

白話版:
背景條件:某專業 某渣男 和 某白富美 因xxx事件，分手過程
1，有一天,渣男的主動向白富美說：咱倆分手吧
2，白富美聽到渣男的請求，回覆：恩，我知道了，你等下吧，我下午吧行李收拾下搬回學校
3，下午白富美搬回學校後，給渣男說，我甩了你，咱倆分手吧
4，渣男收到請求後，戀愛結束

固然可能有吃瓜羣衆坐不住了，爲何三次握手能壓縮成三次，四次斷開爲何不能？？？
四次斷開因爲服務器傳輸完畢後並不表明客戶端也同時接收完畢，因此emmmm..

完整的TCP通信和過程狀態

對於tcp的通信過程還有一個重要的點就是通信狀態，每次tcp的交流在系統中都是能夠監控的，看看狀態有哪些吧

咱們來捋一下每個狀態：
三次握手階段
第一次握手：創建鏈接時，客戶端發送syn包到服務器，並進入SYN_SENT狀態，等待服務器確認
第二次握手：服務器收到syn包，必須確認客戶的SYN，同時本身也發送一個SYN包，即SYN+ACK包，此時服務器進入SYN_RCVD狀態；(SYN_RCVD,原名爲syn_received有的博客是寫SYN_RCVD也有的是RECV,但我理解的是表達的都是一個意思)
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK，此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP鏈接成功）狀態，完成三次握手。
開始數據傳輸
...
四次斷開階段

第一次握手: 客戶端向服務端發起斷開請求，發送FIN，發送seq編號，並回覆上次正常數據傳輸的ack確認，客戶端進入FIN_WAIT_1
第二次握手: 服務端收到後，首先回復ack一個確認，進入CLOSE_WAIT狀態，而客戶端進入FIN_WAIT_2階段
第三次握手: 服務端向客戶端發送FIN斷開請求，和seq編號，進入LAST_ACK狀態，客戶端進入TIME_WAIT狀態
第四次握手: 客戶端收到FIN請求後，回覆ack,則通信鏈接斷開

其中兩個梗

SYN_RCVD:若是你的服務器出現了大量的SYN_RCVD，你可能要留意了可能遭遇了SYN泛洪×××

TCP SYN泛洪發生在OSI第四層，這種方式利用TCP協議的特性，就是三次握手。×××者發送TCP SYN，SYN是TCP三次握手中的第一個數據包，而當服務器返回ACK後，該×××者就不對其進行再確認，那這個TCP鏈接就處於掛起狀態，也就是所謂的半鏈接狀態，服務器收不到再確認的話，還會重複發送ACK給×××者。這樣更加會浪費服務器的資源。×××者就對服務器發送很是大量的這種TCP鏈接，因爲每個都無法完成三次握手，因此在服務器上，這些TCP鏈接會由於掛起狀態而消耗CPU和內存，最後服務器可能死機，就沒法爲正經常使用戶提供服務了。*

TIME_WAIT:若是你的服務器出現大量TIME_WAIT，那麼請格外留意你的服務器負載
TIME_WAY是TCP連接的最後一步，大規模的出現說明你的訪問量很大，必定要格外的留意資源的消耗，已作好隨時增長設備或者調整的準備

baklog什麼梗

表示內核爲相應套接字排隊的最大鏈接個數。SYN-ACK重傳次數服務器發送完SYN－ACK包，若是未收到客戶確認包，服務器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，若是重傳次數超過系統規定的最大重傳次數，系統將該鏈接信息從半鏈接隊列中刪除。注意，每次重傳等待的時間不必定相同。