TCP三次握手、四次挥手过程及原理
TCP 協(xié)議簡述
TCP 提供面向有連接的通信傳輸,面向有連接是指在傳送數(shù)據(jù)之前必須先建立連接,數(shù)據(jù)傳送完成后要釋放連接。
無論哪一方向另一方發(fā)送數(shù)據(jù)之前,都必須先在雙方之間建立一條連接。在TCP/IP協(xié)議中,TCP協(xié)議提供可靠的連接服務(wù),連接是通過三次握手進(jìn)行初始化的。
同時(shí)由于TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議,TCP是全雙工模式,所以需要四次揮手關(guān)閉連接。
TCP包首部
網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)包由兩部分組成:一部分是協(xié)議所要用到的首部,另一部分是上一層傳過來的數(shù)據(jù)。首部的結(jié)構(gòu)由協(xié)議的具體規(guī)范詳細(xì)定義。在數(shù)據(jù)包的首部,明確標(biāo)明了協(xié)議應(yīng)該如何讀取數(shù)據(jù)。反過來說,看到首部,也就能夠了解該協(xié)議必要的信息以及所要處理的數(shù)據(jù)。包首部就像協(xié)議的臉。
所以我們在學(xué)習(xí)TCP協(xié)議之前,首先要知道TCP在網(wǎng)絡(luò)傳輸中處于哪個(gè)位置,以及它的協(xié)議的規(guī)范,下面我們就看看TCP首部的網(wǎng)絡(luò)傳輸起到的作用:
網(wǎng)絡(luò)數(shù)據(jù)傳輸過程
下面的圖是TCP頭部的規(guī)范定義,它定義了TCP協(xié)議如何讀取和解析數(shù)據(jù):
TCP頭部
TCP首部承載這TCP協(xié)議需要的各項(xiàng)信息,下面我們來分析一下:
TCP端口號(hào)
TCP的連接是需要四個(gè)要素確定唯一一個(gè)連接:
(源IP,源端口號(hào))+ (目地IP,目的端口號(hào))
所以TCP首部預(yù)留了兩個(gè)16位作為端口號(hào)的存儲(chǔ),而IP地址由上一層IP協(xié)議負(fù)責(zé)傳遞
源端口號(hào)和目地端口各占16位兩個(gè)字節(jié),也就是端口的范圍是2^16=65535
另外1024以下是系統(tǒng)保留的,從1024-65535是用戶使用的端口范圍
TCP的序號(hào)和確認(rèn)號(hào):
32位序號(hào) seq:Sequence number 縮寫seq ,TCP通信過程中某一個(gè)傳輸方向上的字節(jié)流的每個(gè)字節(jié)的序號(hào),通過這個(gè)來確認(rèn)發(fā)送的數(shù)據(jù)有序,比如現(xiàn)在序列號(hào)為1000,發(fā)送了1000,下一個(gè)序列號(hào)就是2000。
32位確認(rèn)號(hào) ack:Acknowledge number 縮寫ack,TCP對(duì)上一次seq序號(hào)做出的確認(rèn)號(hào),用來響應(yīng)TCP報(bào)文段,給收到的TCP報(bào)文段的序號(hào)seq加1。
TCP的標(biāo)志位
每個(gè)TCP段都有一個(gè)目的,這是借助于TCP標(biāo)志位選項(xiàng)來確定的,允許發(fā)送方或接收方指定哪些標(biāo)志應(yīng)該被使用,以便段被另一端正確處理。
用的最廣泛的標(biāo)志是 SYN,ACK 和 FIN,用于建立連接,確認(rèn)成功的段傳輸,最后終止連接。
SYN:簡寫為S,同步標(biāo)志位,用于建立會(huì)話連接,同步序列號(hào);
ACK: 簡寫為.,確認(rèn)標(biāo)志位,對(duì)已接收的數(shù)據(jù)包進(jìn)行確認(rèn);
FIN: 簡寫為F,完成標(biāo)志位,表示我已經(jīng)沒有數(shù)據(jù)要發(fā)送了,即將關(guān)閉連接;
PSH:簡寫為P,推送標(biāo)志位,表示該數(shù)據(jù)包被對(duì)方接收后應(yīng)立即交給上層應(yīng)用,而不在緩沖區(qū)排隊(duì);
RST:簡寫為R,重置標(biāo)志位,用于連接復(fù)位、拒絕錯(cuò)誤和非法的數(shù)據(jù)包;
URG:簡寫為U,緊急標(biāo)志位,表示數(shù)據(jù)包的緊急指針域有效,用來保證連接不被阻斷,并督促中間設(shè)備盡快處理;
TCP 三次握手建立連接
所謂三次握手(Three-way Handshake),是指建立一個(gè) TCP 連接時(shí),需要客戶端和服務(wù)器總共發(fā)送3個(gè)報(bào)文。
三次握手的目的是連接服務(wù)器指定端口,建立 TCP 連接,并同步連接雙方的序列號(hào)和確認(rèn)號(hào),交換 TCP 窗口大小信息。在 socket 編程中,客戶端執(zhí)行 connect() 時(shí)。將觸發(fā)三次握手。
三次握手過程的示意圖如下:
三次握手建立連接
第一次握手:
客戶端將TCP報(bào)文標(biāo)志位SYN置為1,隨機(jī)產(chǎn)生一個(gè)序號(hào)值seq=J,保存在TCP首部的序列號(hào)(Sequence Number)字段里,指明客戶端打算連接的服務(wù)器的端口,并將該數(shù)據(jù)包發(fā)送給服務(wù)器端,發(fā)送完畢后,客戶端進(jìn)入SYN_SENT狀態(tài),等待服務(wù)器端確認(rèn)。
第二次握手:
服務(wù)器端收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道客戶端請求建立連接,服務(wù)器端將TCP報(bào)文標(biāo)志位SYN和ACK都置為1,ack=J+1,隨機(jī)產(chǎn)生一個(gè)序號(hào)值seq=K,并將該數(shù)據(jù)包發(fā)送給客戶端以確認(rèn)連接請求,服務(wù)器端進(jìn)入SYN_RCVD狀態(tài)。
第三次握手:
客戶端收到確認(rèn)后,檢查ack是否為J+1,ACK是否為1,如果正確則將標(biāo)志位ACK置為1,ack=K+1,并將該數(shù)據(jù)包發(fā)送給服務(wù)器端,服務(wù)器端檢查ack是否為K+1,ACK是否為1,如果正確則連接建立成功,客戶端和服務(wù)器端進(jìn)入ESTABLISHED狀態(tài),完成三次握手,隨后客戶端與服務(wù)器端之間可以開始傳輸數(shù)據(jù)了。
注意:我們上面寫的ack和ACK,不是同一個(gè)概念:
小寫的ack代表的是頭部的確認(rèn)號(hào)Acknowledge number, 縮寫ack,是對(duì)上一個(gè)包的序號(hào)進(jìn)行確認(rèn)的號(hào),ack=seq+1。
大寫的ACK,則是我們上面說的TCP首部的標(biāo)志位,用于標(biāo)志的TCP包是否對(duì)上一個(gè)包進(jìn)行了確認(rèn)操作,如果確認(rèn)了,則把ACK標(biāo)志位設(shè)置成1。
下面我自己做實(shí)驗(yàn),開一個(gè)HTTP服務(wù),監(jiān)聽80端口,然后使用Tcpdump命令抓包,看一下TCP三次握手的過程:
sudo tcpdump -n -t -S -i enp0s3 port 80
第一次握手,標(biāo)志位Flags=S
IP 10.0.2.2.51323 > 10.0.2.15.80: Flags [S], seq 84689409, win 65535, options [mss 1460], length 0
第二次握手,標(biāo)志位Flags=[S.]
IP 10.0.2.15.80 > 10.0.2.2.51323: Flags [S.], seq 1893430205, ack 84689410, win 64240, options [mss 1460], length 0
第三次握手,標(biāo)志位Flags=[.]
IP 10.0.2.2.51323 > 10.0.2.15.80: Flags [.], ack 1893430206, win 65535, length 0
建立連接后,客戶端發(fā)送http請求
IP 10.0.2.2.51321 > 10.0.2.15.80: Flags [P.], seq 1:753, ack 1, win 65535, length 752: HTTP: GET / HTTP/1.1
tcpdump命令解析一下:
-i : 指定抓包的網(wǎng)卡是enp0s3
-n: 把域名轉(zhuǎn)成IP顯示
-t: 不顯示時(shí)間
-S: 序列號(hào)使用絕對(duì)數(shù)值,不指定-S的話,序列號(hào)會(huì)使用相對(duì)的數(shù)值
port: 指定監(jiān)聽端口是80
host:指定監(jiān)聽的主機(jī)名
我們看下實(shí)戰(zhàn)中TCP的三次握手過程:
第一次握手,客戶端51323端口號(hào)向服務(wù)器端80號(hào)端口發(fā)起連接,此時(shí)標(biāo)志位flags=S,即SYN=1標(biāo)志,表示向服務(wù)端發(fā)起連接的請求,同時(shí)生成序列號(hào)seq=84689409
第二次握手,服務(wù)端標(biāo)志位flags=[S.],即SYN+ACK標(biāo)志位設(shè)置為1,表示對(duì)上一個(gè)請求連接的報(bào)文進(jìn)行確認(rèn),同時(shí)設(shè)置ack=seq+1=184689410,生成序列號(hào)seq=1893430205
第三次握手,客戶端對(duì)服務(wù)端的響應(yīng)進(jìn)行確認(rèn),所以此時(shí)標(biāo)志位是[.]即ACK=1,同時(shí)返回對(duì)上一個(gè)報(bào)文的seq的確認(rèn)號(hào),ack=1893430206
至此,三次握手完成,一個(gè)TCP連接建立完成,接下來就是雙端傳輸數(shù)據(jù)了
為什么需要三次握手?
我們假設(shè)client發(fā)出的第一個(gè)連接請求報(bào)文段并沒有丟失,而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了,以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。
本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請求報(bào)文段后,就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請求。于是就向client發(fā)出確認(rèn)報(bào)文段,同意建立連接。
假設(shè)不采用“三次握手”,那么只要server發(fā)出確認(rèn),新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求,因此不會(huì)理睬server的確認(rèn),也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立,并一直等待client發(fā)來數(shù)據(jù)。這樣,server的很多資源就白白浪費(fèi)掉了。
所以,采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況,client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn),就知道client并沒有要求建立連接。
TCP 三次握手跟現(xiàn)實(shí)生活中的人與人打電話是很類似的:
三次握手:
“喂,你聽得到嗎?”
“我聽得到呀,你聽得到我嗎?”
“我能聽到你,今天 balabala……”
經(jīng)過三次的互相確認(rèn),大家就會(huì)認(rèn)為對(duì)方對(duì)聽的到自己說話,并且愿意下一步溝通,否則,對(duì)話就不一定能正常下去了。
TCP 四次揮手關(guān)閉連接
四次揮手即終止TCP連接,就是指斷開一個(gè)TCP連接時(shí),需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開。在socket編程中,這一過程由客戶端或服務(wù)端任一方執(zhí)行close來觸發(fā)。
由于TCP連接是全雙工的,因此,每個(gè)方向都必須要單獨(dú)進(jìn)行關(guān)閉,這一原則是當(dāng)一方完成數(shù)據(jù)發(fā)送任務(wù)后,發(fā)送一個(gè)FIN來終止這一方向的連接,收到一個(gè)FIN只是意味著這一方向上沒有數(shù)據(jù)流動(dòng)了,即不會(huì)再收到數(shù)據(jù)了,但是在這個(gè)TCP連接上仍然能夠發(fā)送數(shù)據(jù),直到這一方向也發(fā)送了FIN。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉,而另一方則執(zhí)行被動(dòng)關(guān)閉。
四次揮手過程的示意圖如下:
四次揮手關(guān)閉連接
揮手請求可以是Client端,也可以是Server端發(fā)起的,我們假設(shè)是Client端發(fā)起:
第一次揮手: Client端發(fā)起揮手請求,向Server端發(fā)送標(biāo)志位是FIN報(bào)文段,設(shè)置序列號(hào)seq,此時(shí),Client端進(jìn)入FIN_WAIT_1狀態(tài),這表示Client端沒有數(shù)據(jù)要發(fā)送給Server端了。
第二次分手:Server端收到了Client端發(fā)送的FIN報(bào)文段,向Client端返回一個(gè)標(biāo)志位是ACK的報(bào)文段,ack設(shè)為seq加1,Client端進(jìn)入FIN_WAIT_2狀態(tài),Server端告訴Client端,我確認(rèn)并同意你的關(guān)閉請求。
第三次分手: Server端向Client端發(fā)送標(biāo)志位是FIN的報(bào)文段,請求關(guān)閉連接,同時(shí)Client端進(jìn)入LAST_ACK狀態(tài)。
第四次分手 : Client端收到Server端發(fā)送的FIN報(bào)文段,向Server端發(fā)送標(biāo)志位是ACK的報(bào)文段,然后Client端進(jìn)入TIME_WAIT狀態(tài)。Server端收到Client端的ACK報(bào)文段以后,就關(guān)閉連接。此時(shí),Client端等待2MSL的時(shí)間后依然沒有收到回復(fù),則證明Server端已正常關(guān)閉,那好,Client端也可以關(guān)閉連接了。
為什么連接的時(shí)候是三次握手,關(guān)閉的時(shí)候卻是四次握手?
建立連接時(shí)因?yàn)楫?dāng)Server端收到Client端的SYN連接請求報(bào)文后,可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來應(yīng)答的,SYN報(bào)文是用來同步的。所以建立連接只需要三次握手。
由于TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議,TCP是全雙工模式。
這就意味著,關(guān)閉連接時(shí),當(dāng)Client端發(fā)出FIN報(bào)文段時(shí),只是表示Client端告訴Server端數(shù)據(jù)已經(jīng)發(fā)送完畢了。當(dāng)Server端收到FIN報(bào)文并返回ACK報(bào)文段,表示它已經(jīng)知道Client端沒有數(shù)據(jù)發(fā)送了,但是Server端還是可以發(fā)送數(shù)據(jù)到Client端的,所以Server很可能并不會(huì)立即關(guān)閉SOCKET,直到Server端把數(shù)據(jù)也發(fā)送完畢。
當(dāng)Server端也發(fā)送了FIN報(bào)文段時(shí),這個(gè)時(shí)候就表示Server端也沒有數(shù)據(jù)要發(fā)送了,就會(huì)告訴Client端,我也沒有數(shù)據(jù)要發(fā)送了,之后彼此就會(huì)愉快的中斷這次TCP連接。
為什么要等待2MSL?
MSL:報(bào)文段最大生存時(shí)間,它是任何報(bào)文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長時(shí)間。
有以下兩個(gè)原因:
第一點(diǎn):保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉:
由于IP協(xié)議的不可靠性或者是其它網(wǎng)絡(luò)原因,導(dǎo)致了Server端沒有收到Client端的ACK報(bào)文,那么Server端就會(huì)在超時(shí)之后重新發(fā)送FIN,如果此時(shí)Client端的連接已經(jīng)關(guān)閉處于CLOESD狀態(tài),那么重發(fā)的FIN就找不到對(duì)應(yīng)的連接了,從而導(dǎo)致連接錯(cuò)亂,所以,Client端發(fā)送完最后的ACK不能直接進(jìn)入CLOSED狀態(tài),而要保持TIME_WAIT,當(dāng)再次收到FIN的收,能夠保證對(duì)方收到ACK,最后正確關(guān)閉連接。
第二點(diǎn):保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失
如果Client端發(fā)送最后的ACK直接進(jìn)入CLOSED狀態(tài),然后又再向Server端發(fā)起一個(gè)新連接,這時(shí)不能保證新連接的與剛關(guān)閉的連接的端口號(hào)是不同的,也就是新連接和老連接的端口號(hào)可能一樣了,那么就可能出現(xiàn)問題:如果前一次的連接某些數(shù)據(jù)滯留在網(wǎng)絡(luò)中,這些延遲數(shù)據(jù)在建立新連接后到達(dá)Client端,由于新老連接的端口號(hào)和IP都一樣,TCP協(xié)議就認(rèn)為延遲數(shù)據(jù)是屬于新連接的,新連接就會(huì)接收到臟數(shù)據(jù),這樣就會(huì)導(dǎo)致數(shù)據(jù)包混亂。所以TCP連接需要在TIME_WAIT狀態(tài)等待2倍MSL,才能保證本次連接的所有數(shù)據(jù)在網(wǎng)絡(luò)中消失。
總結(jié)
以上是生活随笔為你收集整理的TCP三次握手、四次挥手过程及原理的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: MySQL 乐观锁与悲观锁
- 下一篇: 开源 RPC 框架有哪些呢?