HOME 首頁(yè)
SERVICE 服務(wù)產(chǎn)品
XINMEITI 新媒體代運(yùn)營(yíng)
CASE 服務(wù)案例
NEWS 熱點(diǎn)資訊
ABOUT 關(guān)于我們
CONTACT 聯(lián)系我們
創(chuàng)意嶺
讓品牌有溫度、有情感
專(zhuān)注品牌策劃15年

    tcp請(qǐng)求(jmeter發(fā)送tcp請(qǐng)求)

    發(fā)布時(shí)間:2023-03-19 02:14:15     稿源: 創(chuàng)意嶺    閱讀: 97        問(wèn)大家

    大家好!今天讓創(chuàng)意嶺的小編來(lái)大家介紹下關(guān)于tcp請(qǐng)求的問(wèn)題,以下是小編對(duì)此問(wèn)題的歸納整理,讓我們一起來(lái)看看吧。

    開(kāi)始之前先推薦一個(gè)非常厲害的Ai人工智能工具,一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話(huà)答疑等等

    只需要輸入關(guān)鍵詞,就能返回你想要的內(nèi)容,越精準(zhǔn),寫(xiě)出的就越詳細(xì),有微信小程序端、在線(xiàn)網(wǎng)頁(yè)版、PC客戶(hù)端

    官網(wǎng):https://ai.de1919.com

    本文目錄:

    tcp請(qǐng)求(jmeter發(fā)送tcp請(qǐng)求)

    一、一文搞懂TCP的三次握手和四次揮手

    TCP的三次握手和四次揮手實(shí)質(zhì)就是TCP通信的連接和斷開(kāi)。

    三次握手:為了對(duì)每次發(fā)送的數(shù)據(jù)量進(jìn)行跟蹤與協(xié)商,確保數(shù)據(jù)段的發(fā)送和接收同步,根據(jù)所接收到的數(shù)據(jù)量而確認(rèn)數(shù)據(jù)發(fā)送、接收完畢后何時(shí)撤消聯(lián)系,并建立虛連接。

    四次揮手:即終止TCP連接,就是指斷開(kāi)一個(gè)TCP連接時(shí),需要客戶(hù)端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開(kāi)。

    TCP三次握手、四次揮手時(shí)序圖

    TCP協(xié)議位于傳輸層,作用是提供可靠的字節(jié)流服務(wù),為了準(zhǔn)確無(wú)誤地將數(shù)據(jù)送達(dá)目的地,TCP協(xié)議采納三次握手策略。

    三次握手原理:

    第1次握手:客戶(hù)端發(fā)送一個(gè)帶有SYN(synchronize)標(biāo)志的數(shù)據(jù)包給服務(wù)端;

    第2次握手:服務(wù)端接收成功后,回傳一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包傳遞確認(rèn)信息,表示我收到了;

    第3次握手:客戶(hù)端再回傳一個(gè)帶有ACK標(biāo)志的數(shù)據(jù)包,表示我知道了,握手結(jié)束。

    其中:SYN標(biāo)志位數(shù)置1,表示建立TCP連接;ACK標(biāo)志表示驗(yàn)證字段。

    可通過(guò)以下趣味圖解理解三次握手:

    三次握手過(guò)程詳細(xì)說(shuō)明:

    1、客戶(hù)端發(fā)送建立TCP連接的請(qǐng)求報(bào)文,其中報(bào)文中包含seq序列號(hào),是由發(fā)送端隨機(jī)生成的,并且將報(bào)文中的SYN字段置為1,表示需要建立TCP連接。(SYN=1,seq=x,x為隨機(jī)生成數(shù)值);

    2、服務(wù)端回復(fù)客戶(hù)端發(fā)送的TCP連接請(qǐng)求報(bào)文,其中包含seq序列號(hào),是由回復(fù)端隨機(jī)生成的,并且將SYN置為1,而且會(huì)產(chǎn)生ACK字段,ACK字段數(shù)值是在客戶(hù)端發(fā)送過(guò)來(lái)的序列號(hào)seq的基礎(chǔ)上加1進(jìn)行回復(fù),以便客戶(hù)端收到信息時(shí),知曉自己的TCP建立請(qǐng)求已得到驗(yàn)證。(SYN=1,ACK=x+1,seq=y,y為隨機(jī)生成數(shù)值)這里的ack加1可以理解為是確認(rèn)和誰(shuí)建立連接;

    3、客戶(hù)端收到服務(wù)端發(fā)送的TCP建立驗(yàn)證請(qǐng)求后,會(huì)使自己的序列號(hào)加1表示,并且再次回復(fù)ACK驗(yàn)證請(qǐng)求,在服務(wù)端發(fā)過(guò)來(lái)的seq上加1進(jìn)行回復(fù)。(SYN=1,ACK=y+1,seq=x+1)。

    由于TCP連接是全雙工的,因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來(lái)終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒(méi)有數(shù)據(jù)流動(dòng),一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉,而另一方執(zhí)行被動(dòng)關(guān)閉。

    四次揮手原理:

    第1次揮手:客戶(hù)端發(fā)送一個(gè)FIN,用來(lái)關(guān)閉客戶(hù)端到服務(wù)端的數(shù)據(jù)傳送,客戶(hù)端進(jìn)入FIN_WAIT_1狀態(tài);

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

    第3次揮手:服務(wù)端發(fā)送一個(gè)FIN,用來(lái)關(guān)閉服務(wù)端到客戶(hù)端的數(shù)據(jù)傳送,服務(wù)端進(jìn)入LAST_ACK狀態(tài);

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

    其中:FIN標(biāo)志位數(shù)置1,表示斷開(kāi)TCP連接。

    可通過(guò)以下趣味圖解理解四次揮手:

    四次揮手過(guò)程詳細(xì)說(shuō)明:

    1、客戶(hù)端發(fā)送斷開(kāi)TCP連接請(qǐng)求的報(bào)文,其中報(bào)文中包含seq序列號(hào),是由發(fā)送端隨機(jī)生成的,并且還將報(bào)文中的FIN字段置為1,表示需要斷開(kāi)TCP連接。(FIN=1,seq=x,x由客戶(hù)端隨機(jī)生成);

    2、服務(wù)端會(huì)回復(fù)客戶(hù)端發(fā)送的TCP斷開(kāi)請(qǐng)求報(bào)文,其包含seq序列號(hào),是由回復(fù)端隨機(jī)生成的,而且會(huì)產(chǎn)生ACK字段,ACK字段數(shù)值是在客戶(hù)端發(fā)過(guò)來(lái)的seq序列號(hào)基礎(chǔ)上加1進(jìn)行回復(fù),以便客戶(hù)端收到信息時(shí),知曉自己的TCP斷開(kāi)請(qǐng)求已經(jīng)得到驗(yàn)證。(FIN=1,ACK=x+1,seq=y,y由服務(wù)端隨機(jī)生成);

    3、服務(wù)端在回復(fù)完客戶(hù)端的TCP斷開(kāi)請(qǐng)求后,不會(huì)馬上進(jìn)行TCP連接的斷開(kāi),服務(wù)端會(huì)先確保斷開(kāi)前,所有傳輸?shù)紸的數(shù)據(jù)是否已經(jīng)傳輸完畢,一旦確認(rèn)傳輸數(shù)據(jù)完畢,就會(huì)將回復(fù)報(bào)文的FIN字段置1,并且產(chǎn)生隨機(jī)seq序列號(hào)。(FIN=1,ACK=x+1,seq=z,z由服務(wù)端隨機(jī)生成);

    4、客戶(hù)端收到服務(wù)端的TCP斷開(kāi)請(qǐng)求后,會(huì)回復(fù)服務(wù)端的斷開(kāi)請(qǐng)求,包含隨機(jī)生成的seq字段和ACK字段,ACK字段會(huì)在服務(wù)端的TCP斷開(kāi)請(qǐng)求的seq基礎(chǔ)上加1,從而完成服務(wù)端請(qǐng)求的驗(yàn)證回復(fù)。(FIN=1,ACK=z+1,seq=h,h為客戶(hù)端隨機(jī)生成)

    至此TCP斷開(kāi)的4次揮手過(guò)程完畢。

    LISTEN:等待從任何遠(yuǎn)端TCP 和端口的連接請(qǐng)求。

    SYN_SENT:發(fā)送完一個(gè)連接請(qǐng)求后等待一個(gè)匹配的連接請(qǐng)求。

    SYN_RECEIVED:發(fā)送連接請(qǐng)求并且接收到匹配的連接請(qǐng)求以后等待連接請(qǐng)求確認(rèn)。

    ESTABLISHED:表示一個(gè)打開(kāi)的連接,接收到的數(shù)據(jù)可以被投遞給用戶(hù)。連接的數(shù)據(jù)傳輸階段的正常狀態(tài)。

    FIN_WAIT_1:等待遠(yuǎn)端TCP 的連接終止請(qǐng)求,或者等待之前發(fā)送的連接終止請(qǐng)求的確認(rèn)。

    FIN_WAIT_2:等待遠(yuǎn)端TCP 的連接終止請(qǐng)求。

    CLOSE_WAIT:等待本地用戶(hù)的連接終止請(qǐng)求。

    CLOSING:等待遠(yuǎn)端TCP 的連接終止請(qǐng)求確認(rèn)。

    LAST_ACK:等待先前發(fā)送給遠(yuǎn)端TCP 的連接終止請(qǐng)求的確認(rèn)(包括它字節(jié)的連接終止請(qǐng)求的確認(rèn))

    TIME_WAIT:等待足夠的時(shí)間過(guò)去以確保遠(yuǎn)端TCP 接收到它的連接終止請(qǐng)求的確認(rèn)。

    TIME_WAIT 兩個(gè)存在的理由:

              1.可靠的實(shí)現(xiàn)tcp全雙工連接的終止;

              2.允許老的重復(fù)分節(jié)在網(wǎng)絡(luò)中消逝。

    CLOSED:不在連接狀態(tài)(這是為方便描述假想的狀態(tài),實(shí)際不存在)。

    二、怎么解決在window下高并發(fā)TCP請(qǐng)求端口被占用有關(guān)問(wèn)題

    執(zhí)行以下操作之一:

    在 Windows XP 或 Windows Server 2003 計(jì)算機(jī)上的命令提示中輸入以下命令,顯示此計(jì)算機(jī)上 TCP/IP 協(xié)議所使用的活動(dòng)連接:

    復(fù)制

    netstat -n

    這將列出綁定到客戶(hù)端計(jì)算機(jī)的 TCP/IP 地址以及 TCP/IP 地址與遠(yuǎn)程服務(wù)器通信所使用的端口。如果列出的端口使用了所有可用的端口,則出現(xiàn)了 TCP/IP 端口耗盡現(xiàn)象。

    在基于 Windows Server 2003 的客戶(hù)端計(jì)算機(jī)的命令提示中輸入以下命令,以顯示 TCP/IP 協(xié)議所使用的活動(dòng)連接:

    復(fù)制

    netstat -b

    這將列出綁定到客戶(hù)端計(jì)算機(jī)的 TCP/IP 地址、TCP/IP 地址與遠(yuǎn)程服務(wù)器通信所使用的端口以及使用這些端口的應(yīng)用程序。此信息可以幫助您確定那個(gè)客戶(hù)端應(yīng)用程序正在使用過(guò)多的 TCP/IP 端口。

    與 TCP/IP 端口耗盡有關(guān)的問(wèn)題

    當(dāng)客戶(hù)端應(yīng)用程序嘗試使用 TCP/IP 套接字連接到 BizTalk Server,或當(dāng) BizTalk 應(yīng)用程序嘗試使用 TCP/IP 套接字連接到服務(wù)器時(shí),可能會(huì)出現(xiàn)類(lèi)似于下面的情況:

    復(fù)制

    System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.

    - 或者 -

    復(fù)制

    Unable to connect to the remote server

    System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.

    當(dāng)出現(xiàn)這些錯(cuò)誤時(shí),還可能出現(xiàn)以下問(wèn)題:

    客戶(hù)端應(yīng)用程序可能無(wú)法連接到 BizTalk Server。

    BizTalk 應(yīng)用程序服務(wù)可能無(wú)法連接到遠(yuǎn)程 SQL 服務(wù)器。

    BizTalk Server 適配器可能無(wú)法連接到遠(yuǎn)程服務(wù)器。

    客戶(hù)端應(yīng)用程序預(yù)留的每個(gè)端口均占用內(nèi)核內(nèi)存。如果預(yù)留了數(shù)目超常的客戶(hù)端端口,Windows 內(nèi)核內(nèi)存的占用率將相應(yīng)增加。

    原因

    如果客戶(hù)端計(jì)算機(jī)中存在數(shù)目超常的 TCIP/IP 套接字連接,則客戶(hù)端計(jì)算機(jī)上可能出現(xiàn) TCP/IP 端口耗盡的情況。如果多個(gè)客戶(hù)端應(yīng)用程序都在建立連接,則可能出現(xiàn)這種情況。

    如果所有可用的臨時(shí)端口都分配給了客戶(hù)端應(yīng)用程序,則客戶(hù)端將出現(xiàn) TCP/IP 端口耗盡的情況。當(dāng) TCP/IP 端口耗盡時(shí),將無(wú)法預(yù)留客戶(hù)端端口,并且嘗試通過(guò) TCP/IP 套接字連接到服務(wù)器的客戶(hù)端應(yīng)用程序也將出錯(cuò)。

    在高負(fù)載情況下,比處于正常負(fù)載時(shí)更容易出現(xiàn) TCP/IP 端口耗盡的情況。

    解決方法

    執(zhí)行以下步驟以避免 TCP/IP 端口耗盡及其相關(guān)問(wèn)題:

    驗(yàn)證客戶(hù)端應(yīng)用程序沒(méi)有生成過(guò)多的 TCP/IP 套接字連接。這一點(diǎn)可以用上面提到的方法來(lái)檢查,即在 Windows Server 2003 和 Windows XP 上運(yùn)行 netstat -n,或者在 Windows Server 2003 和 2008 上運(yùn)行 netstat -b。

    如果某個(gè)客戶(hù)端應(yīng)用程序使用了數(shù)量超常的 TCP/IP 套接字連接,則應(yīng)考慮重新設(shè)計(jì)客戶(hù)端應(yīng)用程序,以便更有效地使用 TCP/IP 套接字連接。

    注意

    如果為 BizTalk 應(yīng)用程序服務(wù) (BTSNTSvc.exe) 實(shí)例預(yù)留了數(shù)量超常的客戶(hù)端端口,則需驗(yàn)證配置為在 BizTalk 應(yīng)用程序服務(wù)中運(yùn)行的任何自定義代碼都沒(méi)有建立過(guò)多的 TCP/IP 套接字連接。

    如果大量客戶(hù)端應(yīng)用程序要啟動(dòng)已知數(shù)量的 TCP/IP 套接字連接,但沒(méi)有足夠數(shù)量的可用臨時(shí)端口來(lái)滿(mǎn)足連接請(qǐng)求,則需要進(jìn)行以下注冊(cè)表修改。

    警告

    如果注冊(cè)表編輯器使用不當(dāng),則可能會(huì)產(chǎn)生嚴(yán)重問(wèn)題,導(dǎo)致重新安裝操作系統(tǒng)。Microsoft 不保證可以解決因注冊(cè)表編輯器使用不當(dāng)而造成的問(wèn)題。請(qǐng)慎用注冊(cè)表編輯器,風(fēng)險(xiǎn)自負(fù)。在修改注冊(cè)表之前,請(qǐng)務(wù)必備份注冊(cè)表,并確保您知道在發(fā)生問(wèn)題時(shí)如何使用備份進(jìn)行還原。有關(guān)如何備份、還原及修改注冊(cè)表的詳細(xì)信息,請(qǐng)參閱 Microsoft 知識(shí)庫(kù)文章“Microsoft Windows 注冊(cè)表說(shuō)明”,網(wǎng)址為http://go.microsoft.com/fwlink/?LinkId=62729。

    增加動(dòng)態(tài)分配到客戶(hù)端 TCP/IP 套接字連接的臨時(shí)端口的上限。

    降低客戶(hù)端 TCP/IP 套接字連接的超時(shí)值(默認(rèn)值為 240 秒)

    啟動(dòng)注冊(cè)表編輯器。

    在注冊(cè)表中,瀏覽到并單擊以下注冊(cè)表項(xiàng)。

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    在“編輯”菜單中單擊“新建”、“DWORD 值”,然后添加以下注冊(cè)表值,以縮短關(guān)閉連接時(shí),該連接處于 TIME_WAIT 狀態(tài)的時(shí)間。當(dāng)連接處于 TIME_WAIT 狀態(tài)時(shí),套接字對(duì)無(wú)法重新使用:

    值名稱(chēng)

    TcpTimedWaitDelay

    值數(shù)據(jù)

    <在此輸入一個(gè) 30 到 240 之間的十進(jìn)制值。>

    關(guān)閉注冊(cè)表編輯器。

    注意

    必須重新啟動(dòng)計(jì)算機(jī),此更改才會(huì)生效。

    注意

    此值的有效范圍為 30 到 300(十進(jìn)制)之間。默認(rèn)值為 240。

    啟動(dòng)注冊(cè)表編輯器。

    在注冊(cè)表中,瀏覽到并單擊以下注冊(cè)表項(xiàng)。

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    在“編輯”菜單中單擊“新建”、“DWORD 值”,然后添加以下注冊(cè)表值,以增加可以動(dòng)態(tài)分配到客戶(hù)端的臨時(shí)端口的數(shù)量:

    值名稱(chēng)

    MaxUserPort

    值數(shù)據(jù)

    <在此輸入一個(gè) 5000 到 65534 之間的十進(jìn)制值>

    關(guān)閉注冊(cè)表編輯器。

    注意

    必須重新啟動(dòng)計(jì)算機(jī),此更改才會(huì)生效。

    注意

    增加用于客戶(hù)端 TCP/IP 連接的臨時(shí)端口的范圍將占用 Windows 內(nèi)核內(nèi)存。請(qǐng)勿將此設(shè)置的值增加至超過(guò)容納客戶(hù)端應(yīng)用程序套接字連接所需要的值,以便盡可能降低對(duì) Windows 內(nèi)核內(nèi)存的不必要占用。

    三、tcp發(fā)請(qǐng)求數(shù)據(jù)里為什么后面會(huì)自動(dòng)填充很多零

    數(shù)據(jù)部分不是偶數(shù)。

    在RFC1071的文檔中,有一個(gè)C語(yǔ)言的的代碼來(lái)求解校驗(yàn)和。在UDP報(bào)文校驗(yàn)和計(jì)算的時(shí)候,如果報(bào)文的數(shù)據(jù)部分不是偶數(shù)個(gè)字節(jié),則在最后面填充0。

    四、TCP連接相關(guān)

    為什么要有三次握手,因?yàn)槿绻挥袃纱挝帐?,那?/p>

    第一次:客戶(hù)端發(fā)送一個(gè)syn包給服務(wù)器,里面有一個(gè)隨機(jī)生成的syn,然后客戶(hù)端處于syn_send狀態(tài)

    第二次:服務(wù)端收到客戶(hù)端發(fā)來(lái)的syn包之后,確認(rèn)syn包,也就是生成一個(gè)ack=syn+1,然后再自己隨機(jī)生成一個(gè)syn包,即syn+ack包,然后返回給客戶(hù)端,自己變成syn_recv狀態(tài)

    第三次:客戶(hù)端收到服務(wù)端發(fā)來(lái)的syn+ack包之后,確認(rèn)ack是正確的之后,返回一個(gè)ack=syn+1給服務(wù)端,此包發(fā)送完畢,客戶(hù)端進(jìn)入了ESTABLISHED狀態(tài),服務(wù)端收到ack包后也進(jìn)入ESTABLISHED狀態(tài)。

    SYN攻擊,當(dāng)?shù)诙挝帐址?wù)端發(fā)送了syn+ack包之后,收到客戶(hù)端發(fā)送的ack之前這段時(shí)間的tcp鏈接成為半連接,此時(shí)服務(wù)端處于syn_recv狀態(tài)。當(dāng)大量客戶(hù)端隨機(jī)IP瘋狂發(fā)送tcp鏈接請(qǐng)求時(shí),客戶(hù)端以為是不同用戶(hù)的請(qǐng)求,所以隊(duì)列中全是半連接,然后導(dǎo)致服務(wù)器宕機(jī),正常請(qǐng)求被丟棄。

    第一個(gè)包發(fā)送過(guò)程丟失

    A會(huì)周期性超時(shí)重傳,直到收到B的確認(rèn)

    第二個(gè)包發(fā)送過(guò)程丟失

    B會(huì)周期性超時(shí)重傳,直到收到A的確認(rèn)

    第三個(gè)包發(fā)送過(guò)程丟失

    A發(fā)送完數(shù)據(jù)后單方面進(jìn)入TCP的ESTABLISHED狀態(tài),B還處于半鏈接:

    TCP協(xié)議為什么需要三次握手?

    第一次:客戶(hù)端發(fā)送一個(gè)fin給服務(wù)端表示自己要斷開(kāi)連接了,然后進(jìn)入fin_wait_1狀態(tài)

    第二次:服務(wù)端收到fin后,發(fā)送一個(gè)ack=fin+1給客戶(hù)端,服務(wù)端進(jìn)入close_wait狀態(tài),客戶(hù)端進(jìn)入fin_wait_2狀態(tài)

    第三次:服務(wù)端發(fā)送一個(gè)fin,用來(lái)關(guān)閉服務(wù)端到客戶(hù)端的數(shù)據(jù)傳輸,服務(wù)端進(jìn)入last_ack狀態(tài)

    第四次:客戶(hù)端收到fin后,進(jìn)入time_wait狀態(tài),然后發(fā)送一個(gè)ack=fin+1給服務(wù)端,服務(wù)端確認(rèn)后進(jìn)入close狀態(tài),完成四次揮手

    TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議。TCP是全雙工模式,這就意味著,當(dāng)主機(jī)1發(fā)出FIN報(bào)文段時(shí),只是表示主機(jī)1已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了,主機(jī)1告訴主機(jī)2,它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了;但是,這個(gè)時(shí)候主機(jī)1還是可以接受來(lái)自主機(jī)2的數(shù)據(jù);當(dāng)主機(jī)2返回ACK報(bào)文段時(shí),表示它已經(jīng)知道主機(jī)1沒(méi)有數(shù)據(jù)發(fā)送了,但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的;當(dāng)主機(jī)2也發(fā)送了FIN報(bào)文段時(shí),這個(gè)時(shí)候就表示主機(jī)2也沒(méi)有數(shù)據(jù)要發(fā)送了,就會(huì)告訴主機(jī)1,我也沒(méi)有數(shù)據(jù)要發(fā)送了,之后彼此就會(huì)愉快的中斷這次TCP連接。如果要正確的理解四次分手的原理,就需要了解四次分手過(guò)程中的狀態(tài)變化。

    答案解析:

    瀏覽器對(duì)并發(fā)請(qǐng)求的數(shù)目限制是針對(duì)域名的,即針對(duì)同一域名(包括二級(jí)域名)在同一時(shí)間支持的并發(fā)請(qǐng)求數(shù)量的限制。如果請(qǐng)求數(shù)目超出限制,則會(huì)阻塞。因此,網(wǎng)站中對(duì)一些靜態(tài)資源,使用不同的一級(jí)域名,可以提升瀏覽器并行請(qǐng)求的數(shù)目,加速界面資源的獲取速度。

    在 HTTP/1.0 中,一個(gè)http請(qǐng)求收到服務(wù)器響應(yīng)后,會(huì)斷開(kāi)對(duì)應(yīng)的TCP連接。這樣每次請(qǐng)求,都需要重新建立TCP連接,這樣一直重復(fù)建立和斷開(kāi)的過(guò)程,比較耗時(shí)。所以為了充分利用TCP連接,可以設(shè)置頭字段 Connection: keep-alive ,這樣http請(qǐng)求完成后,就不會(huì)斷開(kāi)當(dāng)前的TCP連接,后續(xù)的http請(qǐng)求可以使用當(dāng)前TCP連接進(jìn)行通信。

    第一次訪(fǎng)問(wèn)有初始化連接和SSL開(kāi)銷(xiāo)

    初始化連接和SSL開(kāi)銷(xiāo)消失了,說(shuō)明使用的是同一個(gè)TCP連接。

    HTTP/1.1 將 Connection 寫(xiě)入了標(biāo)準(zhǔn),默認(rèn)值為 keep-alive 。除非強(qiáng)制設(shè)置為 Connection: close ,才會(huì)在請(qǐng)求后斷開(kāi)TCP連接。

    所以這一題的答案就是:默認(rèn)情況下建立的TCP連接不會(huì)斷開(kāi),只有在請(qǐng)求頭中設(shè)置 Connection: close 才會(huì)在請(qǐng)求后關(guān)閉TCP連接。

    HTTP/1.1 中,單個(gè)TCP連接,在同一時(shí)間只能處理一個(gè)http請(qǐng)求,雖然存在Pipelining技術(shù)支持多個(gè)請(qǐng)求同時(shí)發(fā)送,但由于實(shí)踐中存在很多問(wèn)題無(wú)法解決,所以瀏覽器默認(rèn)是關(guān)閉,所以可以認(rèn)為是不支持同時(shí)多個(gè)請(qǐng)求。

    HTTP2 提供了多路傳輸功能,多個(gè)http請(qǐng)求,可以同時(shí)在同一個(gè)TCP連接中進(jìn)行傳輸。

    頁(yè)面資源請(qǐng)求時(shí),瀏覽器會(huì)同時(shí)和服務(wù)器建立多個(gè)TCP連接,在同一個(gè)TCP連接上順序處理多個(gè)HTTP請(qǐng)求。所以瀏覽器的并發(fā)性就體現(xiàn)在可以建立多個(gè)TCP連接,來(lái)支持多個(gè)http同時(shí)請(qǐng)求。

    Chrome瀏覽器最多允許對(duì)同一個(gè)域名Host建立6個(gè)TCP連接,不同的瀏覽器有所區(qū)別。

    補(bǔ)充

    如果圖片都是HTTPS的連接,并且在同一域名下,瀏覽器會(huì)先和服務(wù)器協(xié)商使用 HTTP2 的 Multiplexing 功能進(jìn)行多路傳輸,不過(guò)未必所有的掛在這個(gè)域名下的資源都會(huì)使用同一個(gè)TCP連接。如果用不了HTTPS或者HTTP2(HTTP2是在HTTPS上實(shí)現(xiàn)的),那么瀏覽器會(huì)就在同一個(gè)host建立多個(gè)TCP連接,每一個(gè)TCP連接進(jìn)行順序請(qǐng)求資源。

    參考:

    [1]. 第8題-瀏覽器HTTP請(qǐng)求并發(fā)數(shù)和TCP連接的關(guān)系

    以上就是關(guān)于tcp請(qǐng)求相關(guān)問(wèn)題的回答。希望能幫到你,如有更多相關(guān)問(wèn)題,您也可以聯(lián)系我們的客服進(jìn)行咨詢(xún),客服也會(huì)為您講解更多精彩的知識(shí)和內(nèi)容。


    推薦閱讀:

    tcp請(qǐng)求(jmeter發(fā)送tcp請(qǐng)求)

    ChatGPT有中文嗎(chatcrypt)

    tcp心跳機(jī)制(tcp 心跳)

    又好看又實(shí)用的字體(又好看又實(shí)用的字體有哪些)

    怎么做電商平臺(tái)(買(mǎi)賣(mài)天貓店鋪的平臺(tái))