TCP協(xié)議三次握手過程

? ? ? ? TCP是主機對主機層的傳輸控制協(xié)議，提供可靠的連接服務(wù)，采用三次握手確認建立一個連接：

　　位碼即tcp標志位，有6種標示：SYN（synchronous建立聯(lián)機） ACK（acknowledgement 確認） PSH（push傳送） FIN（finish結(jié)束） RST（reset重置） URG（urgent緊急）

　　Sequence number（順序號碼） Acknowledge number（確認號碼）

　　第一次握手：主機A發(fā)送位碼為syn＝1，隨機產(chǎn)生seq number=1234567的數(shù)據(jù)包到服務(wù)器，主機B由SYN=1知道，A要求建立聯(lián)機；

　　第二次握手：主機B收到請求后要確認聯(lián)機信息，向A發(fā)送ack number=（主機A的seq+1），syn=1，ack=1，隨機產(chǎn)生seq=7654321的包

　　第三次握手：主機A收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1，以及位碼ack是否為1，若正確，主機A會再發(fā)送ack number=（主機B的seq+1），ack=1，主機B收到后確認seq值與ack=1則連接建立成功。

　　完成三次握手，主機A與主機B開始傳送數(shù)據(jù)。

　　在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個連接。

　　第一次握手：建立連接時，客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認；

　　第二次握手：服務(wù)器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)； 第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認包ACK（ack=k+1），此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成三次握手。 完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)。

　　實例：

　　IP 192.168.1.116.3337 》 192.168.1.123.7788： S 3626544836:3626544836

　　IP 192.168.1.123.7788 》 192.168.1.116.3337： S 1739326486:1739326486 ack 3626544837

　　IP 192.168.1.116.3337 》 192.168.1.123.7788： ack 1739326487，ack 1

　　第一次握手：192.168.1.116發(fā)送位碼syn＝1，隨機產(chǎn)生seq number=3626544836的數(shù)據(jù)包到192.168.1.123，192.168.1.123由SYN=1知道192.168.1.116要求建立聯(lián)機;

　　第二次握手：192.168.1.123收到請求后要確認聯(lián)機信息，向192.168.1.116發(fā)送ack number=3626544837，syn=1，ack=1，隨機產(chǎn)生seq=1739326486的包;

　　第三次握手：192.168.1.116收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1，以及位碼ack是否為1，若正確，192.168.1.116會再發(fā)送ack number=1739326487，ack=1，192.168.1.123收到后確認seq=seq+1，ack=1則連接建立成功。

　　圖解：

　　一個三次握手的過程（圖1，圖2）

　　第一次握手的標志位（圖3）

　　我們可以看到標志位里面只有個同步位，也就是在做請求（SYN）

　　第二次握手的標志位（圖4）

　　我們可以看到標志位里面有個確認位和同步位，也就是在做應(yīng)答（SYN + ACK）

　　第三次握手的標志位（圖5）

　　我們可以看到標志位里面只有個確認位，也就是再做再次確認（ACK）

　　一個完整的三次握手也就是 請求---應(yīng)答---再次確認

　　三次握手的過程分析

　　首先由Client發(fā)出請求連接即 SYN=1 ACK=0 （請看頭字段的介紹）， TCP規(guī)定SYN=1時不能攜帶數(shù)據(jù)，但要消耗一個序號，因此聲明自己的序號是 seq=x

　　然后 Server 進行回復確認，即 SYN=1 ACK=1 seq=y， ack=x+1，

　　再然后 Client 再進行一次確認，但不用SYN 了，這時即為 ACK=1， seq=x+1， ack=y+1.

　　然后連接建立，為什么要進行三次握手呢（兩次確認）。

　 ? ??為什么A 還要發(fā)送一次確認呢？ 這主要是為了防止已失效的連接請求報文段突然又傳送到了B，因而產(chǎn)生錯誤。

　　所謂“已失效的連接請求報文段”是這樣產(chǎn)生的。考慮一種正常情況。A 發(fā)出連接請求，但因連接請求報文丟失而未收到確認。于是A 再重傳一一次連接請求。后來收到了確認，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。A 共發(fā)送了兩個連接請求報文段，其中第一個丟失，第二個到達了B。沒有“已失效的連接請求報文段”。

　　而是在某現(xiàn)假定出現(xiàn)一種異常情況，即A 發(fā)出的第一一個連接請求報文段并沒有丟失，些網(wǎng)絡(luò)結(jié)點長時間滯留了，以致延誤到連接釋放以后的某個時間才到達B。本來這是- 一個早已失效的報文段。但B 收到此失效的連接請求報文段后，就誤認為是A 又發(fā)出一次新的連接請求。于是就向A 發(fā)出確認報文段，同意建立連接。假定不采用三次握手，那么只要B發(fā)出確認，新的連接就建立了。也不會向B 發(fā)送數(shù)

　　由于現(xiàn)在A 并沒有發(fā)出建立連接的請求，因此不會理睬B 的確認，據(jù)。但B 卻以為新的運輸連接已經(jīng)建立了，并一直等待A 發(fā)來數(shù)據(jù)。B 的許多資源就這樣白白浪費了。

　　采用3 次握手的辦法可以防止上述現(xiàn)象的發(fā)生。例如在剛才的情況下，A 不會向B 的確認發(fā)出確認。B 由于收不到確認，就知道A 并沒有要求建立連接。

　　下面是釋放連接的過程：

　　當客戶A 沒有東西要發(fā)送時就要釋放 A 這邊的連接，A會發(fā)送一個報文（沒有數(shù)據(jù)），其中 FIN 設(shè)置為1， 服務(wù)器B收到后會給應(yīng)用程序一個信，這時A那邊的連接已經(jīng)關(guān)閉，即A不再發(fā)送信息（但仍可接收信息）。 A收到B的確認后進入等待狀態(tài)，等待B請求釋放連接， B數(shù)據(jù)發(fā)送完成后就向A請求連接釋放，也是用FIN=1 表示， 并且用 ack = u+1（如圖）， A收到后回復一個確認信息，并進入 TIME_WAIT 狀態(tài)， 等待 2MSL 時間。

　　為什么要等待呢？

　　為了這種情況： B向A發(fā)送 FIN = 1 的釋放連接請求，但這個報文丟失了， A沒有接到不會發(fā)送確認信息， B 超時會重傳，這時A在 WAIT_TIME 還能夠接收到這個請求，這時再回復一個確認就行了。（A收到 FIN = 1 的請求后 WAIT_TIME會重新記時）

　　另外服務(wù)器B存在一個保活狀態(tài)，即如果A突然故障死機了，那B那邊的連接資源什么時候能釋放呢？ 就是?；顣r間到了后，B會發(fā)送探測信息， 以決定是否釋放連接。