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

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

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

post為什么會(huì)發(fā)送兩次請(qǐng)求?

jf_ro2CN3Fa ? 來(lái)源:CSDN ? 2023-09-25 09:57 ? 次閱讀

前言

最近博主在字節(jié)面試中遇到這樣一個(gè)面試題,這個(gè)問(wèn)題也是前端面試的高頻問(wèn)題,因?yàn)樵谇岸碎_(kāi)發(fā)的日常開(kāi)發(fā)中我們總是會(huì)與post請(qǐng)求打交道,一個(gè)小小的post請(qǐng)求也是牽扯到很多知識(shí)點(diǎn)的,博主在這給大家細(xì)細(xì)道來(lái)。

同源策略

在瀏覽器中,內(nèi)容是很開(kāi)放的,任何資源都可以接入其中,如 JavaScript 文件、圖片、音頻、視頻等資源,甚至可以下載其他站點(diǎn)的可執(zhí)行文件。

但也不是說(shuō)瀏覽器就是完全自由的,如果不加以控制,就會(huì)出現(xiàn)一些不可控的局面,例如會(huì)出現(xiàn)一些安全問(wèn)題,如:

跨站腳本攻擊(XSS)

SQL 注入攻擊

OS 命令注入攻擊

HTTP 首部注入攻擊

跨站點(diǎn)請(qǐng)求偽造(CSRF)

等等…

如果這些都沒(méi)有限制的話(huà),對(duì)于我們用戶(hù)而言,是相對(duì)危險(xiǎn)的,因此需要一些安全策略來(lái)保障我們的隱私和數(shù)據(jù)安全。

這就引出了最基礎(chǔ)、最核心的安全策略:同源策略。

什么是同源策略

同源策略是一個(gè)重要的安全策略,它用于限制一個(gè)源的文檔或者它加載的腳本如何能與另一個(gè)源的資源進(jìn)行交互。

如果兩個(gè) URL 的協(xié)議、主機(jī)和端口都相同,我們就稱(chēng)這兩個(gè) URL 同源。

協(xié)議:協(xié)議是定義了數(shù)據(jù)如何在計(jì)算機(jī)內(nèi)和之間進(jìn)行交換的規(guī)則的系統(tǒng),例如 HTTP、HTTPS。

主機(jī):是已連接到一個(gè)計(jì)算機(jī)網(wǎng)絡(luò)的一臺(tái)電子計(jì)算機(jī)或其他設(shè)備。網(wǎng)絡(luò)主機(jī)可以向網(wǎng)絡(luò)上的用戶(hù)或其他節(jié)點(diǎn)提供信息資源、服務(wù)和應(yīng)用。使用 TCP/IP 協(xié)議族參與網(wǎng)絡(luò)的計(jì)算機(jī)也可稱(chēng)為 IP 主機(jī)。

端口:主機(jī)是計(jì)算機(jī)到計(jì)算機(jī)之間的通信,那么端口就是進(jìn)程到進(jìn)程之間的通信。

如下表給出了與 URL 的源進(jìn)行對(duì)比的示例:

fb754dc8-5a92-11ee-939d-92fbcf53809c.png

同源策略主要表現(xiàn)在以下三個(gè)方面:DOM、Web 數(shù)據(jù)和網(wǎng)絡(luò)。

DOM 訪(fǎng)問(wèn)限制:同源策略限制了網(wǎng)頁(yè)腳本(如 JavaScript)訪(fǎng)問(wèn)其他源的 DOM。這意味著通過(guò)腳本無(wú)法直接訪(fǎng)問(wèn)跨源頁(yè)面的 DOM 元素、屬性或方法。這是為了防止惡意網(wǎng)站從其他網(wǎng)站竊取敏感信息。

Web 數(shù)據(jù)限制:同源策略也限制了從其他源加載的 Web 數(shù)據(jù)(例如 XMLHttpRequest 或 Fetch API)。在同源策略下,XMLHttpRequest 或 Fetch 請(qǐng)求只能發(fā)送到與當(dāng)前網(wǎng)頁(yè)具有相同源的目標(biāo)。這有助于防止跨站點(diǎn)請(qǐng)求偽造(CSRF)等攻擊。

網(wǎng)絡(luò)通信限制:同源策略還限制了跨源的網(wǎng)絡(luò)通信。瀏覽器會(huì)阻止從一個(gè)源發(fā)出的請(qǐng)求獲取來(lái)自其他源的響應(yīng)。這樣做是為了確保只有受信任的源能夠與服務(wù)器進(jìn)行通信,以避免惡意行為。

出于安全原因,瀏覽器限制從腳本內(nèi)發(fā)起的跨源 HTTP 請(qǐng)求,XMLHttpRequest 和 Fetch API,只能從加載應(yīng)用程序的同一個(gè)域請(qǐng)求 HTTP 資源,除非使用 CORS 頭文件

CORS

對(duì)于瀏覽器限制這個(gè)詞,要著重解釋一下:不一定是瀏覽器限制了發(fā)起跨站請(qǐng)求,也可能是跨站請(qǐng)求可以正常發(fā)起,但是返回結(jié)果被瀏覽器攔截了。

瀏覽器將不同域的內(nèi)容隔離在不同的進(jìn)程中,網(wǎng)絡(luò)進(jìn)程負(fù)責(zé)下載資源并將其送到渲染進(jìn)程中,但由于跨域限制,某些資源可能被阻止加載到渲染進(jìn)程。如果瀏覽器發(fā)現(xiàn)一個(gè)跨域響應(yīng)包含了敏感數(shù)據(jù),它可能會(huì)阻止腳本訪(fǎng)問(wèn)這些數(shù)據(jù),即使網(wǎng)絡(luò)進(jìn)程已經(jīng)獲得了這些數(shù)據(jù)。CORB 的目標(biāo)是在渲染之前盡早阻止惡意代碼獲取跨域數(shù)據(jù)。

CORB 是一種安全機(jī)制,用于防止跨域請(qǐng)求惡意訪(fǎng)問(wèn)跨域響應(yīng)的數(shù)據(jù)。渲染進(jìn)程會(huì)在 CORB 機(jī)制的約束下,選擇性地將哪些資源送入渲染進(jìn)程供頁(yè)面使用。

例如,一個(gè)網(wǎng)頁(yè)可能通過(guò) AJAX 請(qǐng)求從另一個(gè)域的服務(wù)器獲取數(shù)據(jù)。雖然某些情況下這樣的請(qǐng)求可能會(huì)成功,但如果瀏覽器檢測(cè)到請(qǐng)求返回的數(shù)據(jù)可能包含惡意代碼或與同源策略沖突,瀏覽器可能會(huì)阻止網(wǎng)頁(yè)訪(fǎng)問(wèn)返回的數(shù)據(jù),以確保用戶(hù)的安全。

跨源資源共享(Cross-Origin Resource Sharing,CORS)是一種機(jī)制,允許在受控的條件下,不同源的網(wǎng)頁(yè)能夠請(qǐng)求和共享資源。由于瀏覽器的同源策略限制了跨域請(qǐng)求,CORS 提供了一種方式來(lái)解決在 Web 應(yīng)用中進(jìn)行跨域數(shù)據(jù)交換的問(wèn)題。

CORS 的基本思想是,服務(wù)器在響應(yīng)中提供一個(gè)標(biāo)頭(HTTP 頭),指示哪些源被允許訪(fǎng)問(wèn)資源。瀏覽器在發(fā)起跨域請(qǐng)求時(shí)會(huì)先發(fā)送一個(gè)預(yù)檢請(qǐng)求(OPTIONS 請(qǐng)求)到服務(wù)器,服務(wù)器通過(guò)設(shè)置適當(dāng)?shù)?CORS 標(biāo)頭來(lái)指定是否允許跨域請(qǐng)求,并指定允許的請(qǐng)求源、方法、標(biāo)頭等信息。

簡(jiǎn)單請(qǐng)求

不會(huì)觸發(fā) CORS 預(yù)檢請(qǐng)求。這樣的請(qǐng)求為 簡(jiǎn)單請(qǐng)求,。若請(qǐng)求滿(mǎn)足所有下述條件,則該請(qǐng)求可視為 簡(jiǎn)單請(qǐng)求:

HTTP 方法限制:只能使用 GET、HEAD、POST 這三種 HTTP 方法之一。如果請(qǐng)求使用了其他 HTTP 方法,就不再被視為簡(jiǎn)單請(qǐng)求。

自定義標(biāo)頭限制:請(qǐng)求的 HTTP 標(biāo)頭只能是以下幾種常見(jiàn)的標(biāo)頭:Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type(僅限于 application/x-www-form-urlencoded、multipart/form-data、text/plain)。HTML 頭部 header field 字段:DPR、Download、Save-Data、Viewport-Width、WIdth。如果請(qǐng)求使用了其他標(biāo)頭,同樣不再被視為簡(jiǎn)單請(qǐng)求。

請(qǐng)求中沒(méi)有使用 ReadableStream 對(duì)象。

不使用自定義請(qǐng)求標(biāo)頭:請(qǐng)求不能包含用戶(hù)自定義的標(biāo)頭。

請(qǐng)求中的任意 XMLHttpRequestUpload 對(duì)象均沒(méi)有注冊(cè)任何事件監(jiān)聽(tīng)器;XMLHttpRequestUpload 對(duì)象可以使用 XMLHttpRequest.upload 屬性訪(fǎng)問(wèn)

預(yù)檢請(qǐng)求

非簡(jiǎn)單請(qǐng)求的 CORS 請(qǐng)求,會(huì)在正式通信之前,增加一次 HTTP 查詢(xún)請(qǐng)求,稱(chēng)為 預(yù)檢請(qǐng)求。

需預(yù)檢的請(qǐng)求要求必須首先使用 OPTIONS 方法發(fā)起一個(gè)預(yù)檢請(qǐng)求到服務(wù)器,以獲知服務(wù)器是否允許該實(shí)際請(qǐng)求。預(yù)檢請(qǐng)求 的使用,可以避免跨域請(qǐng)求對(duì)服務(wù)器的用戶(hù)數(shù)據(jù)產(chǎn)生未預(yù)期的影響。

例如我在自己的網(wǎng)站上刪除一條記錄:

fb80d9ea-5a92-11ee-939d-92fbcf53809c.png

它首先會(huì)發(fā)起一個(gè)預(yù)檢請(qǐng)求,預(yù)檢請(qǐng)求的頭信息包括兩個(gè)特殊字段:

Access-Control-Request-Method:該字段是必須的,用來(lái)列出瀏覽器的 CORS 請(qǐng)求會(huì)用到哪些 HTTP 方法,上例是 POST。

Access-Control-Request-Headers:該字段是一個(gè)逗號(hào)分隔的字符串,指定瀏覽器 CORS 請(qǐng)求會(huì)額外發(fā)送的頭信息字段,上例是 content-type,x-secsdk-csrf-token。

access-control-allow-origin:在上述例子中,表示 https://xxx.cn 可以請(qǐng)求數(shù)據(jù),也可以設(shè)置為* 符號(hào),表示統(tǒng)一任意跨源請(qǐng)求。

access-control-max-age:該字段可選,用來(lái)指定本次預(yù)檢請(qǐng)求的有效期,單位為秒。上面結(jié)果中,有效期是 1 天(86408 秒),即允許緩存該條回應(yīng) 1 天(86408 秒),在此期間,不用發(fā)出另一條預(yù)檢請(qǐng)求。

一旦服務(wù)器通過(guò)了 預(yù)檢請(qǐng)求,以后每次瀏覽器正常的 CORS 請(qǐng)求,就都跟簡(jiǎn)單請(qǐng)求一樣,會(huì)有一個(gè) Origin 頭信息字段。服務(wù)器的回應(yīng),也都會(huì)有一個(gè) Access-Control-Allow-Origin 頭信息字段。

fb9f90a6-5a92-11ee-939d-92fbcf53809c.png

上面頭信息中,Access-Control-Allow-Origin 字段是每次回應(yīng)都必定包含的。

附帶身份憑證的請(qǐng)求與通配符

在響應(yīng)附帶身份憑證的請(qǐng)求時(shí):

為了避免惡意網(wǎng)站濫用 Access-Control-Allow-Origin 頭部字段來(lái)獲取用戶(hù)敏感信息,服務(wù)器在設(shè)置時(shí)不能將其值設(shè)為通配符 *。相反,應(yīng)該將其設(shè)置為特定的域,例如:Access-Control-Allow-Origin: https://xxx.cn。通過(guò)將 Access-Control-Allow-Origin 設(shè)置為特定的域,服務(wù)器只允許來(lái)自指定域的請(qǐng)求進(jìn)行跨域訪(fǎng)問(wèn)。這樣可以限制跨域請(qǐng)求的范圍,避免不可信的域獲取到用戶(hù)敏感信息。

為了避免潛在的安全風(fēng)險(xiǎn),服務(wù)器不能將 Access-Control-Allow-Headers 的值設(shè)為通配符 *。這是因?yàn)椴皇芟拗频恼?qǐng)求頭可能被濫用。相反,應(yīng)該將其設(shè)置為一個(gè)包含標(biāo)頭名稱(chēng)的列表,例如:Access-Control-Allow-Headers: X-PINGOTHER, Content-Type。通過(guò)將 Access-Control-Allow-Headers 設(shè)置為明確的標(biāo)頭名稱(chēng)列表,服務(wù)器可以限制哪些自定義請(qǐng)求頭是允許的。只有在允許的標(biāo)頭列表中的頭部字段才能在跨域請(qǐng)求中被接受。

為了避免潛在的安全風(fēng)險(xiǎn),服務(wù)器不能將 Access-Control-Allow-Methods 的值設(shè)為通配符 *。這樣做將允許來(lái)自任意域的請(qǐng)求使用任意的 HTTP 方法,可能導(dǎo)致濫用行為的發(fā)生。相反,應(yīng)該將其設(shè)置為一個(gè)特定的請(qǐng)求方法名稱(chēng)列表,例如:Access-Control-Allow-Methods: POST, GET。通過(guò)將 Access-Control-Allow-Methods 設(shè)置為明確的請(qǐng)求方法列表,服務(wù)器可以限制哪些方法是允許的。只有在允許的方法列表中的方法才能在跨域請(qǐng)求中被接受和處理。

對(duì)于附帶身份憑證的請(qǐng)求(通常是 Cookie)

這是因?yàn)檎?qǐng)求的標(biāo)頭中攜帶了 Cookie 信息,如果 Access-Control-Allow-Origin 的值為 *,請(qǐng)求將會(huì)失敗。而將 Access-Control-Allow-Origin 的值設(shè)置為 https://xxx.cn,則請(qǐng)求將成功執(zhí)行。

另外,響應(yīng)標(biāo)頭中也攜帶了 Set-Cookie 字段,嘗試對(duì) Cookie 進(jìn)行修改。如果操作失敗,將會(huì)拋出異常。

完整的請(qǐng)求流程圖

fbc88114-5a92-11ee-939d-92fbcf53809c.png

總結(jié)

預(yù)檢請(qǐng)求是在進(jìn)行跨域資源共享 CORS 時(shí),由瀏覽器自動(dòng)發(fā)起的一種 OPTIONS 請(qǐng)求。它的存在是為了保障安全,并允許服務(wù)器決定是否允許跨域請(qǐng)求。

跨域請(qǐng)求是指在瀏覽器中向不同域名、不同端口或不同協(xié)議的資源發(fā)送請(qǐng)求。出于安全原因,瀏覽器默認(rèn)禁止跨域請(qǐng)求,只允許同源策略。而當(dāng)網(wǎng)頁(yè)需要進(jìn)行跨域請(qǐng)求時(shí),瀏覽器會(huì)自動(dòng)發(fā)送一個(gè)預(yù)檢請(qǐng)求,以確定是否服務(wù)器允許實(shí)際的跨域請(qǐng)求。

預(yù)檢請(qǐng)求中包含了一些額外的頭部信息,如 Origin 和 Access-Control-Request-Method 等,用于告知服務(wù)器實(shí)際請(qǐng)求的方法和來(lái)源。服務(wù)器收到預(yù)檢請(qǐng)求后,可以根據(jù)這些頭部信息,進(jìn)行驗(yàn)證和授權(quán)判斷。如果服務(wù)器認(rèn)可該跨域請(qǐng)求,將返回一個(gè)包含 Access-Control-Allow-Origin 等頭部信息的響應(yīng),瀏覽器才會(huì)繼續(xù)發(fā)送實(shí)際的跨域請(qǐng)求。

使用預(yù)檢請(qǐng)求機(jī)制可以有效地防范跨域請(qǐng)求帶來(lái)的安全風(fēng)險(xiǎn),保護(hù)用戶(hù)數(shù)據(jù)和隱私。







審核編輯:劉清

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

    關(guān)注

    0

    文章

    21

    瀏覽量

    1756
  • csrf
    +關(guān)注

    關(guān)注

    0

    文章

    7

    瀏覽量

    2224

原文標(biāo)題:面試官:post為什么會(huì)發(fā)送兩次請(qǐng)求?

文章出處:【微信號(hào):芋道源碼,微信公眾號(hào):芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    TC397 UART接收中斷只會(huì)進(jìn)入兩次,為什么?

    您好,我想詢(xún)問(wèn)有關(guān)串口的問(wèn)題:我在使用串口中斷的時(shí)候發(fā)現(xiàn)發(fā)送數(shù)據(jù)的時(shí)候,我的接收中斷只會(huì)進(jìn)入兩次,查看手冊(cè)發(fā)現(xiàn)RX FIFO一寫(xiě)入只能是1 or 2,可是我發(fā)送的數(shù)據(jù)大于2字節(jié),但是
    發(fā)表于 06-04 09:26

    使用ESP32-S3開(kāi)發(fā)板http post請(qǐng)求發(fā)送SD卡上的大文件,如何循環(huán)邊讀取文件邊分塊發(fā)送文件呢?

    您和,我準(zhǔn)備使用ESP32-S3開(kāi)發(fā)板http post請(qǐng)求發(fā)送SD卡上的大文件,但是使用esp_http_client_set_post_field的buffer太小,內(nèi)存不能一
    發(fā)表于 06-06 06:19

    labview上位機(jī)串口通信怎么設(shè)置點(diǎn)擊一發(fā)送自動(dòng)重復(fù)發(fā)送兩次啊??

    labview上位機(jī)給下位機(jī)發(fā)送數(shù)據(jù),每次發(fā)送位16進(jìn)制8個(gè)但是下位機(jī)要接收17個(gè)來(lái)進(jìn)行判斷和提取我需要的數(shù)值。。但是每次都是連續(xù)按兩次發(fā)送
    發(fā)表于 05-13 14:50

    有辦法使用單個(gè)POST請(qǐng)求發(fā)送64 kByte的二進(jìn)制數(shù)據(jù)塊嗎?

    嗨,我正在使用SPWF01SA1模塊使用POST請(qǐng)求將數(shù)據(jù)從我的應(yīng)用程序發(fā)送到中央服務(wù)器。我需要使用單個(gè)POST請(qǐng)求傳輸64 kByte的二
    發(fā)表于 03-06 16:07

    為什么lwip+ucosii板子上電會(huì)有兩次gratitions arp?

    上電后會(huì)發(fā)出倆arp requset,且mac不同,網(wǎng)絡(luò)助手發(fā)送udp數(shù)據(jù)包先針對(duì)一個(gè)mac,不行的話(huà)在廣播請(qǐng)求。這樣會(huì)等好久。具體不知道為什么會(huì)有
    發(fā)表于 10-10 23:52

    STC單片機(jī)兩次下載相同的程序發(fā)現(xiàn)串口發(fā)送的數(shù)據(jù)不一樣

    今天遇到一個(gè)不解的問(wèn)題,程序中發(fā)送一個(gè)固定的字節(jié)數(shù)據(jù),我前后兩次下載相同的程序發(fā)現(xiàn)串口發(fā)送的數(shù)據(jù)前后兩次竟然不同!另外,在KEIL環(huán)境下如何實(shí)現(xiàn)在線(xiàn)調(diào)試STC單片機(jī)程序(不是單純的燒寫(xiě)
    發(fā)表于 10-30 07:15

    如何使用POST請(qǐng)求從SPIFF向服務(wù)器發(fā)送圖像?

    嘗試將圖像(使用 POST 請(qǐng)求發(fā)送到服務(wù)器,該服務(wù)器將查找圖像中的某些項(xiàng)目并返回包含我需要的信息的 JSON 對(duì)象。:我使用手動(dòng)轉(zhuǎn)換的 Base64 字符串圖像處理服務(wù)器對(duì) API 的 P
    發(fā)表于 02-24 08:35

    如何對(duì)Google Cloud IoT Core Pub/Sub的http POST發(fā)送請(qǐng)求?

    我正在 lua 中開(kāi)發(fā)一個(gè)項(xiàng)目,使用 ESPlorer IDE,它需要 ESP8266 通過(guò) http 客戶(hù)端 POST 請(qǐng)求將遙測(cè)事件發(fā)送到谷歌云物聯(lián)網(wǎng)核心,該請(qǐng)求必須具有與以下類(lèi)似
    發(fā)表于 04-27 07:17

    http請(qǐng)求 get post

    ; importjava.util.List; importjava.util.Map;publicclassHttpRequest{/** * 向指定URL發(fā)送GET方法的請(qǐng)求 * *@paramurl * 發(fā)送
    發(fā)表于 09-27 10:36 ?16次下載

    馬斯克:4新冠病毒檢測(cè) 兩次陰性 兩次陽(yáng)性

    11月13日消息,據(jù)外媒報(bào)道,特斯拉CEO馬斯克剛剛在社交網(wǎng)絡(luò)上表示,今天做了4新冠病毒檢測(cè),檢查結(jié)果兩次為陰性兩次為陽(yáng)性。 馬斯克表示,相同的機(jī)器,相同的測(cè)試,相同的護(hù)士,同樣的抗原檢測(cè)
    的頭像 發(fā)表于 11-13 16:29 ?1798次閱讀

    get與post請(qǐng)求一些區(qū)別

    今天再次看到這個(gè)問(wèn)題,我也有了一些新的理解和感觸,臨時(shí)回顧了一下 get 與 post請(qǐng)求的一些區(qū)別。
    的頭像 發(fā)表于 09-07 10:00 ?1336次閱讀

    HTTP請(qǐng)求報(bào)文:GET和POST的區(qū)別

    GET 和 POST 其實(shí)都是 HTTP 的請(qǐng)求方法。除了這 2 個(gè)請(qǐng)求方法之外,HTTP 還有 HEAD、PUT、DELETE、TRACE、CONNECT、OPTIONS 這 6 個(gè)請(qǐng)求
    發(fā)表于 04-10 10:11 ?2103次閱讀

    所有接口都用post請(qǐng)求的原因

    查看上面的區(qū)別,就會(huì)發(fā)現(xiàn)post發(fā)送數(shù)據(jù)量大的請(qǐng)求時(shí)優(yōu)勢(shì)很顯示,get則更適合獲取靜態(tài)資源、簡(jiǎn)單的查詢(xún)等接口。 我個(gè)人在開(kāi)發(fā)接口的時(shí)候也會(huì)注意,將簡(jiǎn)單的查詢(xún)
    發(fā)表于 08-24 10:06 ?376次閱讀
    所有接口都用<b class='flag-5'>post</b><b class='flag-5'>請(qǐng)求</b>的原因

    python怎么將list輸入兩次

    在Python中,有多種方法可以將一個(gè)列表輸入兩次。下面是使用不同的方法來(lái)實(shí)現(xiàn)此功能的幾個(gè)示例: 方法1: 使用循環(huán)將列表復(fù)制兩次 這是一種基本的方法,使用循環(huán)遍歷列表并復(fù)制其元素兩次。以下是一個(gè)
    的頭像 發(fā)表于 11-21 16:17 ?1232次閱讀

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

    說(shuō)說(shuō)TCP三握手的過(guò)程?為什么是三而不是兩次、四? TCP三握手是建立TCP連接的過(guò)程,確保數(shù)據(jù)的可靠傳輸。它是由
    的頭像 發(fā)表于 02-04 11:03 ?526次閱讀