一句話概括，TCP連接握手，握的是啥？
通信雙方數據原點的序列號！
第一個包，即A發給B的SYN 中途被丟，沒有到達B
A會週期性超時重傳，直到收到B的確認
第二個包，即B發給A的SYN +ACK 中途被丟，沒有到達A
B會週期性超時重傳，直到收到A的確認
第三個包，即A發給B的ACK 中途被丟，沒有到達B
A發完ACK，單方面認爲TCP爲 Established狀態，而B顯然認爲TCP爲Active狀態：謝希仁版《計算機網絡》中的例子是這樣的，“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送ack包。（校注：此時因爲client沒有發起建立連接請求，所以client處於CLOSED狀態，接受到任何包都會丟棄，謝希仁舉的例子就是這種場景。但是如果服務器發送對這個延誤的舊連接報文的確認的同時，客戶端調用connect函數發起了連接，就會使客戶端進入SYN_SEND狀態，當服務器那個對延誤舊連接報文的確認傳到客戶端時，因爲客戶端已經處於SYN_SEND狀態，所以就會使客戶端進入ESTABLISHED狀態，此時服務器端反而丟棄了這個重複的通過connect函數發送的SYN包，見第三個圖。而連接建立之後，發送包由於SEQ是以被丟棄的SYN包的序號爲準，而服務器接收序號是以那個延誤舊連接SYN報文序號爲準，導致服務器丟棄後續發送的數據包）但server卻以爲新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛纔那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。
“這個問題的本質是, 信道不可靠, 但是通信雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在消息中包含什麼信息, 三次通信是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是爲了滿足”在不可靠信道上可靠地傳輸信息”這一需求所導致的. 請注意這裏的本質需求,信道不可靠, 數據傳輸要可靠. 三次達到了, 那後面你想接着握手也好, 發數據也好, 跟進行可靠信息傳輸的需求就沒關係了. 因此,如果信道是可靠的, 即無論什麼時候發出消息, 對方一定能收到, 或者你不關心是否要保證對方收到你的消息, 那就能像UDP那樣直接發送消息就可以了.”。
作者：郭無心
鏈接：https://www.zhihu.com/question/24853633/answer/63668444
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
4. 重點在於：雙方都需要確認自己的發信和收信功能都正常，收信功能通過接收對方信息得到確認，發信功能需要發出信息，然後收到對方的確認信息得到確認。
作者：Sheng Liu
來源：知乎
5. 而之所以存在 3-way hanshake 的說法，是因爲 TCP 是雙向通訊協議，作爲響應一方(Responder) 要想初始化發送通道，必須也進行一輪 SYN + ACK。由於 SYN ACK 在 TCP 分組頭部是兩個標識位，因此處於優化目的被合併了。所以達到雙方都能進行收發的狀態只需要 3 個分組。所以實際上理解成兩次（單向通訊）和四次（不考慮合併）也未嘗不可。
作者：安江澤
鏈接：https://www.zhihu.com/question/24853633/answer/115149437
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。