在《計算機網路》一書中其中有提到，三次握手的目的是「為了防止已經失效的連線請求報文段突然又傳到服務端，因而產生錯誤」，這種情況是：一端(client)a發出去的第乙個連線請求報文並沒有丟失，而是因為某些未知的原因在某個網路節點上發生滯留，導致延遲到連線釋放以後的某個時間才到達另一端(server)b。本來這是乙個早已失效的報文段，但是b收到此失效的報文之後，會誤認為是a再次發出的乙個新的連線請求，於是b端就向a又發出確認報文，表示同意建立連線。如果不採用「三次握手」，那麼只要b端發出確認報文就會認為新的連線已經建立了，但是a端並沒有發出建立連線的請求，因此不會去向b端傳送資料，b端沒有收到資料就會一直等待，這樣b端就會白白浪費掉很多資源。如果採用「三次握手」的話就不會出現這種情況，b端收到乙個過時失效的報文段之後，向a端發出確認，此時a並沒有要求建立連線，所以就不會向b端傳送確認，這個時候b端也能夠知道連線沒有建立。
問題的本質是，通道是不可靠的，但是我們要建立可靠的連線傳送可靠的資料，也就是資料傳輸是需要可靠的。在這個時候三次握手是乙個理論上的最小值，並不是說是tcp協議要求的，而是為了滿足在不可靠的通道上傳輸可靠的資料所要求的。
tcp建立連線三次握手過程：
第一次握手：建立連線時， 客戶端傳送 syn包（syn=j）到 伺服器，並進入 syn_sent狀態，等待伺服器確認；syn：同步序列編號（ synchronize sequence numbers）
第二次握手：伺服器收到syn包，必須確認客戶的syn（ack=j+1），同時自己也傳送乙個syn包（syn=k），即syn+ack包，此時伺服器進入syn_recv狀態。
第三次握手：客戶端收到伺服器的syn+ack包，向伺服器傳送確認包ack(ack=k+1），此包傳送完畢，客戶端和伺服器進入established（tcp連線成功）狀態，完成三次握手。
tcp為什麼四次揮手？
本質的原因是tcp是全雙公的，要實現可靠的連線關閉，a發出結束報文fin，收到b確認後a知道自己沒有資料需要傳送了，b知道a不再傳送資料了，自己也不會接收資料了，但是此時a還是可以接收資料，b也可以傳送資料；當b發出fin報文的時候此時兩邊才會真正的斷開連線，讀寫分開。
tcp斷開連線四次揮手過程：
由於tcp連線是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的資料傳送任務後就能傳送乙個fin來終止這個方向的連線。收到乙個 fin只意味著這一方向上沒有資料流動，乙個tcp連線在收到乙個fin後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（1） tcp客戶端傳送乙個fin，用來關閉客戶到伺服器的 資料傳送。
（2） 伺服器收到這個fin，它發回乙個ack，確認序號為收到的序號加1。和syn一樣，乙個fin將占用乙個序號。
（3） 伺服器關閉客戶端的連線，傳送乙個fin給客戶端。
（4） 客戶端發回ack 報文確認，並將確認序號設定為收到序號加1。
TCP三次握手協議
摘自 syn攻擊原理以及防範技術 tcp握手協議 在tcp ip協議中，tcp協議提供可靠的連線服務，採用三次握手建立乙個連線。第一次握手 建立連線時，客戶端傳送syn包 syn j 到伺服器，並進入syn send狀態，等待伺服器確認 第二次握手 伺服器收到syn包，必須確認客戶的syn ack ...
TCP三次握手協議
在tcp ip協議中，tcp協議提供可靠的連線服務，採用三次握手建立乙個連線。第一次握手 建立連線時，客戶端傳送syn包 syn j 到伺服器，並進入syn send狀態，等待伺服器確認 第二次握手 伺服器收到syn包，必須確認客戶的syn ack j 1 同時自己也傳送乙個syn包 syn k 即...
TCP協議三次握手
第一次握手 客戶端傳送syn包 syn j 到伺服器，並進入syn send狀態，等待伺服器確認 第二次握手 伺服器收到syn包，必須確認客戶的syn ack j 1 同時自己也傳送乙個syn包 syn k 即syn ack包，此時伺服器進入 syn recv 狀態 第三次握手 客戶端 收到伺服器的...