TCP(Transmission Control Protocol 傳輸控制協議)是一種面向連接的、可靠的、基于字節流的傳輸層通信協議，由IETF的RFC 793定義。

三次握手

TCP連接是通過三次握手來連接的。

第一次握手

當客戶端向服務器發起連接請求時，客戶端會發送同步序列標號SYN到服務器，在這里我們設SYN為m，等待服務器確認，這時客戶端的狀態為SYN_SENT。

第二次握手

當服務器收到客戶端發送的SYN后，服務器要做的是確認客戶端發送過來的SYN，在這里服務器發送確認包ACK，這里的ACK為m+1，意思是說“我收到了你發送的SYN了”，同時，服務器也會向客戶端發送一個SYN包，這里我們設SYN為n。這時服務器的狀態為SYN_RECV。

一句話，服務器端發送SYN和ACK兩個包。

第三次握手

客戶端收到服務器發送的SYN和ACK包后，需向服務器發送確認包ACK，“我也收到你發送的SYN了，我這就給你發個確認過去，然后我們即能合體了”，這里的ACK為n+1，發送完畢后，客戶端和服務器的狀態為ESTABLISH，即TCP連接成功。

在三次握手中，客戶端和服務器端都發送兩個包SYN和ACK，只不過服務器端的兩個包是一次性發過來的，客戶端的兩個包是分兩次發送的。

三次握手示意圖如下(純手繪，見諒見諒)：

四次揮手

當A端和B端要斷開連接時，需要四次握手，這里稱為四次揮手。

斷開連接請求可以由客戶端發出，也可以由服務器端發出，在這里我們稱A端向B端請求斷開連接。

第一次揮手

A端向B端請求斷開連接時會向B端發送一個帶有FIN標記的報文段，這里的FIN是FINish的意思。

第二次揮手

B端收到A發送的FIN后，B段現在可能現在還有數據沒有傳完，所以B端并不會馬上向A端發送FIN，而是先發送一個確認序號ACK，意思是說“你發的斷開連接請求我收到了，但是我現在還有數據沒有發完，請稍等一下唄”。

第三次揮手

當B端的事情忙完了，那么此時B端就可以斷開連接了，此時B端向A端發送FIN序號，意思是這次可以斷開連接了。

第四次揮手

A端收到B端發送的FIN后，會向B端發送確認ACK，然后經過兩個MSL時長后斷開連接。

MSL是Maximum Segment Lifetime，最大報文段生存時間，2個MSL是報文段發送和接收的最長時間。

四次揮手示意圖如下(純手繪，見諒見諒)：

兩次握手可以么?

TCP連接時是三次握手，那么兩次握手可行嗎?

在《計算機網絡》中是這樣解釋的：已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了。由于現在client并沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送ACK包。這樣就會白白浪費資源。

而經過三次握手，客戶端和服務器都有應有答，這樣可以確保TCP正確連接。

為什么TCP連接是三次，揮手確是四次?

在TCP連接中，服務器端的SYN和ACK向客戶端發送是一次性發送的，而在斷開連接的過程中，B端向A端發送的ACK和FIN是是分兩次發送的。因為在B端接收到A端的FIN后，B端可能還有數據要傳輸，所以先發送ACK，等B端處理完自己的事情后就可以發送FIN斷開連接了。

為什么在第四次揮手后會有2個MSL的延時?

前文說到

MSL是Maximum Segment Lifetime，最大報文段生存時間，2個MSL是報文段發送和接收的最長時間。

假定網絡不可靠，那么第四次發送的ACK可能丟失，即B端無法收到這個ACK，如果B端收不到這個確認ACK，B端會定時向A端重復發送FIN，直到B端收到A的確認ACK。所以這個2MSL就是用來處理這個可能丟失的ACK的。