圖解TCP通信三次握手和四次分手

2020-02-18 18:56:18

字體：大中小

來源：轉(zhuǎn)載

供稿：網(wǎng)友

這篇文章主要介紹了圖解TCP通信三次握手和四次分手,對正在學(xué)習(xí)TPC通信的同學(xué)會有些幫助,需要的朋友可以參考下

TCP協(xié)議非常重要，這里把它的連接和釋放整理一下。

TCP,三次握手,四次分手

首先是三次握手：

1、客戶端發(fā)起，像服務(wù)器發(fā)送的報文SYN=1，ACK=0，然后選擇了一個初始序號：seq=x。

SYN

在鏈接的時候創(chuàng)建一個同步序號，當(dāng)SYN=1同時ACK=0的時候，表明這是一個連接請求的報文段。如果對方有意鏈接，返回的報文里面SYN=1，ACK=1,。從這個意義上來說，SYN=1的時候，就表明這是一個‘請求’或者‘接受請求’的報文。

SYN=1的報文段不能攜帶數(shù)據(jù)。但是要消耗掉一個序號，

ACK

僅當(dāng)ACK=1的時候，確認字號(期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的編號)才有效。因此，TCP規(guī)定，當(dāng)鏈接建立之后，所有往來的報文里面的ACK都應(yīng)該是1(事實上，也只有客戶端發(fā)起的鏈接請求報文的ACK沒有置1)。

現(xiàn)在的狀態(tài)：客戶端進入SYN-SEND

2、服務(wù)器接收到了SYN=1，ACK=0的請求報文之后，返回一個SYN=1，ACK=1的確認報文。

同時，確認號ack=x+1，同時也為自己選擇一個初始序號seq=y

現(xiàn)在的狀態(tài)：服務(wù)器進入SYN-REVD

3、客戶端接收到了服務(wù)器的返回信息之后，還要給服務(wù)器返回最后一條確認，ACK=1，確認號ack=y+1;

現(xiàn)在的狀態(tài)：客戶端進入ESTABLISHED

下面說一下為什么兩次握手不行，非得三次：

首先說明一種正常的情況

，就是客戶端發(fā)送了一條請求鏈接的報文，但是由于網(wǎng)絡(luò)原因丟失了，所以，不可能接收到服務(wù)器端的確認。這個時候，客戶端就就只有再一次發(fā)送原來的請求報文，這次服務(wù)器收到之后返回確認，客戶端再確認一次，鏈接確立。

然后考慮一種不正常的情況

，客戶端發(fā)了兩次請求鏈接的報文，第二條被服務(wù)器捕捉到，返回數(shù)據(jù)，完成了兩次握手。數(shù)據(jù)傳送完成之后，鏈接關(guān)閉。但是這時候，第一條擁塞的請求報文現(xiàn)在到達了服務(wù)器端，服務(wù)器還以為客戶端要又一次建立連接，于是發(fā)送確認，然后把自己敞開，等著客戶端發(fā)送過來數(shù)據(jù)。于是，很多的網(wǎng)絡(luò)資源就是這樣浪費掉了。

要是實行三次握手，服務(wù)器收到了一條過期的請求報文，返回確認信息，客戶端接收到了服務(wù)器的信息之后感到莫名其妙，心想：我他媽又沒要鏈接，你返回這個是不是瘋了。于是不置一詞。服務(wù)器過一段時間還沒有收到第三次握手的數(shù)據(jù)，知道客戶端并沒有要求建立鏈接的請求，含淚離開。

然后是四次分手：

現(xiàn)在雙方的狀態(tài)都是ESTABLISHED狀態(tài)。

1、客戶端發(fā)起請求，請求斷開鏈接。FIN=1，seq=u。u是之前傳送過來的最后一個字節(jié)的序號+1。

FIN：用來釋放一個鏈接，當(dāng)FIN=1的時候，表明此報文的發(fā)送方已經(jīng)完成了數(shù)據(jù)的發(fā)送，沒有新的數(shù)據(jù)要傳送，并要求釋放鏈接。

客戶端進入FIN-WAIT-1狀態(tài)，等著服務(wù)器返回確認;

2、服務(wù)器收到客戶端的請求斷開鏈接的報文之后，返回確認信息。ACK=1，seq=v，ack=u+1。

服務(wù)器進入CLOSE-WAIT狀態(tài)。

這個時候，客戶端不能給服務(wù)器發(fā)送信息報文，只能接收。但是服務(wù)器要是還有信息要傳給服務(wù)器，仍然能傳送。

3、當(dāng)服務(wù)器也沒有了可以傳的信息之后，給客戶端發(fā)送請求結(jié)束的報文。FIN=1，ACK=1，

ack=u+1，seq=w。

這個時候的狀態(tài)：服務(wù)器進入LAST-ACK狀態(tài)。

4、客戶端接收到FIN=1的報文之后，返回確認報文，ACK=1，seq=u+1，ack=w+1。