TCP的三次握手和四次揮手
三次握手
TCP連接是通過三次握手來連接的。
***次握手
當(dāng)客戶端向服務(wù)器發(fā)起連接請求時,客戶端會發(fā)送同步序列標(biāo)號SYN到服務(wù)器,在這里我們設(shè)SYN為m,等待服務(wù)器確認(rèn),這時客戶端的狀態(tài)為SYN_SENT。
第二次握手
當(dāng)服務(wù)器收到客戶端發(fā)送的SYN后,服務(wù)器要做的是確認(rèn)客戶端發(fā)送過來的SYN,在這里服務(wù)器發(fā)送確認(rèn)包ACK,這里的ACK為m+1,意思是說“我收到了你發(fā)送的SYN了”,同時,服務(wù)器也會向客戶端發(fā)送一個SYN包,這里我們設(shè)SYN為n。這時服務(wù)器的狀態(tài)為SYN_RECV。
一句話,服務(wù)器端發(fā)送SYN和ACK兩個包。
第三次握手
客戶端收到服務(wù)器發(fā)送的SYN和ACK包后,需向服務(wù)器發(fā)送確認(rèn)包ACK,“我也收到你發(fā)送的SYN了,我這就給你發(fā)個確認(rèn)過去,然后我們即能合體了”,這里的ACK為n+1,發(fā)送完畢后,客戶端和服務(wù)器的狀態(tài)為ESTABLISH,即TCP連接成功。
在三次握手中,客戶端和服務(wù)器端都發(fā)送兩個包SYN和ACK,只不過服務(wù)器端的兩個包是一次性發(fā)過來的,客戶端的兩個包是分兩次發(fā)送的。
三次握手示意圖如下(純手繪,見諒見諒):
四次揮手
當(dāng)A端和B端要斷開連接時,需要四次握手,這里稱為四次揮手。
斷開連接請求可以由客戶端發(fā)出,也可以由服務(wù)器端發(fā)出,在這里我們稱A端向B端請求斷開連接。
***次揮手
A端向B端請求斷開連接時會向B端發(fā)送一個帶有FIN標(biāo)記的報文段,這里的FIN是FINish的意思。
第二次揮手
B端收到A發(fā)送的FIN后,B段現(xiàn)在可能現(xiàn)在還有數(shù)據(jù)沒有傳完,所以B端并不會馬上向A端發(fā)送FIN,而是先發(fā)送一個確認(rèn)序號ACK,意思是說“你發(fā)的斷開連接請求我收到了,但是我現(xiàn)在還有數(shù)據(jù)沒有發(fā)完,請稍等一下唄”。
第三次揮手
當(dāng)B端的事情忙完了,那么此時B端就可以斷開連接了,此時B端向A端發(fā)送FIN序號,意思是這次可以斷開連接了。
第四次揮手
A端收到B端發(fā)送的FIN后,會向B端發(fā)送確認(rèn)ACK,然后經(jīng)過兩個MSL時長后斷開連接。
MSL是Maximum Segment Lifetime,***報文段生存時間,2個MSL是報文段發(fā)送和接收的最長時間。
四次揮手示意圖如下(純手繪,見諒見諒):
兩次握手可以么?
TCP連接時是三次握手,那么兩次握手可行嗎?
在《計算機(jī)網(wǎng)絡(luò)》中是這樣解釋的:已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下:client發(fā)出的***個連接請求報文段并沒有丟失,而是在某個網(wǎng)絡(luò)結(jié)點(diǎn)長時間的滯留了,以致延誤到連接釋放以后的某個時間才到達(dá)server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后,就誤認(rèn)為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認(rèn)報文段,同意建立連接。假設(shè)不采用“三次握手”,那么只要server發(fā)出確認(rèn),新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求,因此不會理睬server的確認(rèn),也不會向server發(fā)送ACK包。這樣就會白白浪費(fèi)資源。
而經(jīng)過三次握手,客戶端和服務(wù)器都有應(yīng)有答,這樣可以確保TCP正確連接。
為什么TCP連接是三次,揮手確是四次?
在TCP連接中,服務(wù)器端的SYN和ACK向客戶端發(fā)送是一次性發(fā)送的,而在斷開連接的過程中,B端向A端發(fā)送的ACK和FIN是是分兩次發(fā)送的。因?yàn)樵贐端接收到A端的FIN后,B端可能還有數(shù)據(jù)要傳輸,所以先發(fā)送ACK,等B端處理完自己的事情后就可以發(fā)送FIN斷開連接了。
為什么在第四次揮手后會有2個MSL的延時?
前文說到
MSL是Maximum Segment Lifetime,***報文段生存時間,2個MSL是報文段發(fā)送和接收的最長時間。
假定網(wǎng)絡(luò)不可靠,那么第四次發(fā)送的ACK可能丟失,即B端無法收到這個ACK,如果B端收不到這個確認(rèn)ACK,B端會定時向A端重復(fù)發(fā)送FIN,直到B端收到A的確認(rèn)ACK。所以這個2MSL就是用來處理這個可能丟失的ACK的。