找了一下資料發現還是有點門道的

只要還是來源於知戶上：傳送門

首先從Tcp通訊是全雙工通訊分析，全雙工也就是我可以給你發信息你也可以給我發信息(可以同時發)

三次握手也是確認這個全雙工通訊的過程

確認客戶端可以給服務端發訊息 第一次握手的客戶端傳送的syn包以及第二握手服務端傳送的ack

確認服務端可以給客戶端發訊息 第二次握手服務端傳送的syn包以及第三次握手客戶端傳送的ack

知戶上有個很有趣的答案描述了這個過程

我比較偏向於上述原因

還看到兩種比較有趣的回答

摘自知戶使用者：小宮呀

一種是為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤

“已失效的連線請求報文段”的產生在這樣一種情況下：client發出的第一個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是client再次發出的一個新的連線請求。於是就向client發出確認報文段，同意建立連線。假設不採用“三次握手”，那麼只要server發出確認，新的連線就建立了。由於現在client並沒有發出建立連線的請求，因此不會理睬server的確認，也不會向server傳送資料。但server卻以為新的運輸連線已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連線。”

另外一種是 如果想確定雙通道通暢，必須使用三個包的傳送接收，也就是三次握手

“這個問題的本質是, 通道不可靠, 但是通訊雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在訊息中包含什麼資訊, 三次通訊是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是為了滿足"在不可靠通道上可靠地傳輸資訊"這一需求所導致的. 請注意這裡的本質需求,通道不可靠, 資料傳輸要可靠. 三次達到了, 那後面你想接著握手也好, 發資料也好, 跟進行可靠資訊傳輸的需求就沒關係了. 因此,如果通道是可靠的, 即無論什麼時候發出訊息, 對方一定能收到, 或者你不關心是否要保證對方收到你的訊息, 那就能像UDP那樣直接傳送訊息就可以了.”

另外Tcp的可靠傳輸更多的是靠重傳機制來保證的