成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

說(shuō)說(shuō)TCP的三次握手和四次揮手

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理
TCP(Transmission Control Protocol) 傳輸控制協(xié)議,是一種 面向連接的、可靠的、基于字節(jié)流的傳輸層 通信協(xié)議。

[[379162]]

一、傳輸控制協(xié)議TCP簡(jiǎn)介

1.1 簡(jiǎn)介

TCP(Transmission Control Protocol) 傳輸控制協(xié)議,是一種 面向連接的、可靠的、基于字節(jié)流的傳輸層 通信協(xié)議。

TCP是一種面向連接(連接導(dǎo)向)的、可靠的基于字節(jié)流的傳輸層通信協(xié)議。TCP將用戶數(shù)據(jù)打包成報(bào)文段,它發(fā)送后啟動(dòng)一個(gè)定時(shí)器,另一端收到的數(shù)據(jù)進(jìn)行確認(rèn)、對(duì)失序的數(shù)據(jù)重新排序、丟棄重復(fù)數(shù)據(jù)。

TCP把連接作為最基本的對(duì)象,每一條TCP連接都有兩個(gè)端點(diǎn),這種端點(diǎn)我們叫作套接字(socket),將端口號(hào)拼接到IP地址即構(gòu)成了套接字,例如 192.1.1.6:50030

1.2 特點(diǎn)

  • 面向連接的、可靠的、基于字節(jié)流的 傳輸層 通信協(xié)議
  • 將應(yīng)用層的數(shù)據(jù)流分割成文段并發(fā)送給目標(biāo)節(jié)點(diǎn)的TCP層
  • 數(shù)據(jù)包都有序號(hào),對(duì)方收到則發(fā)送ACK確認(rèn),未收到則重傳
  • 使用校驗(yàn)和來(lái)檢驗(yàn)數(shù)據(jù)在傳輸過(guò)程中是否有誤

二、TCP報(bào)文頭


1、源端口(Source Port)/ 目的端口(Destination Port):他們各占2個(gè)字節(jié),標(biāo)示該段報(bào)文來(lái)自哪里(源端口)以及要傳給哪個(gè)上層協(xié)議或應(yīng)用程序(目的端口)。進(jìn)行tcp通信時(shí),一般client是通過(guò)系統(tǒng)自動(dòng)選擇的臨時(shí)端口號(hào),而服務(wù)器一般是使用知名服務(wù)端口號(hào)或者自己指定的端口號(hào) (比如DNS協(xié)議對(duì)應(yīng)端口53,HTTP協(xié)議對(duì)應(yīng)80)

2、序號(hào)(Sequence Number):占據(jù)四個(gè)字節(jié),TCP是面向字節(jié)流的,TCP連接中傳送的字節(jié)流中的每個(gè)字節(jié)都按順序編號(hào),例如如一段報(bào)文的序號(hào)字段值是 107,而攜帶的數(shù)據(jù)共有 100個(gè)字段,如果有下一個(gè)報(bào)文過(guò)來(lái),那么序號(hào)就從 207(100+107)開始,整個(gè)要傳送的字節(jié)流的起始序號(hào)必須要在連接建立時(shí)設(shè)置。首部中的序號(hào)字段值指的是本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)

3、確認(rèn)序號(hào)(Acknowledgment Number):4個(gè)字節(jié),是期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào),若確認(rèn)號(hào)=N,則表明:到序號(hào)N-1為止的所有數(shù)據(jù)都已正確收到,例如:B收到A發(fā)送過(guò)來(lái)的報(bào)文,其序列號(hào)字段是 301,而數(shù)據(jù)長(zhǎng)度是 200字節(jié),這表明了B正確的收到了A到序號(hào) 500(301+200-1)為止的數(shù)據(jù),因此B希望收到A的下一個(gè)數(shù)據(jù)序號(hào)是 501,于是B在發(fā)送給A的確認(rèn)報(bào)文段中,會(huì)把ACK確認(rèn)號(hào)設(shè)置為 501

4、數(shù)據(jù)偏移(Offset):4個(gè)字節(jié)。指出TCP報(bào)文段的數(shù)據(jù)起始處距離報(bào)文段的起始處有多遠(yuǎn),這個(gè)字段實(shí)際上是指出TCP報(bào)文段的首部長(zhǎng)度。由于首部中還有長(zhǎng)度不確定的選項(xiàng)字段,因此數(shù)據(jù)偏移字段是必要的。單位是32位字,也就是4字節(jié),4位二進(jìn)制最大表示15,所以數(shù)據(jù)偏移也就是TCP首部最大60字節(jié)

5、保留(Reserved):6個(gè)字節(jié)。保留域

6、TCP Flags:控制位,由八個(gè)標(biāo)志位組成,每個(gè)標(biāo)志位表示控制的功能,我們主要來(lái)介紹TCP Flags中常用的六個(gè),

  • URG(緊急指針標(biāo)志):當(dāng) URG=1時(shí),表明緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù),應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級(jí)的數(shù)據(jù)),而不要按原來(lái)的排隊(duì)順序來(lái)傳送。例如,已經(jīng)發(fā)送了很長(zhǎng)的一個(gè)程序在主機(jī)上運(yùn)行。但后來(lái)發(fā)現(xiàn)了一些問(wèn)題,需要取消該程序的運(yùn)行。因此用戶從鍵盤發(fā)出中斷命令。如果不使用緊急數(shù)據(jù),那么這兩個(gè)字符將存儲(chǔ)在接收TCP的緩存末尾。只有在所有的數(shù)據(jù)被處理完畢后這兩個(gè)字符才被交付接收方的應(yīng)用進(jìn)程。這樣做就浪費(fèi)了許多時(shí)間
  • ACK(確認(rèn)序號(hào)標(biāo)志):當(dāng) ACK=1時(shí)確認(rèn)號(hào)字段有效。當(dāng) ACK=0時(shí),確認(rèn)號(hào)無(wú)效。TCP規(guī)定,在連接建立后所有的傳送的報(bào)文段都必須把ACK置1
  • PSH(push標(biāo)志):當(dāng)兩個(gè)應(yīng)用進(jìn)程進(jìn)行交互式的通信時(shí),有時(shí)在一端的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能收到對(duì)方的響應(yīng)。在這種情況下,TCP就可以使用推送操作。這時(shí),發(fā)送方TCP把PSH置1,并立即創(chuàng)建一個(gè)報(bào)文段發(fā)送出去。接收方TCP收到PSH=1的報(bào)文段,就盡快地交付接收應(yīng)用進(jìn)程,而不再等到整個(gè)緩存都填滿了后向上交付
  • RST(重置連接標(biāo)志):TCP連接中出現(xiàn)嚴(yán)重差錯(cuò)(如由于主機(jī)崩潰或其他原因),必須釋放連接,然后再重新建立運(yùn)輸連接,可以用來(lái)拒絕一個(gè)非法的報(bào)文段或拒絕打開一個(gè)連接
  • SYN(同步序號(hào),用于建立連接過(guò)程):在連接建立時(shí)用來(lái)同步序號(hào)。當(dāng) SYN=1而ACK=0時(shí),表明這是一個(gè)連接請(qǐng)求報(bào)文段。對(duì)方若同意建立連接,則應(yīng)在相應(yīng)的報(bào)文段中使用 SYN=1和ACK=1。因此,SYN置為1就表示這是一個(gè)連接請(qǐng)求或連接接受保溫。
  • FIN(finish標(biāo)志,用于釋放連接):當(dāng) FIN=1時(shí),表明此報(bào)文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢,并要求釋放運(yùn)輸連接

7、窗口(Window):是TCP流量控制的一個(gè)手段。這里說(shuō)的窗口,指的是接收通告窗口(Receiver Window,RWND)。它告訴對(duì)方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù),這樣就可以控制發(fā)送數(shù)據(jù)的速度

8、檢驗(yàn)和(Checksum):檢驗(yàn)范圍包括首部和數(shù)據(jù)兩部分,由發(fā)送端填充,接收端對(duì)TCP報(bào)文段執(zhí)行CRC算法以檢驗(yàn)TCP報(bào)文段在傳輸過(guò)程中是否損壞。這也是TCP可靠傳輸?shù)囊粋€(gè)重要保障

9、緊急指針(Urgent Pointer):緊急指針僅在URG=1時(shí)才有意義,它指出本報(bào)文段中的緊急數(shù)據(jù)的字節(jié)數(shù)(緊急數(shù)據(jù)結(jié)束后就是普通數(shù)據(jù))。因此,緊急指針指出了緊急數(shù)據(jù)的末尾在報(bào)文段中的位置。當(dāng)所有緊急數(shù)據(jù)都處理完時(shí),TCP就告訴應(yīng)用程序恢復(fù)到正常操作。值得注意的是,即使窗口為零時(shí)也可發(fā)送緊急數(shù)據(jù)。

10、TCP可選項(xiàng)(TCP Options):長(zhǎng)度可變,最長(zhǎng)可達(dá)40字節(jié)。當(dāng)沒(méi)有使用“選項(xiàng)”時(shí),TCP的首部長(zhǎng)度是20字節(jié)。

三、TCP的三次握手

所謂三次握手(Three-Way Handshake)即建立TCP連接,就是指建立一個(gè)TCP連接時(shí),需要客戶端和服務(wù)端總共發(fā)送3個(gè)包以確認(rèn)連接的建立。在socket編程中,這一過(guò)程由客戶端執(zhí)行connect來(lái)觸發(fā),整個(gè)流程如下圖所示:


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

第一次握手: 建立連接時(shí),客戶端發(fā)送SYN包(syn=j)到服務(wù)器,并進(jìn)入SYN_SEND狀態(tài),等待服務(wù)器確認(rèn),SYN:同步序列編號(hào)(Synchronize Sequence Numbers)。

第二次握手: 服務(wù)器收到 SYN 包,必須確認(rèn)客戶的 SYN(ack=j+1),同時(shí)自己也發(fā)送一個(gè)SYN包(syn=k),即SYN+ACK包,此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài);

第三次握手: 客戶端收到服務(wù)器的SYN + ACK包,向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1),此包發(fā)送完畢,客戶端和服務(wù)器進(jìn)入ESTABLISHED(TCP連接成功)狀態(tài),完成三次握手。

3.1 為什么需要三次握手才能建立連接

為了初始化Sequence Number 的初始值,實(shí)現(xiàn)可靠數(shù)據(jù)傳輸, TCP 協(xié)議的通信雙方, 都必須維護(hù)一個(gè)序列號(hào), 以標(biāo)識(shí)發(fā)送出去的數(shù)據(jù)包中, 哪些是已經(jīng)被對(duì)方收到的。三次握手的過(guò)程即是通信雙方相互告知序列號(hào)起始值, 并確認(rèn)對(duì)方已經(jīng)收到了序列號(hào)起始值的必經(jīng)步驟

如果只是兩次握手, 至多只有連接發(fā)起方的起始序列號(hào)能被確認(rèn), 另一方選擇的序列號(hào)則得不到確認(rèn)

3.2 首次握手的隱患——SYN超時(shí)

一、問(wèn)題起因分析:

服務(wù)器收到客戶端的SYN,回復(fù)SYN和ACK的時(shí)候未收到ACK確認(rèn)

服務(wù)器不斷重試直至超時(shí),Linux默認(rèn)等待63秒才斷開連接;(重復(fù)5次【不包括第一次】,從1秒開始,每次重試都翻倍:1+2+4+8+16+32=63秒)

二、針對(duì)SYN Flood的防護(hù)措施:

SYN隊(duì)列滿后,通過(guò)tcp_syncookies參數(shù)會(huì)發(fā)SYN cookie【源端口+目標(biāo)端口+時(shí)間戳組成】

若為正常連接則Client會(huì)回發(fā)SYN Cookie,直接建立連接;

3.3 ?;顧C(jī)制:

當(dāng)我們建立連接后,Client出現(xiàn)故障怎么辦?

向?qū)Ψ桨l(fā)送?;钐綔y(cè)報(bào)文,如果未收到相應(yīng)則繼續(xù)發(fā)送;

嘗試次數(shù)達(dá)到?;钐綔y(cè)數(shù)仍未收到相應(yīng)則中斷連接;

四、TCP的四次揮手

所謂四次揮手(Four-Way Wavehand)即終止TCP連接,就是指斷開一個(gè)TCP連接時(shí),需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開。在socket編程中,這一過(guò)程由客戶端或服務(wù)端任一方執(zhí)行close來(lái)觸發(fā),整個(gè)流程如下圖所示:


由于TCP連接時(shí)全雙工的,因此,每個(gè)方向都必須要單獨(dú)進(jìn)行關(guān)閉,這一原則是當(dāng)一方完成數(shù)據(jù)發(fā)送任務(wù)后,發(fā)送一個(gè)FIN來(lái)終止這一方向的連接,收到一個(gè)FIN只是意味著這一方向上沒(méi)有數(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)閉。

第一次揮手: Client發(fā)送一個(gè)FIN,用來(lái)關(guān)閉Client到Server的數(shù)據(jù)傳送,Client進(jìn)入FINWAIT1狀態(tài)

第二次揮手: Server收到FIN后,發(fā)送一個(gè)ACK給Client,確認(rèn)序號(hào)為收到序號(hào)+1(與SYN相同,一個(gè)FIN占用一個(gè)序號(hào)),Server進(jìn)入CLOSE_WAIT狀態(tài)

第三次揮手: Server發(fā)送一個(gè)FIN,用來(lái)關(guān)閉Server到Client的數(shù)據(jù)傳送,Server進(jìn)入LAST_ACK狀態(tài)

第四次揮手: Client收到FIN后,Client進(jìn)入TIME_WAIT狀態(tài),接著發(fā)送一個(gè)ACK給Server,確認(rèn)序號(hào)為收到序號(hào)+1,Server進(jìn)入CLOSED狀態(tài),完成四次揮手

一、為什么會(huì)有TIME_WAIT狀態(tài)

客戶端連接在收到服務(wù)器的結(jié)束報(bào)文段之后,不會(huì)直接進(jìn)入CLOSED狀態(tài),而是轉(zhuǎn)移到TIME_WAIT狀態(tài)。在這個(gè)狀態(tài),客戶端連接要等待一段長(zhǎng)為2MSL,即兩倍的報(bào)文段最大生存時(shí)間,才能完全關(guān)閉,其原因主要有兩點(diǎn):

確保有足夠的時(shí)間放對(duì)方收到ACK包

避免新舊連接混淆

二、為什么需要四次握手才能斷開連接

因?yàn)門CP連接是全雙工的網(wǎng)絡(luò)協(xié)議,允許同時(shí)通信的雙方同時(shí)進(jìn)行數(shù)據(jù)的收發(fā),同樣也允許收發(fā)兩個(gè)方向的連接被獨(dú)立關(guān)閉,以避免client數(shù)據(jù)發(fā)送完畢,向server發(fā)送FIN關(guān)閉連接,而server還有發(fā)送到client的數(shù)據(jù)沒(méi)有發(fā)送完畢的情況。所以關(guān)閉TCP連接需要進(jìn)行四次握手,每次關(guān)閉一個(gè)方向上的連接需要FIN和ACK兩次握手,發(fā)送發(fā)和接收方都需要FIN報(bào)文和ACK報(bào)文

三、服務(wù)器出現(xiàn)大量CLOSE_WAIT狀態(tài)的原因

是由于對(duì)方關(guān)閉socket連接,我方忙于讀或?qū)?,沒(méi)有及時(shí)關(guān)閉連接

當(dāng)客戶端因?yàn)槟撤N原因先于服務(wù)端發(fā)出了FIN信號(hào),就會(huì)導(dǎo)致服務(wù)端被動(dòng)關(guān)閉,若服務(wù)端不主動(dòng)關(guān)閉socket發(fā)FIN給Client,此時(shí)服務(wù)端Socket會(huì)處于CLOSEWAIT狀態(tài)(而不是LASTACK狀態(tài))。通常來(lái)說(shuō),一個(gè)CLOSEWAIT會(huì)維持至少2個(gè)小時(shí)的時(shí)間(系統(tǒng)默認(rèn)超時(shí)時(shí)間的是7200秒,也就是2小時(shí))。如果服務(wù)端程序因某個(gè)原因?qū)е孪到y(tǒng)造成一堆CLOSEWAIT消耗資源,那么通常是等不到釋放那一刻,系統(tǒng)就已崩潰

解決:1、檢查代碼,特別是釋放資源的代碼 2、檢查配置,特別是處理請(qǐng)求的線程配置

Linux的檢查代碼:

  1. netstat -n|awk '/^tcp/{++S[$NF]}END{for(a in S) print a,S[a]}' 

 

五、總結(jié)

到這里TCP的三次握手四次揮手就講完了,好久都沒(méi)有寫技術(shù)文章了,寫了一下,感覺(jué)還挺好的,上面是博主的認(rèn)識(shí),有寫的不好的地方,大家可以在評(píng)論區(qū)討論或者提問(wèn)。

 

責(zé)任編輯:姜華 來(lái)源: 牧小碼農(nóng)
相關(guān)推薦

2021-05-18 12:27:40

TCP控制協(xié)議

2015-10-13 09:42:52

TCP網(wǎng)絡(luò)協(xié)議

2023-10-24 15:22:09

TCPUDP

2021-05-28 09:08:20

TCP連接序列號(hào)

2024-01-12 08:23:11

TCPACK服務(wù)器

2019-06-12 11:26:37

TCP三次握手四次揮手

2017-09-25 21:27:07

TCP協(xié)議數(shù)據(jù)鏈

2023-03-07 08:38:23

三次握手四次揮手服務(wù)端

2019-02-01 09:38:16

2021-07-03 17:47:25

TCP控制協(xié)議

2020-02-17 10:10:43

TCP三次握手四次揮手

2023-10-28 09:07:57

TCP面試三次握手

2020-06-29 14:50:47

TCP狀態(tài)ACK

2014-09-19 09:46:46

TCPIP

2023-11-01 08:04:08

WiresharkTCP協(xié)議

2015-11-09 09:58:56

2022-11-17 10:20:49

TCP三次握手四次揮手

2025-05-20 08:38:03

2023-10-17 15:44:19

TCP四次揮手

2019-12-13 07:31:04

TCP三次握手四次揮手
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板: 香蕉视频91 | 久久久毛片 | 久久精品亚洲精品国产欧美 | 欧美在线a | 久久久久免费观看 | 国产精品99久久久久久www | 欧美高清hd | 国产原创视频 | 亚洲午夜视频 | 99这里只有精品视频 | 91久久综合亚洲鲁鲁五月天 | 成人亚洲| 亚洲免费人成在线视频观看 | 欧美日韩精品在线免费观看 | 国产精品视频97 | 91视频一区 | 欧美一级黄色网 | 色站综合 | 日韩欧美在线一区二区 | 国产日韩欧美精品一区二区三区 | 欧美成人精品一区 | 欧美九九 | av黄色在线观看 | 久久天堂网 | 色婷婷综合成人av | 亚洲精品一区在线 | 天天躁日日躁aaaa视频 | 精品一区在线免费观看 | 91久久婷婷| 浴室洗澡偷拍一区二区 | 拍拍无遮挡人做人爱视频免费观看 | 欧美视频免费在线 | 涩色视频在线观看 | 国产一级片 | 欧美13videosex性极品 | 激情国产在线 | 成人片免费看 | 欧美久久久久久 | 日韩欧美久久 | 国产乱码久久久 | 国产探花在线精品一区二区 |