額外的點：
兩次握手不行，因為：三次握手是為了防止已經失效的連線請求報文段突然又傳到了服務端，從而產生錯誤。 比如：a 發出的第乙個連線請求報文段在網路結點長時間滯留了，導致延誤到連線釋放之後的某個時間才到達 b。 本來這是乙個早已失效的報文段，但是 b 會誤以為這是 a 又發出一次新的連線請求，於是就向 a 發出確認報文段，同意建立連線。如果不採用第三次握手，那麼只要 b 發出確認，b 就認為新的連線已經建立了。但由於 a 並沒有發出建立連線的請求，所以不會理睬 b 的確認，也就不會向 b 傳送資料，而 b 以為新的連線已經建立，就會一直等待 a 發來資料，這樣就白白浪費了 b 的資源。如果採用了三次握手，b 由於收不到確認，就會知道 a 並沒有要求建立連線，也就不會又開啟連線了。
四次握手不行，因為在經過三次握手後，客戶端和服務端已經可以確認建立連線了，所以沒必要再增加握手次數。
開始主機 a 和主機 b 都處於已建立連線狀態。首先 a 向 b 發出連線釋放報文段，並停止傳送資料，主動關閉 tcp 連線。報文段首部的終止控制位 fin 置為 1，序號 seq = u，這個序號等於前面已經傳送過的資料的最後乙個位元組的序號加 1 。這時 a 進入 fin-wait-1（終止等待1）狀態，等待 b 的確認。（這個報文段會消耗掉乙個序號）
b 收到連線釋放報文段後立即向 a 發出確認，確認號 ack = u + 1 ，序號 seq = v，這個序號等於 b 前面已經傳送過的資料的最後乙個位元組的序號加 1 。然後 b 進入 close-wait（關閉等待）狀態。此時 tcp 連線處於半關閉狀態，也就是 a 已經沒有資料要傳送了，但 b 若傳送資料，a 仍要接收，因為 b 到 a 這個方向的連線並未關閉。a 收到 b 的確認後，就進入 fin-wait-2（終止等待2）狀態，等待 b 傳送連線釋放報文段。
若 b 已經沒有要向 a 傳送的資料了，就通知 tcp 釋放連線，向 a 發出連線釋放報文段，報文段的終止控制位 fin = 1 ，確認號 ack = u + 1 ，序號 seq = w 。b 進入 last-ack（最後確認）狀態，等待 a 的確認。
a 收到 b 的連線釋放報文段後，發出確認釋放報文段，報文段的確認位 ack 為 1，確認號 ack = w + 1 ，序號 seq = u + 1（因為前面 fin 報文段消耗了乙個序號）。然後進入 time-wait（時間等待）狀態。此時 tcp 連線還沒釋放掉，必須經過時間等待計時器設定的 2msl 時間後，a 才進入關閉狀態，msl 指的是報文最長存活時間。b 一收到 a 的確認，就進入關閉狀態。所以在釋放連線時， b 結束 tcp 連線的時間要早於 a。
（a 之所以等待 2msl 時間，有兩個原因（time_wait的作用）：一是為了保證 a 傳送的最後乙個 ack 報文段能夠到達 b，如果這個報文段丟失，導致 b 未收到 a 發來的確認報文，那麼 b 會超時重傳這個 fin + ack 報文段，而 a 就能在 2msl 時間內收到這個重傳的報文段，接著 a 重傳一次確認，並重新啟動 2msl 計時器。最後使 a 和 b 都正常進入到關閉狀態。二是等待 2msl 時間，可以使本次連線持續時間內所產生的所有報文段都從網路中消失，使下乙個新的連線中不會出現舊的連線請求報文段）
注意：四次揮手為什麼第二次跟第三次不能合併, 第二次和第三次之間的等待是什麼?原因：高併發可以讓伺服器在短時間內占用大量埠，埠範圍是0~65535，客戶端每斷開乙個連線，該連線就會進入timewait狀態，預設60s超時**。在這種高併發場景下容易造成time-wait過多，沒有埠可用，導致連線失敗。
解決辦法：
三次握手 四次揮手
1.tcp連線的建立 1 首先是伺服器初始化的過程，從 closed 關閉 狀態開始通過順序呼叫 socket bind listen 和accept 原語建立 socket 套接字，進入 listen 監聽 狀態，等待客戶端的 tcp傳輸連線請求。2 客戶端最開始也是從 closed 狀態開始呼叫...
三次握手，四次揮手
三次握手 three times handshake three way handshake 所謂的 三次握手 即對每次傳送的 資料量是怎樣跟蹤進行協商使 資料段的傳送和接收同步，根據所接收到的資料量而確定的資料確認數及資料傳送 接收完畢後何時撤消聯絡，並建立虛連線。為了提供可靠的傳送，tcp在傳送...
三次握手 四次揮手
在tcp ip 協議中，tcp 協議提供可靠的連線服務，採用三次握手建立乙個連線，如圖1所示。1 第一次握手 建立連線時，客戶端a 傳送syn 包 syn j 到伺服器b 並進入syn send 狀態，等待伺服器b 確認。2 第二次握手 伺服器b 收到syn 包，必須確認客戶a 的syn ack j...