大家都知道TCP有三次握手的過程，今天我就仔細想了想為什麼TCP要有三次握手

    先貼一張三次握手的示意圖，說明一點是在三次握手中A是在第二次握手後申請快取資源，B是在第一次握手後申請

    其實這個問題就是說，為什麼tcp不能兩次握手，或者一次握手就建立連線，和三次握手時怎麼解決兩次握手中的問題的。

    為什麼不能一次握手很容易理解，TCP是面向連線的，一次握手肯定建立不了連線，一條資訊發出去連個回信都沒有怎麼連線？所以問題在為什麼不能兩次握手，這個問題也很容易網上說的也不少，假設只有兩次握手，比如圖中的1，2步，當A想要建立連線時傳送一個SYN，然後等待ACK，結果這個SYN因為網路問題沒有及時到達B，所以A在一段時間內沒收到ACK後，在傳送一個SYN，B也成功收到，然後A也收到ACK，這時A傳送的第一個SYN終於到了B，對於B來說這是一個新連線請求，然後B又為這個連線申請資源，返回ACK，然而這個SYN是個無效的請求，A收到這個SYN的ACK後也並不會理會它，而B卻不知道，B會一直為這個連線維持著資源，造成資源的浪費

    那三次握手為什麼可以？兩次握手的問題在於伺服器端不知道一個SYN是否是無效的，而三次握手機制因為客戶端會給伺服器回覆第二次握手，也意味著伺服器會等待客戶端的第三次握手，如果第三次握手遲遲不來，伺服器便會認為這個SYN是無效的，釋放相關資源。但這時有個問題就是客戶端完成第二次握手便認為連線已建立，而第三次握手可能在傳輸中丟失，服務端會認為連線是無效的，這時如果Client端向Server寫資料，Server端將以RST包響應，方能感知到Server的錯誤。

   總的來說，三次握手可以保證任何一次握手出現問題，都是可以被發現或補救的

     第一次握手A傳送SYN傳輸失敗，A,B都不會申請資源，連線失敗。如果一段時間內發出多個SYN連線請求，那麼A只會接受它最後傳送的那個SYN的SYN+

     第二次握手B傳送SYN+ACK傳輸失敗，A不會申請資源，B申請了資源，但收不到A的ACK，過一段時間釋放資源。如果是收到了多個A的SYN請求，B都會回覆SYN+ACK，但A只會承認其中它最早傳送的那個SYN的迴應，並回復最後一次握手的ACK

     第三次握手ACK傳輸失敗，B沒有收到ACK，釋放資源，對於後序的A的傳輸資料返回RST。實際上B會因為沒有收到A的ACK會多次傳送SYN+ACK，次數是可以設定的，如果最後還是沒有收到A的ACK，則釋放資源，對A的資料傳輸返回RST