0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(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ī)纱尾恍袉??四次不行嗎?然后很多人就解釋?zhuān)绻莾纱危驮鯓釉鯓?,四次,又怎樣怎樣?但這其實(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ò)程是:

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

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

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

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

客戶(hù)端收到服務(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)模式”。這也常被稱(chēng)為四次揮手。

還拿 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)樵诖酥埃p方還處于合作的狀態(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 專(zhuān)門(mén)設(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):建立連接順序;

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

加粗實(shí)線:客戶(hù)端 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)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(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

    文章

    252

    瀏覽量

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

    關(guān)注

    8

    文章

    1324

    瀏覽量

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

    關(guān)注

    2

    文章

    489

    瀏覽量

    27395
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    深度解析TCP與UDP協(xié)議

    據(jù)傳輸之前,TCP要求雙方通過(guò)三次握手過(guò)程建立穩(wěn)固的連接,確保數(shù)據(jù)傳輸?shù)臏?zhǔn)確性。當(dāng)數(shù)據(jù)傳輸完畢,雙方需要通過(guò)四次揮手過(guò)程關(guān)閉連接,確保資源得
    的頭像 發(fā)表于 09-02 14:53 ?181次閱讀
    深度<b class='flag-5'>解析</b><b class='flag-5'>TCP</b>與UDP<b class='flag-5'>協(xié)議</b>

    簡(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 ?250次閱讀

    說(shuō)說(shuō)TCP三次握手的過(guò)程?為什么是三次而不是兩、四次

    三次而不是兩四次。 首先,我們需要了解TCP是一種面向連接的協(xié)議。在進(jìn)行數(shù)據(jù)傳輸之前,發(fā)送端和接收端需要建立一個(gè)可靠的連接。
    的頭像 發(fā)表于 02-04 11:03 ?443次閱讀

    tcp協(xié)議四次揮手過(guò)程及原因

    TCP協(xié)議致力于可靠的數(shù)據(jù)傳輸,即使在連接關(guān)閉時(shí)也不例外。在關(guān)閉連接之前,雙方需要確保對(duì)方已經(jīng)接收到了所有的數(shù)據(jù),以避免數(shù)據(jù)丟失或不完整。
    的頭像 發(fā)表于 02-03 16:51 ?3730次閱讀
    <b class='flag-5'>tcp</b><b class='flag-5'>協(xié)議</b><b class='flag-5'>四次</b><b class='flag-5'>揮手</b>過(guò)程及原因

    TCP協(xié)議連接的三次握手

    通過(guò)三次握手,客戶(hù)端與服務(wù)端能夠確保彼此的網(wǎng)絡(luò)連接是可用的??蛻?hù)端發(fā)起的SYN報(bào)文和服務(wù)端返回的SYN+ACK報(bào)文都包含了對(duì)方的初始序列號(hào)和通信能力信息,通過(guò)互相確認(rèn)這些信息,雙方確認(rèn)彼此的能力和正確性。
    的頭像 發(fā)表于 02-03 16:44 ?1200次閱讀
    <b class='flag-5'>TCP</b><b class='flag-5'>協(xié)議</b>連接的<b class='flag-5'>三次</b><b class='flag-5'>握手</b>

    TCP和UDP協(xié)議有什么區(qū)別?如何通過(guò)網(wǎng)關(guān)實(shí)現(xiàn)TCP協(xié)議通信?

    四次握手就是指斷開(kāi)的過(guò)程。而UDP可以立即傳輸數(shù)據(jù),并不需要建立三次握手連接。兩者相比,TCP就像是掛了專(zhuān)家號(hào),可以保證及時(shí)看?。欢鳸DP就
    的頭像 發(fā)表于 01-24 11:07 ?464次閱讀
    <b class='flag-5'>TCP</b>和UDP<b class='flag-5'>協(xié)議</b>有什么區(qū)別?如何通過(guò)網(wǎng)關(guān)實(shí)現(xiàn)<b class='flag-5'>TCP</b><b class='flag-5'>協(xié)議</b>通信?

    淺談TCP三次握手四次揮手

    在計(jì)算機(jī)網(wǎng)絡(luò)的基本概念中,分層次的體系結(jié)構(gòu)是最基本的。計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)的抽象概念較多,在學(xué)習(xí)時(shí)要多思考。這些概念對(duì)后面的學(xué)習(xí)很有幫助。
    的頭像 發(fā)表于 01-03 13:40 ?645次閱讀
    淺談<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四次揮手過(guò)程分析

    TCP 連接是全雙工的,雙方可以同時(shí)發(fā)送和接收數(shù)據(jù)。第一客戶(hù)端發(fā)送 FIN 報(bào)文后只表示它不再發(fā)送數(shù)據(jù),但還是能接受數(shù)據(jù)。服務(wù)端接收到 FIN 報(bào)文,回一個(gè) ACK 應(yīng)答報(bào)文,這次服務(wù)端可以還有數(shù)據(jù)需要處理和發(fā)送,等它處理完成
    的頭像 發(fā)表于 12-10 15:40 ?2686次閱讀
    <b class='flag-5'>TCP</b><b class='flag-5'>四次</b><b class='flag-5'>揮手</b>過(guò)程分析

    關(guān)于TCP協(xié)議總結(jié)的硬核干貨

    本文給出TCP報(bào)文格式的詳細(xì)說(shuō)明,介紹網(wǎng)絡(luò)數(shù)據(jù)包傳遞中如何進(jìn)行地址解析、建立TCP連接的三次握手
    發(fā)表于 11-17 09:26 ?396次閱讀
    關(guān)于<b class='flag-5'>TCP</b><b class='flag-5'>協(xié)議</b>總結(jié)的硬核干貨

    TCP的長(zhǎng)連接和短連接

    TCP在真正開(kāi)始進(jìn)行數(shù)據(jù)傳輸之前,Server 和 Client 之間必須建立一個(gè)連接。當(dāng)數(shù)據(jù)傳輸完成后,雙方不再需要這個(gè)連接時(shí),就可以釋放這個(gè)連接。 TCP連接的建立是通過(guò)三次握手,
    的頭像 發(fā)表于 11-13 10:46 ?855次閱讀

    TCP通信過(guò)程詳解

    握手的,而釋放則需要4揮手,所以說(shuō)每個(gè)連接的建立都是需要資源消耗和時(shí)間消耗的 經(jīng)典的三次握手示意圖: 經(jīng)典的
    的頭像 發(fā)表于 11-09 14:39 ?950次閱讀
    <b class='flag-5'>TCP</b>通信過(guò)程詳解

    TCP三次握手的理論知識(shí)

    關(guān)于TCP三次握手的理論知識(shí),往上一搜一大片,本文就跳過(guò)理論,直接上手。Let’s go。 準(zhǔn)備知識(shí) 抓一個(gè)TCP三次
    的頭像 發(fā)表于 11-09 11:27 ?608次閱讀
    <b class='flag-5'>TCP</b><b class='flag-5'>三次</b><b class='flag-5'>握手</b>的理論知識(shí)

    TCP協(xié)議詳細(xì)解析

    TCPTCP/IP協(xié)議族中一個(gè)最核心的協(xié)議,它向下使用網(wǎng)絡(luò)層IP協(xié)議,向上為應(yīng)用層HTTP、F
    的頭像 發(fā)表于 11-03 09:14 ?3587次閱讀
    <b class='flag-5'>TCP</b><b class='flag-5'>協(xié)議</b>詳細(xì)<b class='flag-5'>解析</b>

    TCP連接的建立與中止

    常重要的 。 TCP 連接的建立可以簡(jiǎn)單地稱(chēng)為三次握手,而連接的中止則可以稱(chēng)為四次揮手。 建立連接 TC
    的頭像 發(fā)表于 10-08 16:52 ?631次閱讀

    TCP協(xié)議如何優(yōu)化

    TCP/IP協(xié)議經(jīng)常在面試中會(huì)被問(wèn)到,基礎(chǔ)的會(huì)問(wèn)三次握手四次揮手,更深一點(diǎn)可能會(huì)問(wèn)
    的頭像 發(fā)表于 10-08 15:15 ?1224次閱讀
    <b class='flag-5'>TCP</b><b class='flag-5'>協(xié)議</b>如何優(yōu)化