TCP鏈接創建過程當中爲何須要「三次握手」

http://chriszeng87.iteye.com/blog/1871772

傳輸控制協議 （Transmission Control Protocol, TCP ）是一種面向鏈接的、可靠的、基於字節流的運輸層（Transport layer）通訊協議。是專門爲了在不可靠的互聯網絡上提供一個可靠的端到端字節流而設計的。互聯網絡與單個網絡不一樣，由於互聯網絡的不一樣部分可能有着大相徑庭的拓撲、帶寬、延遲、分組大小和其餘參數。TCP的設計目標是可以動態的適應互聯網絡的這些特性，並且當面對多種失敗的時候仍然可以健壯。

每一次TCP鏈接都須要三個階段：鏈接創建、數據傳送和鏈接釋放。「三次握手」就發生在鏈接創建階段。 「三次握手」的具體過程網上有不少詳解。可自行Google之。這裏探討的是——爲何須要「三次握手」。

我Google該問題答案後發現，網絡上對於「三次握手」的過程都有很詳細的描述，但對於爲何須要「三次握手」來創建鏈接卻沒有很好的答案。只能求助於書本了。

在謝希仁著《計算機網絡》第四版中講「三次握手」的目的是「 爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤」。在另外一部經典的《計算機網絡》一書中講「三次握手」的目的是爲了解決「 網絡中存在延遲的重複分組 」的問題。 這兩種不用的表述其實闡明的是同一個問題。

謝希仁版《計算機網絡》中的例子是這樣的，「已失效的鏈接請求報文段」的產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。」

這個例子很清晰的闡釋了「三次握手」對於創建可靠鏈接的意義。

在Google Groups的TopLanguage中看到一帖討論TCP「三次握手」以爲頗有意思。貼主提出「TCP創建鏈接爲何是三次握手？」的問題，在衆多回復中，有一條回覆寫道：「 這個問題的本質是, 信道不可靠, 可是通訊雙發須要就某個問題達成一致. 而要解決這個問題,  不管你在消息中包含什麼信息, 三次通訊是理論上的最小值. 因此三次握手不是TCP自己的要求, 而是爲了知足"在不可靠信道上可靠地傳輸信息"這一需求所致使的. 請注意這裏的本質需求,信道不可靠, 數據傳輸要可靠. 三次達到了, 那後面你想接着握手也好, 發數據也好, 跟進行可靠信息傳輸的需求就不要緊了. 所以,若是信道是可靠的, 即不管何時發出消息, 對方必定能收到, 或者你不關心是否要保證對方收到你的消息, 那就能像UDP那樣直接發送消息就能夠了. 」。這可視爲對「三次握手」目的的另外一種解答思路。