正文

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ì)話答疑等等

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

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

本文目錄:

1、一文搞懂TCP的三次握手和四次揮手
2、怎么解決在window下高并發(fā)TCP請(qǐng)求端口被占用有關(guān)問(wèn)題
3、tcp發(fā)請(qǐng)求數(shù)據(jù)里為什么后面會(huì)自動(dòng)填充很多零
4、TCP連接相關(guān)

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í)，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開(kāi)。

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

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

三次握手原理：

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

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

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

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

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

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

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

3、客戶端收到服務(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次揮手：客戶端發(fā)送一個(gè)FIN，用來(lái)關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)傳送，客戶端進(jìn)入FIN_WAIT_1狀態(tài)；

第2次揮手：服務(wù)端收到FIN后，發(fā)送一個(gè)ACK給客戶端，確認(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ù)端到客戶端的數(shù)據(jù)傳送，服務(wù)端進(jìn)入LAST_ACK狀態(tài)；

第4次揮手：客戶端收到FIN后，客戶端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、客戶端發(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由客戶端隨機(jī)生成）；

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

3、服務(wù)端在回復(fù)完客戶端的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、客戶端收到服務(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為客戶端隨機(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ù)可以被投遞給用戶。連接的數(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：等待本地用戶的連接終止請(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

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

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

復(fù)制

netstat -b

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

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

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

復(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)題：

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

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

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

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

原因

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

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

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

解決方法

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

驗(yàn)證客戶端應(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è)客戶端應(yīng)用程序使用了數(shù)量超常的 TCP/IP 套接字連接，則應(yīng)考慮重新設(shè)計(jì)客戶端應(yīng)用程序，以便更有效地使用 TCP/IP 套接字連接。

注意

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

如果大量客戶端應(yīng)用程序要啟動(dòng)已知數(shù)量的 TCP/IP 套接字連接，但沒(méi)有足夠數(shù)量的可用臨時(shí)端口來(lái)滿足連接請(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)分配到客戶端 TCP/IP 套接字連接的臨時(shí)端口的上限。

降低客戶端 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ú)法重新使用：

值名稱

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)分配到客戶端的臨時(shí)端口的數(shù)量：

值名稱

MaxUserPort

值數(shù)據(jù)

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

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

注意

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

注意

增加用于客戶端 TCP/IP 連接的臨時(shí)端口的范圍將占用 Windows 內(nèi)核內(nèi)存。請(qǐng)勿將此設(shè)置的值增加至超過(guò)容納客戶端應(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>

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

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

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

SYN攻擊，當(dāng)?shù)诙挝帐址?wù)端發(fā)送了syn+ack包之后，收到客戶端發(fā)送的ack之前這段時(shí)間的tcp鏈接成為半連接，此時(shí)服務(wù)端處于syn_recv狀態(tài)。當(dāng)大量客戶端隨機(jī)IP瘋狂發(fā)送tcp鏈接請(qǐng)求時(shí)，客戶端以為是不同用戶的請(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é)議為什么需要三次握手？

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

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

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

第四次：客戶端收到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)行通信。

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

初始化連接和SSL開(kāi)銷消失了，說(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)行咨詢，客服也會(huì)為您講解更多精彩的知識(shí)和內(nèi)容。