一区二区三区三上|欧美在线视频五区|国产午夜无码在线观看视频|亚洲国产裸体网站|无码成年人影视|亚洲AV亚洲AV|成人开心激情五月|欧美性爱内射视频|超碰人人干人人上|一区二区无码三区亚洲人区久久精品

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

網(wǎng)絡(luò)協(xié)議:TCP的三次握手,四次揮手技術(shù)解析

454398 ? 來(lái)源:博客園 ? 作者:北國(guó)丶風(fēng)光 ? 2020-10-26 15:28 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

TCP 包頭格式

老規(guī)矩,咱們先來(lái)看看 TCP 頭的格式。

從上面這個(gè)圖可以看出,它比 UDP 要復(fù)雜的多。而復(fù)雜的地方,也正是它為了解決 UDP 存在的問(wèn)題所必需的字段。

首先,源端口號(hào)和目標(biāo)端口號(hào)是兩者都有,不可缺少的字段。

接下來(lái)是包的序號(hào)。給包編號(hào)就是為了解決亂序的問(wèn)題。老大哥做事,穩(wěn)重為主,一件件來(lái),面臨再?gòu)?fù)雜的情況,也臨危不亂。

除了發(fā)送端需要給包編號(hào)外,接收方也會(huì)回復(fù)確認(rèn)序號(hào)。做事靠譜,答應(yīng)了就要做到,暫時(shí)做不到也要給個(gè)回復(fù)。

這里要注意的是,TCP 是個(gè)老大哥沒(méi)錯(cuò),但不能說(shuō)他一定會(huì)保證傳輸準(zhǔn)確無(wú)誤的完成。從 IP 層面來(lái)講,如果網(wǎng)絡(luò)的確那么差,是沒(méi)有任何可靠性保證的,即使 TCP 老大哥再穩(wěn),他也管不了 IP 層丟包,他只能盡可能的保證在他的層面上的可靠性。

然后是一些狀態(tài)位。有以下常見(jiàn)狀態(tài)位:

SYN(Synchronize Sequence Numbers,同步序列編號(hào)):發(fā)起一個(gè)連接

ACK(Acknowledgement,確認(rèn)字符):回復(fù)

RST(Connection reset):重新連接

FIN:結(jié)束連接

從這些狀態(tài)位就可以看出,TCP 基于“性惡論”,警覺(jué)性就很高,不像 UDP 和小朋友似的,隨便一個(gè)不認(rèn)識(shí)的小朋友都能玩到一起,他與別人的信任要經(jīng)過(guò)多次交互才能建立。

還有一個(gè)窗口大小。這個(gè)是 TCP 用來(lái)進(jìn)行流量控制的。通信雙方各聲明一個(gè)窗口,標(biāo)識(shí)自己當(dāng)前的處理能力,讓發(fā)送端別發(fā)送的太快,要不然撐死接收端。也不能發(fā)送的太慢,要不然就餓死接收端了。

根據(jù)上述對(duì) TCP 頭的分析,我們知道對(duì)于 TCP 協(xié)議要重點(diǎn)關(guān)注以下幾個(gè)問(wèn)題:

  • 順序問(wèn)題,穩(wěn)重不亂;
  • 丟包問(wèn)題,承諾靠譜;
  • 連接偉豪,有始有終;
  • 流量控制,把握分寸;
  • 擁塞控制,知進(jìn)知退。

TCP 的三次握手

了解完 TCP 頭,我們就來(lái)看下 TCP 建立連接的過(guò)程,這就是著名的“三次握手”。

三次握手,過(guò)程是這樣子的:

A:你好,我是 A(SYN)。

B:你好 A,我是 B(SYN,ACK)。

A:你好 B(ACK 的 ACK)。

著重記憶上述過(guò)程,后續(xù)很多分析都是基于這個(gè)過(guò)程來(lái)的。

記得剛接觸三次握手的時(shí)候,就一直很納悶,為啥一定要三次??jī)纱尾恍袉??四次不行嗎?然后很多人就解釋,如果是兩次,就怎樣怎樣,四次,又怎樣怎樣?但這其實(shí)都是從結(jié)果推原因,沒(méi)有說(shuō)明本質(zhì)。

我們應(yīng)該知道,握手是為了建立穩(wěn)定的連接,這個(gè)是最終目的。而要達(dá)到這個(gè)目的,就要通信雙方的交互形成一個(gè)確認(rèn)的閉環(huán)。

拿上述 A、B 通信的例子來(lái)看,A 給 B 發(fā)信息,B 要告訴 A 他收到信息了。這時(shí)候,算是一個(gè)確認(rèn)閉環(huán)嗎?明顯不是,因?yàn)?B 沒(méi)有收到來(lái)自 A 的確認(rèn)信息。

所以,要達(dá)到我們上述的目標(biāo),還要 A 給 B 一個(gè)確認(rèn)信息,這樣就形成了一個(gè)確認(rèn)閉環(huán)。

A 給 B 的確認(rèn)信息發(fā)出后,遇到網(wǎng)絡(luò)不好的情況,也會(huì)出現(xiàn)丟包的情況。按理來(lái)說(shuō),還應(yīng)該有個(gè)回應(yīng),但是,我們發(fā)現(xiàn),好像這樣下去就沒(méi)玩沒(méi)了啦。

所以,我們說(shuō),只要通信雙方形成一個(gè)確認(rèn)閉環(huán)后,就認(rèn)為連接已建立。一旦連接建立,A 會(huì)馬上發(fā)送數(shù)據(jù),而 A 發(fā)送數(shù)據(jù),后續(xù)的很多問(wèn)題都得到了解決。

例如 A 發(fā)給 B 的確認(rèn)消息丟了,當(dāng) A 后續(xù)發(fā)送的數(shù)據(jù)到達(dá)的時(shí)候,B 可以認(rèn)為這個(gè)連接已經(jīng)建立。如果 B 直接掛了,A 發(fā)送的數(shù)據(jù)就會(huì)報(bào)錯(cuò),說(shuō) B 不可達(dá),這樣,A 也知道 B 出事情了。

三次握手除了通信雙方建立連接外,主要還是為了溝通 TCP 包的序號(hào)問(wèn)題。

A 要告訴 B,我發(fā)起的包的序號(hào)起始是從哪個(gè)號(hào)開(kāi)始的,B 也要告訴 A,B 發(fā)起的包的序號(hào)的起始號(hào)。

TCP 包的序號(hào)是會(huì)隨時(shí)間變化的,可以看成一個(gè) 32 位的計(jì)數(shù)器,每 4ms 加一。計(jì)算一下,這樣到出現(xiàn)重復(fù)號(hào),需要 4 個(gè)多小時(shí)。但是,4 個(gè)小時(shí)后,還沒(méi)到達(dá)目的地的包早就死翹翹了。這是因?yàn)?IP 包頭里的 TTL(生存時(shí)間)。

為什么序號(hào)不能從 1 開(kāi)始呢?因?yàn)檫@樣會(huì)很容易出現(xiàn)沖突。

例如,A 連上 B 之后,發(fā)送了 1、2、3 三個(gè)包,但是發(fā)送 3 的時(shí)候,中間丟了,或者繞路了,于是重新發(fā)送,后來(lái) A 掉線了,重新連上 B 后,序號(hào)又從 1 開(kāi)始,然后發(fā)送 2,但是壓根沒(méi)想發(fā)送 3,而如果上次繞路的那個(gè) 3 剛好又回來(lái)了,發(fā)給了 B ,B 自然就認(rèn)為,這就是下一包,于是發(fā)生了錯(cuò)誤。

就這樣,雙方歷經(jīng)千辛萬(wàn)苦,終于建立了連接。前面也說(shuō)過(guò),為了維護(hù)這個(gè)連接,雙方都要維護(hù)一個(gè)狀態(tài)機(jī),在連接建立的過(guò)程中,雙方的狀態(tài)變化時(shí)序圖就像下面這樣:

整體過(guò)程是:

客戶端和服務(wù)端都處于 CLOSED 狀態(tài);

服務(wù)端主動(dòng)監(jiān)聽(tīng)某個(gè)端口,處于 LISTEN 狀態(tài);

客戶端主動(dòng)發(fā)起連接 SYN,處于 SYN-SENT 狀態(tài)。

服務(wù)端收到客戶端發(fā)起的連接,返回 SYN,并且 ACK 客戶端的 SYN,處于 SYN-RCVD 狀態(tài);

客戶端收到服務(wù)端發(fā)送的 SYN 和 ACK 之后,發(fā)送 ACK 的 ACK,處于 ESTABLISHED 狀態(tài);

服務(wù)端收到 ACK 的 ACK 之后,處于 ESTABLISHED 狀態(tài)。

TCP 的四次揮手

說(shuō)完了連接,接下來(lái)就來(lái)了解下 TCP 的“再見(jiàn)模式”。這也常被稱為四次揮手。

還拿 A 和 B 舉例,揮手過(guò)程:

A:B 啊,我不想和你玩了。

B:哦,你不想玩了啊,我知道了。這個(gè)時(shí)候,還只是 A 不想玩了,就是說(shuō) A 不會(huì)再發(fā)送數(shù)據(jù),但是 B 此時(shí)還沒(méi)做完自己的事情,還是可以發(fā)送數(shù)據(jù)的,所以此時(shí)的 B 處于半關(guān)閉狀態(tài)。

B:A啊,好吧,我也不想和你玩了,拜拜。

A:好的,拜拜。

這樣這個(gè)連接就關(guān)閉了。看起來(lái)過(guò)程很順利,是的,這是通信雙方“和平分手”的場(chǎng)面。

A 開(kāi)始說(shuō)“不玩了”,B 說(shuō)“知道了”,這個(gè)回合,是沒(méi)什么問(wèn)題的,因?yàn)樵诖酥?,雙方還處于合作的狀態(tài)。

如果 A 說(shuō)“不玩了”,沒(méi)有收到回復(fù),那么 A 會(huì)重新發(fā)送“不玩了”。但是這個(gè)回合結(jié)束之后,就很可能出現(xiàn)異常情況了,因?yàn)橛幸环铰氏人浩颇?。這種撕破臉有兩種情況。

一種情況是,A 說(shuō)完“不玩了”之后,A 直接跑路,這是會(huì)有問(wèn)題的,因?yàn)?B 還沒(méi)有發(fā)起結(jié)束,而如果 A 直接跑路,B 就算發(fā)起結(jié)束,也得不到回答,B 就就不知道該怎么辦了。

另一種情況是,A 說(shuō)完“不玩了”,B 直接跑路。這樣也是有問(wèn)題的,因?yàn)?A 不知道 B 是還有事情要處理,還是過(guò)一會(huì)發(fā)送結(jié)束。

為了解決這些問(wèn)題,TCP 專門設(shè)計(jì)了幾個(gè)狀態(tài)來(lái)處理這些問(wèn)題。接下來(lái),我們就來(lái)看看斷開(kāi)連接時(shí)的狀態(tài)時(shí)序圖。

整體過(guò)程是:

A 說(shuō)“不玩了”,就進(jìn)入 FIN_WAIT_1 狀態(tài);

B 收到 “A 不玩”的消息后,回復(fù)“知道了”,就進(jìn)入 CLOSE_WAIT 狀態(tài);

A 收到“B 說(shuō)知道了”,進(jìn)入 FIN_WAIT_2 狀態(tài)。這時(shí)候,如果B 直接跑路,則 A 將永遠(yuǎn)在這個(gè)狀態(tài)。TCP 協(xié)議里面并沒(méi)有對(duì)這個(gè)狀態(tài)的處理,但是 Linux 有,可以調(diào)整 tcp_fin_timeout 這個(gè)參數(shù),設(shè)置一個(gè)超時(shí)時(shí)間;

B 沒(méi)有跑路,發(fā)送了“B 也不玩了”的消息,處于 LAST_ACK 狀態(tài);

A 收到“B 說(shuō)不玩了”的消息,回復(fù)“A 知道 B 也不玩了”的消息后,從 FINE_WAIT_2 狀態(tài)結(jié)束。

最后一個(gè)步驟里,如果 A 直接跑路了,也會(huì)出現(xiàn)問(wèn)題。因?yàn)?A 的最后一個(gè)回復(fù),B 如果沒(méi)有收到的話就會(huì)重復(fù)第 4 步,但是因?yàn)?A 已經(jīng)跑路了,所以 B 會(huì)一直重復(fù)第 4 步。

因此,TCP 協(xié)議要求 A 最后要等待一段時(shí)間,這個(gè)等待時(shí)間是 TIME_WAIT,這個(gè)時(shí)間要足夠長(zhǎng),長(zhǎng)到如果 B 沒(méi)收到 A 的回復(fù),B 重發(fā)給 A,A 的回復(fù)要有足夠時(shí)間到達(dá) B。

A 直接跑路還有一個(gè)問(wèn)題是,A 的端口就空出來(lái)了,但是 B 不知道,B 原來(lái)發(fā)過(guò)的很多包可能還在路上,如果 A 的端口被新的應(yīng)用占用了,這個(gè)新的應(yīng)用會(huì)受到上個(gè)連接中 B 發(fā)過(guò)來(lái)的包,雖然序列號(hào)是重新生成的,但是這里會(huì)有一個(gè)雙保險(xiǎn),防止產(chǎn)生混亂。因此也需要 A 等待足夠長(zhǎng)的時(shí)間,等到 B 發(fā)送的所有未到的包都“死翹翹”,再空出端口。

這個(gè)等待的時(shí)間設(shè)為 2MSL,MSL 是Maximum Segment Lifetime,即報(bào)文最大生存時(shí)間。它是任何報(bào)文再網(wǎng)絡(luò)上存在的最長(zhǎng)時(shí)間,超過(guò)這個(gè)時(shí)間的報(bào)文就會(huì)被丟棄。

因?yàn)?TCP 報(bào)文基于 IP 協(xié)議,而 IP 頭中有一個(gè) TTL 域,是 IP 數(shù)據(jù)報(bào)可以經(jīng)過(guò)的最大路有數(shù),每經(jīng)過(guò)一個(gè)處理他的路由器,此值就減 1,當(dāng)此值為 0 時(shí),數(shù)據(jù)報(bào)就被丟棄,同時(shí)發(fā)送 ICMP 報(bào)文通知源主機(jī)。協(xié)議規(guī)定 MSL 為 2 分鐘,實(shí)際應(yīng)用中常用的是 30 秒、1分鐘和 2 分鐘等。

還有一種異常情況,B 超過(guò)了 2MS 的時(shí)間,依然沒(méi)有收到它發(fā)的 FIN 的 ACK。按照 TCP 的原理,B 當(dāng)然還會(huì)重發(fā) FIN,這個(gè)時(shí)候 A 再收到這個(gè)包之后,就表示,我已經(jīng)等你這么久,算是仁至義盡了,再來(lái)的數(shù)據(jù)包我就不認(rèn)了,于是直接發(fā)送 RST,這樣 B 就知道 A 跑路了。

TCP 狀態(tài)機(jī)

將連接建立和連接斷開(kāi)的兩個(gè)時(shí)序狀態(tài)圖綜合起來(lái),就是著名的TCP 狀態(tài)機(jī)。我們可以將這個(gè)狀態(tài)機(jī)和時(shí)序狀態(tài)機(jī)對(duì)照看,就會(huì)更加明了。

圖中加黑加粗部分,是上面說(shuō)到的主要流程,相關(guān)說(shuō)明:

阿拉伯?dāng)?shù)字序號(hào):建立連接順序;

大寫中文數(shù)字序號(hào):斷開(kāi)連接順序;

加粗實(shí)線:客戶端 A 的狀態(tài)變遷;

加粗虛線:服務(wù)端 B 的狀態(tài)變遷;

總結(jié)

TCP 包頭很復(fù)雜,主要關(guān)注 5 個(gè)問(wèn)題。順序問(wèn)題、丟包問(wèn)題、連接維護(hù)、流量控制、擁塞控制;

建立連接三次握手,斷開(kāi)連接四次揮手,狀態(tài)圖要牢記。
編輯:hfy

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 網(wǎng)絡(luò)協(xié)議

    關(guān)注

    3

    文章

    273

    瀏覽量

    22087
  • TCP
    TCP
    +關(guān)注

    關(guān)注

    8

    文章

    1402

    瀏覽量

    80985
  • 狀態(tài)機(jī)
    +關(guān)注

    關(guān)注

    2

    文章

    493

    瀏覽量

    28223
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    TCP三次握手四次揮手,這樣解釋太通俗易懂了!

    TCP連接的建立和釋放分別通過(guò)“三次握手”和“四次揮手”來(lái)完成。三次
    的頭像 發(fā)表于 04-24 19:33 ?751次閱讀
    <b class='flag-5'>TCP</b><b class='flag-5'>三次</b><b class='flag-5'>握手</b>和<b class='flag-5'>四次</b><b class='flag-5'>揮手</b>,這樣解釋太通俗易懂了!

    一文看懂TCP三次握手工作原理

    的那樣云山霧繞。為了實(shí)現(xiàn)可靠數(shù)據(jù)傳輸,?TCP 協(xié)議的通信雙方, 都必須維護(hù)一個(gè)序列號(hào), 以標(biāo)識(shí)發(fā)送出去的數(shù)據(jù)包中, 哪些是已經(jīng)被對(duì)方收到的。三次握手的過(guò)程即是通信雙方相互告知序列號(hào)起
    的頭像 發(fā)表于 01-09 10:19 ?1319次閱讀
    一文看懂<b class='flag-5'>TCP</b><b class='flag-5'>三次</b><b class='flag-5'>握手</b>工作原理

    如何監(jiān)測(cè)TCP三次握手過(guò)程

    在計(jì)算機(jī)網(wǎng)絡(luò)中,傳輸控制協(xié)議TCP)是確保數(shù)據(jù)可靠傳輸?shù)年P(guān)鍵協(xié)議之一。TCP通過(guò)三次
    的頭像 發(fā)表于 01-06 09:20 ?763次閱讀

    TCP三次握手與負(fù)載均衡的配置

    在計(jì)算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它通過(guò)三次
    的頭像 發(fā)表于 01-06 09:15 ?554次閱讀

    TCP三次握手如何影響網(wǎng)絡(luò)性能

    在計(jì)算機(jī)網(wǎng)絡(luò)中,TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它通過(guò)三次握手過(guò)程來(lái)建立兩個(gè)
    的頭像 發(fā)表于 01-06 09:13 ?639次閱讀

    TCP三次握手的常見(jiàn)問(wèn)題及解決方案

    TCP三次握手(Three-way Handshake)是TCP(傳輸控制協(xié)議)建立連接時(shí)的一個(gè)過(guò)程,它確保了兩個(gè)端點(diǎn)在開(kāi)始通信之前都準(zhǔn)備好
    的頭像 發(fā)表于 01-06 09:11 ?1234次閱讀

    TCP三次握手與連接建立的關(guān)系

    在計(jì)算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它負(fù)責(zé)在兩個(gè)主機(jī)之間建立、維護(hù)和終止連接,確保數(shù)據(jù)的可靠傳輸。
    的頭像 發(fā)表于 01-06 09:09 ?730次閱讀

    TCP三次握手的步驟詳解

    1.TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。在兩個(gè)主機(jī)之間建立通信之前,必須通過(guò)三次握手過(guò)程來(lái)建立一個(gè)穩(wěn)定的連接。這個(gè)過(guò)程確保了兩個(gè)端點(diǎn)都準(zhǔn)備好發(fā)送和接收數(shù)據(jù)。 2
    的頭像 發(fā)表于 01-06 09:07 ?937次閱讀

    TCP三次握手網(wǎng)絡(luò)抓包分析

    在計(jì)算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。TCP通過(guò)
    的頭像 發(fā)表于 01-06 09:05 ?713次閱讀

    TCP三次握手安全性分析

    TCP(傳輸控制協(xié)議)的三次握手是建立可靠連接的重要機(jī)制,它確保了通信雙方在數(shù)據(jù)傳輸前的連接狀態(tài)是可靠和準(zhǔn)確的。然而,從安全性的角度來(lái)分析,TCP
    的頭像 發(fā)表于 01-03 18:10 ?1013次閱讀

    TCP三次握手與UDP的區(qū)別

    、連接管理、可靠性、效率等方面有著顯著的區(qū)別。 1. TCP三次握手 TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。在數(shù)據(jù)傳輸
    的頭像 發(fā)表于 01-03 17:35 ?845次閱讀

    TCP三次握手的基本原理

    在計(jì)算機(jī)網(wǎng)絡(luò)中,TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它確保了數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)目煽啃院晚樞蛐浴榱私?/div>
    的頭像 發(fā)表于 01-03 17:25 ?1143次閱讀

    TCP三次握手協(xié)議的作用

    在計(jì)算機(jī)網(wǎng)絡(luò)中,數(shù)據(jù)的傳輸需要在發(fā)送方和接收方之間建立一個(gè)穩(wěn)定的連接,以確保數(shù)據(jù)的完整性和順序。TCP(傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議,它通過(guò)
    的頭像 發(fā)表于 01-03 17:15 ?923次閱讀

    TCP三次握手的詳細(xì)過(guò)程

    TCP(傳輸控制協(xié)議三次握手是一種在互聯(lián)網(wǎng)上建立一個(gè)可靠的、有序的和錯(cuò)誤檢測(cè)能力的連接的方法。這個(gè)過(guò)程確保了兩個(gè)設(shè)備(通常是客戶端和服務(wù)器)在數(shù)據(jù)傳輸開(kāi)始之前能夠相互確認(rèn)對(duì)方的存在和
    的頭像 發(fā)表于 01-03 17:11 ?1194次閱讀

    簡(jiǎn)述TCP協(xié)議三次握手機(jī)制

    TCP(Transmission Control Protocol,傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。它主要用于在IP網(wǎng)絡(luò)中進(jìn)行數(shù)據(jù)傳輸。
    的頭像 發(fā)表于 08-16 10:57 ?2041次閱讀