TCP三次握手&四次揮手
點擊上方藍(lán)色字體，選擇“標(biāo)星公眾號”
優(yōu)質(zhì)文章，第一時間送達(dá)
作者 | EhuoWeirdo
來源 | urlify.cn/f2YR3e
1、TCP概述
網(wǎng)絡(luò)分為IOS七層協(xié)議：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表現(xiàn)層、應(yīng)用層
TCP協(xié)議屬于傳輸層的協(xié)議
1.1TCP數(shù)據(jù)包結(jié)構(gòu)圖
在進(jìn)行握手時，就依賴著結(jié)構(gòu)中的序號和確認(rèn)號
1.2TCP中的標(biāo)識符
SYN：同步標(biāo)志
同步序列編號(
Synchronize Sequence Numbers)欄有效。該標(biāo)志僅在三次握手建立TCP連接時有效。它提示TCP連接的服務(wù)端檢查序列編號，該序列編號為TCP連接初始端(一般是客戶端)的初始序列編號。在這里，可以把TCP序列編號看作是一個范圍從0到4，294，967，295的32位計數(shù)器。通過TCP連接交換的數(shù)據(jù)中每一個字節(jié)都經(jīng)過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個字節(jié)的序列編號
ACK：確認(rèn)標(biāo)志
確認(rèn)編號(
Acknowledgement Number)欄有效。大多數(shù)情況下該標(biāo)志位是置位的。TCP報頭內(nèi)的確認(rèn)編號欄內(nèi)包含的確認(rèn)編號(w+1，F(xiàn)igure-1)為下一個預(yù)期的序列編號，同時提示遠(yuǎn)端系統(tǒng)已經(jīng)成功接收所有數(shù)據(jù)
URG：緊急標(biāo)志
緊急(
The urgent pointer) 標(biāo)志有效，緊急標(biāo)志置位
FIN：結(jié)束標(biāo)志
帶有該標(biāo)志置位的數(shù)據(jù)包用來結(jié)束一個TCP會話，但對應(yīng)端口仍處于開放狀態(tài)，準(zhǔn)備接收后續(xù)數(shù)據(jù)
三次握手Three-way Handshake
2、三次握手
一個虛擬連接的建立是通過三次握手實現(xiàn)的
2.1示意圖
2.2三次握手流程
B的TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸模塊TCB，準(zhǔn)備接受客戶進(jìn)程的連接請求。然后服務(wù)器進(jìn)程就處于
LISTEN（收聽）狀態(tài)，等待客戶的連接請求第一次握手：A的TCP客戶進(jìn)程也是首先創(chuàng)建傳輸控制模塊TCB，然后向B發(fā)出連接請求報文段，此時首部中的同部位
SYN = 1，同時選擇一個初始序號seq = x（這個指令的意思就是告訴B客戶機(jī)自己的序號是多少，要接著這個序號發(fā)送數(shù)據(jù)報）。TCP規(guī)定，SYN報文段（即SYN = 1的報文段）不能攜帶數(shù)據(jù)，但是要消耗一個需要。此時TCP客戶進(jìn)程進(jìn)入SYN-SENT（同步已發(fā)送）狀態(tài)第二次握手：B收到連續(xù)請求報文段后，如同意建立連接，則向A發(fā)送確認(rèn)。在確認(rèn)報文段中應(yīng)把
SYN位和ACK位都置為1，確認(rèn)號是ack = x + 1,同時自己也為自己選擇一個初始序號seq = y。（注意：這個報文段也不能攜帶數(shù)據(jù)，但同樣需要消耗掉一個序號）。這時TCP服務(wù)器進(jìn)程進(jìn)入SYN-REVD（同步收到）狀態(tài)第三次握手：TCP客戶進(jìn)程收到B的確認(rèn)后，還要向B給出確認(rèn)。確認(rèn)報文段的ACK置1，確認(rèn)號
ack = y + 1，而自己的序號seq = x + 1。TCP的標(biāo)準(zhǔn)規(guī)定，ACK報文段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)則不消耗序號，在這種情況下，下一個數(shù)據(jù)報文段的序號仍是seq = x + 1。這時，TCP連接建立，A進(jìn)入ESTABLISHED（已建立連接）狀態(tài)，當(dāng)B收到A的確認(rèn)消息后，也進(jìn)入ESTABLISHED狀態(tài)
注：最后一次握手在默認(rèn)不攜帶數(shù)據(jù)的情況下，由于SYN不是1，是不消耗序列號的。所以三次握手結(jié)束后，客戶端下一個發(fā)送的報文中
seq依舊是x + 1
2.3為什么需要三次握手，而非兩次？
為了實現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方， 都必須維護(hù)一個序列號， 以標(biāo)識發(fā)送出去的數(shù)據(jù)包中， 哪些是已經(jīng)被對方收到的。三次握手的過程即是通信雙方相互告知序列號起始值， 并確認(rèn)對方已經(jīng)收到了序列號起始值的必經(jīng)步驟
如果只是兩次握手， 至多只有連接發(fā)起方的起始序列號能被確認(rèn)， 另一方選擇的序列號則得不到確認(rèn)
3、四次揮手
一個虛擬連接的斷開是通過四次揮手實現(xiàn)的
3.1示意圖：
3.2四次揮手流程：
第一次揮手：A數(shù)據(jù)傳輸關(guān)閉，需要斷開連接，A應(yīng)用進(jìn)程向其TCP發(fā)出連接釋放報文段（
FIN = 1， seq = u），并停止在發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接，進(jìn)入FIN-WAIT-1狀態(tài)，等待B的確認(rèn)第二次揮手：B收到連接釋放報文后即發(fā)出確認(rèn)報文段（
ACK = 1，確認(rèn)號ack = u + 1，序列號seq = v），B進(jìn)入CLOSE-WAIT關(guān)閉等待狀態(tài)，此時的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。而A收到B的確認(rèn)后，進(jìn)入FIN-WAIT-2狀態(tài)，等待B發(fā)出的連接釋放報文段第三次揮手：當(dāng)B數(shù)據(jù)傳輸完畢，B發(fā)出連接釋放報文段（
FIN = 1，ACK = 1，序號seq = u + 1，確認(rèn)號ack = u + 1），B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)，等待A的最后確認(rèn)第四次揮手：A收到B的連接釋放報文段后，對此發(fā)出確認(rèn)報文段（
ACK = 1，seq = u + 1，ack = w + 1），A進(jìn)入TIME-WAIT（時間等待）狀態(tài)，此時TCP未釋放掉，需要經(jīng)過時間等待計時器設(shè)置的時間2MSL后，A才進(jìn)入CLOSE狀態(tài)
3.3為什么A在TIME-WAIT狀態(tài)必須等待2MSL（最大報文生存時間）的時間？
為了保證A發(fā)送的最后一個ACK報文段能夠到達(dá)B，保證A、B正常進(jìn)入CLOSED狀態(tài)
這個ACK報文段有可能丟失，使得處于LAST-ACK狀態(tài)的B收不到對已發(fā)送的FIN+ACK報文段的確認(rèn)，B超時重傳FIN+ACK報文段，A能2MSL時間內(nèi)收到這個重傳的FIN+ACK報文段，接著A重傳一次確認(rèn)，同時重啟2MSL計數(shù)器，2MSL時間后A和B進(jìn)入CLOSE狀態(tài)，如果A在TIME-WAIT狀態(tài)時接收到B的FIN+ACK報文段之后向B發(fā)出確認(rèn)報文段，而不再確認(rèn)B是否收到立即進(jìn)入CLOSED狀態(tài)，如若B并沒有正常收到A 的確認(rèn)報文段，則B無法正正常進(jìn)入到CLOSED狀態(tài)
粉絲福利：Java從入門到入土學(xué)習(xí)路線圖
??????
??長按上方微信二維碼 2 秒
感謝點贊支持下哈 