TCP的整個連線過程

如果沒有基礎的話，直接看這張圖或者網路上各種文字描述，十分生澀，所以先看懂接下來的握手揮手的圖，理解之後，再看這個有限狀態機就感覺原來如此簡單。

三次握手

握手過程

第一次握手：主機A傳送位碼為syn＝1，隨機產生seq number=x的資料包到伺服器，客戶端進入SYN_SEND狀態，等待伺服器的確認；主機B由SYN=1知道A要求建立連線。

第二次握手：主機B收到請求後要確認連線資訊，向A傳送ack number(主機A的seq+1)、syn=1、ack=1，隨機產生seq=y的包，此時伺服器進入SYN_RECV狀態。

第三次握手：主機A收到後檢查ack number是否正確，即第一次傳送的seq number+1，以及位碼ack是否為1，若正確，主機A會再發送ack number(主機B的seq+1)、ack=1，主機B收到後確認seq值與ack=1則連線建立成功。客戶端和伺服器端都進入ESTABLISHED狀態。

三次握手的必要性

1. 第一次握手：客戶端傳送網路包，服務端收到了。這樣服務端就能得出結論：客戶端的傳送能力、服務端的接收能力是正常的。
   
2. 第二次握手：服務端發包，客戶端收到了。這樣客戶端就能得出結論：服務端的接收、傳送能力，客戶端的接收、傳送能力是正常的。不過此時伺服器並不能確認客戶端的接收能力是否正常。
   
3. 第三次握手：客戶端發包，服務端收到了。這樣服務端就能得出結論：客戶端的接收能力，伺服器自己的傳送能力也正常。

至此，客戶端和服務端可以確定雙方的接收和傳送能力均正常。

第三次握手的必要性

這主要是為了防止已失效的連線請求報文段突然又傳送到了伺服器端，從而減少服務端的開銷。
如果只有兩次握手就建立連線會出現這種情況：客戶端發出的連線請求報文段在某些網路節點長時間滯留了，以致延誤到連線釋放以後的某個時間才能到達服務端。本來這是一個早已失效的報文段，但服務端收到此失效的連線請求報文段後，就誤認為客戶端又發出了一次新的連線請求。於是向客戶端發出確認報文段，同意建立連線。由於現在客戶端並沒有發出建立連線的請求，因此不會處理服務端的確認，也不會向服務端傳送資料。但服務端卻以為新的連線已經建立了，並一直等待客戶端發來資料。 服務端會因此浪費很多了。

如果第三次握手丟失了，客戶端服務端會如何處理？

服務端：
該TCP連線的狀態為SYN_RECV,並且會根據TCP的超時重傳機制，會等待3秒、6秒、12秒後重新發送SYN+ACK包，以便Client重新發送ACK包。而Server重發SYN+ACK包的次數，可以通過設定/proc/sys/net/ipv4/tcp_synack_retries修改，預設值為5。如果重發指定次數之後，仍然未收到客戶端的ACK應答，那麼一段時間後，服務端自動關閉這個連線。
客戶端：
客戶端在接收到SYN+ACK包，它的TCP連線狀態就為ESTABLISHED（已連線），表示該連線已經建立。那麼如果第三次握手中的ACK包丟失的情況下，客戶端向服務端傳送資料，服務端將以RST包(reset重置)響應，才能感知到服務端的錯誤。

什麼是syn flood攻擊

syn flood是一種經典的ddos攻擊手段，這裡面用到了TCP三次握手存在的漏洞。當服務端接收到SYN後進入SYN-RECV狀態，此時的連線稱為半連線，同時會被服務端寫入一個半連線佇列。如果攻擊者在短時間內不斷的向服務端傳送大量的SYN包而不響應，那麼伺服器的半連線佇列很快會被寫滿，從而導致無法工作。 實現syn flood 的手段，可以通過偽造源IP的方式，這樣伺服器的響應就永遠到達不了客戶端(握手無法完成)；當然，通過設定客戶端防火牆規則也可以達到同樣的目的。對syn flood實現攔截是比較困難的，可以通過啟用 syn_cookies 的方式實現緩解，但這通常不是最佳方案。最好的辦法是通過專業的防火牆來解決，基本上所有的雲端計算大 都具備這個能力。

四次揮手

揮手過程

第一次揮手：主機A（可以是客戶端，也可以是伺服器端），設定Sequence Number和Acknowledgment Number，向主機B傳送一個FIN報文段；此時，主機A進入FIN_WAIT_1狀態；這表示主機A沒有資料要傳送給主機B了。
第二次揮手：主機B收到了主機A傳送的FIN報文段，向主機A回一個ACK報文段，Acknowledgment Number為Sequence Number加1，主機A進入FIN_WAIT_2狀態；主機B告訴主機A，我也沒有資料要傳送了，可以進行關閉連線了。
第三次揮手：主機B向主機A傳送FIN報文段，請求關閉連線，同時主機B進入CLOSE_WAIT狀態。
第四次揮手：主機A收到主機B傳送的FIN報文段，向主機B傳送ACK報文段，然後主機A進入TIME_WAIT狀態；主機B收到主機A的ACK報文段以後，就關閉連線；此時，主機A等待2MSL後依然沒有收到回覆，則證明主機B已正常關閉，那好，主機A也可以關閉連線了。

主機B傳送了FIN-ACK之後，會立即啟動超時重傳計時器
主機A在傳送最後一個ACK之後，會立即啟動時間等待計時器

揮手為什麼需要四次？

因為當服務端收到客戶端的SYN連線請求報文後，可以直接傳送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連線時，當服務端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴客戶端，"你發的FIN報文我收到了"。只有等到我服務端所有的報文都發送完了，我才能傳送FIN報文，因此不能一起傳送。故需要四次揮手。

RST是什麼，為什麼會出現

RST 是一個特殊的標記，用來表示當前應該立即終止連線。以下這些情況都會產生RST：

• 向一個未被監聽的埠傳送資料
• 對方已經呼叫 close 關閉連線
• 存在一些資料未處理(接收緩衝區)，請求關閉連線時，會發送RST強制關閉
• 某些請求發生了超時

為什麼伺服器會有大量closewait

半關閉的狀態下的伺服器連線會處於closewait狀態，直到伺服器傳送了FIN。 那麼在應用層則是呼叫socket.close()會執行FIN的傳送，如果伺服器出現大量CLOSE_WAIT狀態的連線，那麼有可能的原因：

• 伺服器壓力過大，根本來不及呼叫close
• 存在連線洩露問題(Bug)，伺服器未及時關閉連線

四次揮手釋放連線時，等待2MSL的意義

為了保證客戶端傳送的最後一個ACK報文段能夠到達伺服器。因為這個ACK有可能丟失，從而導致處在LAST-ACK狀態的伺服器收不到對FIN-ACK的確認報文。伺服器會超時重傳這個FIN-ACK，接著客戶端再重傳一次確認，重新啟動時間等待計時器。最後客戶端和伺服器都能正常的關閉。假設客戶端不等待2MSL，而是在傳送完ACK之後直接釋放關閉，一但這個ACK丟失的話，伺服器就無法正常的進入關閉連線狀態。

MSL是Maximum Segment Lifetime的英文縮寫，可譯為“最長報文段壽命”，它是任何報文在網路上存在的最長時間，超過這個時間報文將被丟棄。我們都知道IP頭部中有個TTL欄位，TTL是time to live的縮寫，可譯為“生存時間”，這個生存時間是由源主機設定初始值代表一個IP資料包可以經過的最大路由數，每經過一個路由器，它的值就減1，當此值為0則資料報被丟棄，同時傳送ICMP報文通知源主機。RFC793中規定MSL為2分鐘，但這完全是從工程上來考慮，對於現在的網路，常用值30秒或1分鐘。因此TCP允許不同的實現可根據具體情況使用更小的MSL值。

最後，限於筆者經驗水平有限，歡迎讀者就文中的觀點提出寶貴的建議和意見。如果想獲得更多的學習資源或者想和更多的是技術愛好者一起交流，可以關注我的公眾號『全菜工程師小輝』後臺回覆關鍵詞領取學習資料、進入前後端技術交流群和程式設計師副業群。同時也可以加入程式設計師副業群Q群：735764906 一起交流。

相關推薦