tcp協議爲何是三次握手而不是兩次握手？

咱們都知道tcp協議須要三次握手，那爲何不是兩次握手呢，關於這個疑問我查了不少資料，看到不少的解釋，現概括總結以下，方便咱們理解記憶

若是是兩次握手，咱們一塊兒來看看下面兩種場景

1.形成資源浪費

• Client向Server發送了一個a1的包

假如這時因爲傳輸鏈路上遇到故障，致使a1傳輸到Server的時間特別長 假設1min
在這一分鐘的時間內，因爲Client沒有收到Server對於a1包的確認，Client會覺得上一個包發送丟了或者失敗
那麼Client會再發送一個a2的包

• Client又向Server發送了一個a2的包

此次Server正常收到

• 因而Server向Client發送了一個b2的確認包
• Client和Server創建連接

而隨後滯後的a1包傳到了Server，Server又會返回b1包確認

可是因爲Client已經清除了a1包，因此Client會丟棄掉這個包，可是Server又會保持這個至關於「殭屍」的鏈接

這樣就會形成白白浪費資源

在謝希仁著《計算機網絡》第四版中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段又忽然傳送到服務器，由於產生錯誤」

在另外一部經典的《計算機網絡》（AndrewS.Tanenbaum著，第四版）一書中講「三次握手」的目的是爲了解決「網絡中存在延遲的重複分組」的問題。

咱們會發現這兩種不一樣的表述其實闡明的是同一個問題。

2.死鎖可能發生

• Client向Server發送了一個鏈接請求分組
• Server收到這個分組，併發送了確認應答分組

按照兩次握手的協定，Server認爲已經成功的創建鏈接，能夠開始發送數據分組
而此時Server的應答分組傳輸丟失了，Client不知道Server是否已準備好，不知道Server創建什麼樣的序列號
Client甚至懷疑Server是否收到了本身的鏈接請求分組，在這種狀況下，Client認爲鏈接還未創建成功，將忽略Server發來的任何數據請求，只等待鏈接確認影帶分組。而Server在發出的分組超時後，重複發送一樣的分組，資源就造成了死鎖。

而上面兩種狀況，若是使用三次握手就能夠成功避免，三次握手完成的兩個重要功能

1. 既要雙方作好發送數據的準備工做（雙方都知道彼此已準備好）
2. 容許雙方就初始序列號進行協商，這個序列號在握手過程當中被髮送和確認