三次握手

三次握手（three times handshake；three-way handshake）所謂的“三次握手”即對每次傳送的資料量是怎樣跟蹤進行協商使資料段的傳送和接收同步，根據所接收到的資料量而確定的資料確認數及資料傳送、接收完畢後何時撤消聯絡，並建立虛連線。

第一次
第一次握手：建立連線時，客戶端傳送syn包（syn=j）到伺服器，並進入SYN_SENT狀態，等待伺服器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次

具體流程圖如下:

為什麼三次握手

在謝希仁著《計算機網路》第四版中講“三次握手”的目的是“為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤”。在另一部經典的《計算機網路》一書中講“三次握手”的目的是為了解決“網路中存在延遲的重複分組”的問題。這兩種不用的表述其實闡明的是同一個問題。
謝希仁版《計算機網路》中的例子是這樣的，“已失效的連線請求報文段”的產生在這樣一種情況下：client發出的第一個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是client再次發出的一個新的連線請求。於是就向client發出確認報文段，同意建立連線。假設不採用“三次握手”，那麼只要server發出確認，新的連線就建立了。由於現在client並沒有發出建立連線的請求，因此不會理睬server的確認，也不會向server傳送資料。但server卻以為新的運輸連線已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連線。”。主要目的防止server端一直等待，浪費資源。

四次揮手

TCP四次揮手，由於TCP連線是全雙工的，因此每個方向都必須單獨進行關閉。
由於TCP連線是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
第一次
客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送。
第二次
伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1。和SYN一樣，一個FIN將佔用一個序號。
第三次
伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A。
第四次

具體流程圖如下:

為什麼四次揮手

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裡來發送。但關閉連線時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料傳送給你了；但未必你所有的資料都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連線了，所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的.

整體流程