影響http性能的常見(jiàn)因素是什么

這篇文章主要講解了“影響http性能的常見(jiàn)因素是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“影響http性能的常見(jiàn)因素是什么”吧！

成都創(chuàng)新互聯(lián)公司主營(yíng)黃石港網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,重慶APP開(kāi)發(fā)公司,黃石港h5重慶小程序開(kāi)發(fā)搭建,黃石港網(wǎng)站營(yíng)銷推廣歡迎黃石港等地區(qū)企業(yè)咨詢

TCP連接建立

通常如果網(wǎng)絡(luò)穩(wěn)定TCP連接建立不會(huì)消耗很多時(shí)間而且也都會(huì)在合理耗時(shí)范圍內(nèi)完成三次握手過(guò)程，但是由于HTTP是無(wú)狀態(tài)的屬于短連接，一次HTTP會(huì)話接受后會(huì)斷開(kāi)TCP連接，一個(gè)網(wǎng)頁(yè)通常有很多資源這就意味著會(huì)進(jìn)行很多次HTTP會(huì)話，而相對(duì)于HTTP會(huì)話來(lái)說(shuō)TCP三次握手建立連接就會(huì)顯得太耗時(shí)了，當(dāng)然可以通過(guò)重用現(xiàn)有連接來(lái)減少TCP連接建立次數(shù)。

TCP慢啟動(dòng)

TCP擁塞控制手段1，在TCP剛建立好之后的最初傳輸階段會(huì)限制連接的最大傳輸速度，如果數(shù)據(jù)傳輸成功，后續(xù)會(huì)逐步提高傳輸速度，這就TCP慢啟動(dòng)。慢啟動(dòng)限制了某一時(shí)刻可以傳輸?shù)腎P分組2數(shù)量。那么為什么會(huì)有慢啟動(dòng)呢？主要是為了避免網(wǎng)絡(luò)因?yàn)榇笠?guī)模的數(shù)據(jù)傳輸而癱瘓，在互聯(lián)網(wǎng)上數(shù)據(jù)傳輸很重要的一個(gè)環(huán)節(jié)就是路由器，而路由器本身的速度并不快加之互聯(lián)網(wǎng)上的很多流量都可能發(fā)送過(guò)來(lái)要求其進(jìn)行路由轉(zhuǎn)發(fā)，如果在某一時(shí)間內(nèi)到達(dá)路由器的數(shù)據(jù)量遠(yuǎn)大于其發(fā)送的數(shù)量那么路由器在本地緩存耗盡的情況下就會(huì)丟棄數(shù)據(jù)包，這種丟棄行為被稱作擁塞，一個(gè)路由器出現(xiàn)這種狀況就會(huì)影響很多條鏈路，嚴(yán)重的會(huì)導(dǎo)致大面積癱瘓。所以TCP通信的任何一方需要進(jìn)行擁塞控制，而慢啟動(dòng)就是擁塞控制的其中一種算法或者叫做機(jī)制。
你設(shè)想一種情況，我們知道TCP有重傳機(jī)制，假設(shè)網(wǎng)絡(luò)中的一個(gè)路由器因?yàn)閾砣霈F(xiàn)大面積丟包情況，作為數(shù)據(jù)的發(fā)送方其TCP協(xié)議?？隙〞?huì)檢測(cè)到這種情況，那么它就會(huì)啟動(dòng)TCP重傳機(jī)制，而且該路由器影響的發(fā)送方肯定不止你一個(gè)，那么大量的發(fā)送方TCP協(xié)議棧都開(kāi)始了重傳那這就等于在原本擁塞的網(wǎng)絡(luò)上發(fā)送更多的數(shù)據(jù)包，這就等于火上澆油。

通過(guò)上面的描述得出即便是在正常的網(wǎng)絡(luò)環(huán)境中，作為HTTP報(bào)文的發(fā)送方與每個(gè)請(qǐng)求建立TCP連接都會(huì)受到慢啟動(dòng)影響，那么又根據(jù)HTTP是短連接一次會(huì)話結(jié)束就會(huì)斷開(kāi)，可以想象客戶端發(fā)起HTTP請(qǐng)求剛獲取完web頁(yè)面上的一個(gè)資源，HTTP就斷開(kāi)，有可能還沒(méi)有經(jīng)歷完TCP慢啟動(dòng)過(guò)程這個(gè)TCP連接就斷開(kāi)了，那web頁(yè)面其他的后續(xù)資源還要繼續(xù)建立TCP連接，而每個(gè)TCP連接都會(huì)有慢啟動(dòng)階段，這個(gè)性能可想而知，所以為了提升性能，我們可以開(kāi)啟HTTP的持久連接也就是后面要說(shuō)的keepalive。

另外我們知道TCP中有窗口的概念，這個(gè)窗口在發(fā)送方和接收方都有，窗口的作用一方面保證了發(fā)送和接收方在管理分組時(shí)變得有序；另外在有序的基礎(chǔ)上可以發(fā)送多個(gè)分組從而提高了吞吐量；還有一點(diǎn)就是這個(gè)窗口大小可以調(diào)整，其目的是避免發(fā)送方發(fā)送數(shù)據(jù)的速度比接收方接收的速度快。窗口雖然解決了通信雙發(fā)的速率問(wèn)題，可是網(wǎng)絡(luò)中會(huì)經(jīng)過(guò)其他網(wǎng)絡(luò)設(shè)備，發(fā)送方怎么知道路由器的接收能力呢？所以就有了上面介紹的擁塞控制。

TCP延遲確認(rèn)

首先要知道什么是確認(rèn)，它的意思就是發(fā)送方給接收方發(fā)送一個(gè)TCP分段，接收方收到以后要回傳一個(gè)確認(rèn)表示收到，如果在一定時(shí)間內(nèi)發(fā)送方?jīng)]有收到該確認(rèn)那么就需要重發(fā)該TCP分段。

確認(rèn)報(bào)文通常都比較小，也就是一個(gè)IP分組可以承載多個(gè)確認(rèn)報(bào)文，所以為了避免過(guò)多的發(fā)送小報(bào)文，那么接收方在回傳確認(rèn)報(bào)文的時(shí)候會(huì)等待看看有沒(méi)有發(fā)給接收方的其他數(shù)據(jù)，如果有那么就把確認(rèn)報(bào)文和數(shù)據(jù)一起放在一個(gè)TCP分段中發(fā)送過(guò)去，如果在一定時(shí)間內(nèi)容通常是100-200毫秒沒(méi)有需要發(fā)送的其他數(shù)據(jù)那么就將該確認(rèn)報(bào)文放在單獨(dú)的分組中發(fā)送。其實(shí)這么做的目的也是為了盡可能降低網(wǎng)絡(luò)負(fù)擔(dān)。

一個(gè)通俗的例子就是物流，卡車的載重是一定的，假如是10噸載重，從A城市到B城市，你肯定希望它能盡可能的裝滿一車貨而不是來(lái)了一個(gè)小包裹你就立刻起身開(kāi)向B城市。

所以TCP被設(shè)計(jì)成不是來(lái)一個(gè)數(shù)據(jù)包就馬上返回ACK確認(rèn)，它通常都會(huì)在緩存中積攢一段時(shí)間，如果還有相同方向的數(shù)據(jù)就捎帶把前面的ACK確認(rèn)回傳過(guò)去，但是也不能等的時(shí)間過(guò)長(zhǎng)否則對(duì)方會(huì)認(rèn)為丟包了從而引發(fā)對(duì)方的重傳。

對(duì)于是否使用以及如何使用延遲確認(rèn)不同操作系統(tǒng)會(huì)有不同，比如Linux可以啟用也可以關(guān)閉，關(guān)閉就意味著來(lái)一個(gè)就確認(rèn)一個(gè)，這也是快速確認(rèn)模式。

需要注意的是是否啟用或者說(shuō)設(shè)置多少毫秒，也要看場(chǎng)景。比如在線游戲場(chǎng)景下肯定是盡快確認(rèn)，SSH會(huì)話可以使用延遲確認(rèn)。

對(duì)于HTTP來(lái)說(shuō)我們可以關(guān)閉或者調(diào)整TCP延遲確認(rèn)。

Nagle算法

這個(gè)算法其實(shí)也是為了提高IP分組利用率以及降低網(wǎng)絡(luò)負(fù)擔(dān)而設(shè)計(jì)，這里面依然涉及到小報(bào)文和全尺寸報(bào)文（按以太網(wǎng)的標(biāo)準(zhǔn)MTU1500字節(jié)一個(gè)的報(bào)文計(jì)算，小于1500的都算非全尺寸報(bào)文），但是無(wú)論小報(bào)文怎么小也不會(huì)小于40個(gè)字節(jié)，因?yàn)镮P首部和TCP首部就各占用20個(gè)字節(jié)。如果你發(fā)送一個(gè)50個(gè)字節(jié)小報(bào)文，其實(shí)這就意味著有效數(shù)據(jù)太少，就像延遲確認(rèn)一樣小尺寸包在局域網(wǎng)問(wèn)題不大，主要是影響廣域網(wǎng)。

這個(gè)算法其實(shí)就是如果發(fā)送方當(dāng)前TCP連接中有發(fā)出去但還沒(méi)有收到確認(rèn)的報(bào)文的時(shí)候，那么此時(shí)如果發(fā)送方還有小報(bào)文要發(fā)送的話就不能發(fā)送而是要放到緩沖區(qū)等待之前發(fā)出報(bào)文的確認(rèn)，收到確認(rèn)之后，發(fā)送方會(huì)收集緩存中同方向的小報(bào)文組裝成一個(gè)報(bào)文進(jìn)行發(fā)送。其實(shí)這也就意味著接收方返回ACK確認(rèn)的速度越快，發(fā)送方發(fā)送數(shù)據(jù)也就越快。

現(xiàn)在我們說(shuō)說(shuō)延遲確認(rèn)和Nagle算法結(jié)合將會(huì)帶來(lái)的問(wèn)題。其實(shí)很容易看出，因?yàn)橛醒舆t確認(rèn)，那么接收方則會(huì)在一段時(shí)間內(nèi)積攢ACK確認(rèn)，而發(fā)送方在這段時(shí)間內(nèi)收不到ACK那么也就不會(huì)繼續(xù)發(fā)送剩下的非全尺寸數(shù)據(jù)包（數(shù)據(jù)被分成多個(gè)IP分組，發(fā)送方要發(fā)送的響應(yīng)數(shù)據(jù)的分組數(shù)量不可能一定是1500的整數(shù)倍，大概率會(huì)發(fā)生數(shù)據(jù)尾部的一些數(shù)據(jù)就是小尺寸IP分組），所以你就看出這里的矛盾所在，那么這種問(wèn)題在TCP傳輸中會(huì)影響傳輸性能那么HTTP又依賴TCP所以自然也會(huì)影響HTTP性能，通常我們會(huì)在服務(wù)器端禁用該算法，我們可以在操作系統(tǒng)上禁用或者在HTTP程序中設(shè)置TCP_NODELAY來(lái)禁用該算法。比如在Nginx中你可以使用tcp_nodelay on;來(lái)禁用。

TIME_WAIT積累與端口耗盡3

這里指的是作為客戶端的一方或者說(shuō)是在TCP連接中主動(dòng)關(guān)閉的一方，雖然服務(wù)器也可以主動(dòng)發(fā)起關(guān)閉，但是我們這里討論的是HTTP性能，由于HTTP這種連接的特性，通常都是客戶端發(fā)起主動(dòng)關(guān)閉，

客戶端發(fā)起一個(gè)HTTP請(qǐng)求（這里說(shuō)的是對(duì)一個(gè)特定資源的請(qǐng)求而不是打開(kāi)一個(gè)所謂的主頁(yè)，一個(gè)主頁(yè)有N多資源所以會(huì)導(dǎo)致有N個(gè)HTTP請(qǐng)求的發(fā)起）這個(gè)請(qǐng)求結(jié)束后就會(huì)斷開(kāi)TCP連接，那么該連接在客戶端上的TCP狀態(tài)會(huì)出現(xiàn)一種叫做TIME_WAIT的狀態(tài)，從這個(gè)狀態(tài)到最終關(guān)閉通常會(huì)經(jīng)過(guò)2MSL4的時(shí)長(zhǎng)，我們知道客戶端訪問(wèn)服務(wù)端的HTTP服務(wù)會(huì)使用自己本機(jī)隨機(jī)高位端口來(lái)連接服務(wù)器的80或者443端口來(lái)建立HTTP通信（其本質(zhì)就是TCP通信）這就意味著會(huì)消耗客戶端上的可用端口數(shù)量，雖然客戶端斷開(kāi)連接會(huì)釋放這個(gè)隨機(jī)端口，不過(guò)客戶端主動(dòng)斷開(kāi)連接后，TCP狀態(tài)從TIME_WAIT到真正CLOSED之間的這2MSL時(shí)長(zhǎng)內(nèi)，該隨機(jī)端口不會(huì)被使用（如果客戶端又發(fā)起對(duì)相同服務(wù)器的HTTP訪問(wèn)），其目的之一是為了防止相同TCP套接字上的臟數(shù)據(jù)。通過(guò)上面的結(jié)論我們就知道如果客戶端對(duì)服務(wù)器的HTTP訪問(wèn)過(guò)于密集那么就有可能出現(xiàn)端口使用速度高于端口釋放速度最終導(dǎo)致因沒(méi)有可用隨機(jī)端口而無(wú)法建立連接。

上面我們說(shuō)過(guò)通常都是客戶端主動(dòng)關(guān)閉連接，

TCP/IP詳解 卷1 第二版，P442，最后的一段寫(xiě)到 對(duì)于交互式應(yīng)用程序而言，客戶端通常執(zhí)行主動(dòng)關(guān)閉操作并進(jìn)入TIME_WAIT狀態(tài)，服務(wù)器通常執(zhí)行被動(dòng)關(guān)閉操作并且不會(huì)直接進(jìn)入TIME_WAIT狀態(tài)。

不過(guò)如果web服務(wù)器并且開(kāi)啟了keep-alive的話，當(dāng)達(dá)到超時(shí)時(shí)長(zhǎng)服務(wù)器也會(huì)主動(dòng)關(guān)閉。（我這里并不是說(shuō)TCP/IP詳解錯(cuò)了，而是它在那一節(jié)主要是針對(duì)TCP來(lái)說(shuō)，并沒(méi)有引入HTTP，而且它說(shuō)的是通常而不是一定）

我使用Nginx做測(cè)試，并且在配置文件中設(shè)置了keepalive_timeout 65s;，Nginx的默認(rèn)設(shè)置是75s，設(shè)置為0表示禁用keepalive，如下圖：

下面我使用Chrom瀏覽器訪問(wèn)這個(gè)Nginx默認(rèn)提供的主頁(yè)，并通過(guò)抓包程序來(lái)監(jiān)控整個(gè)通信過(guò)程，如下圖：

從上圖可以看出來(lái)在有效數(shù)據(jù)傳送完畢后，中間出現(xiàn)了Keep-Alive標(biāo)記的通信，并且在65秒內(nèi)沒(méi)有請(qǐng)求后服務(wù)器主動(dòng)斷開(kāi)連接，這種情況你在Nginx的服務(wù)器上就會(huì)看到TIME_WAIT的狀態(tài)。

服務(wù)端端口耗盡

有人說(shuō)Nginx監(jiān)聽(tīng)80或者443，客戶端都是連接這個(gè)端口，服務(wù)端怎么會(huì)端口耗盡呢？就像下圖一樣（忽略圖中的TIME_WAIT，產(chǎn)生這個(gè)的原因上面已經(jīng)說(shuō)過(guò)了是因?yàn)镹ginx的keepalive_timeout設(shè)置導(dǎo)致的）

其實(shí)，這取決于Nginx工作模式，我們使用Nginx通常都是讓其工作在代理模式，這就意味著真正的資源或者數(shù)據(jù)在后端Web應(yīng)用程序上，比如Tomcat。代理模式的特點(diǎn)是代理服務(wù)器代替用戶去后端獲取數(shù)據(jù)，那么此時(shí)相對(duì)于后端服務(wù)器來(lái)說(shuō)，Nginx就是一個(gè)客戶端，這時(shí)候Nginx就會(huì)使用隨機(jī)端口來(lái)向后端發(fā)起請(qǐng)求，而系統(tǒng)可用隨機(jī)端口范圍是一定的，可以使用sysctl net.ipv4.ip_local_port_range命令來(lái)查看服務(wù)器上的隨機(jī)端口范圍。

通過(guò)我們之前介紹的延遲確認(rèn)、Nagle算法以及代理模式下Nginx充當(dāng)后端的客戶端角色并使用隨機(jī)端口連接后端，這就意味著服務(wù)端的端口耗盡風(fēng)險(xiǎn)是存在的。隨機(jī)端口釋放速度如果比與后端建立連接的速度慢就有可能出現(xiàn)。不過(guò)一般不會(huì)出現(xiàn)這個(gè)情況，至少我們公司的Nginx我沒(méi)有發(fā)現(xiàn)有這種現(xiàn)象產(chǎn)生。因?yàn)槭紫仁庆o態(tài)資源都在cdn上；其次后端大部分都是REST接口提供用戶認(rèn)證或者數(shù)據(jù)庫(kù)操作，這些操作其實(shí)后端如果沒(méi)有瓶頸的話基本都很快。不過(guò)話說(shuō)回來(lái)如果后端真的有瓶頸且擴(kuò)容或者改架構(gòu)成本比較高的話，那么當(dāng)面對(duì)大量并發(fā)的時(shí)候你應(yīng)該做的是限流防止后端被打死。

服務(wù)端HTTP進(jìn)程打開(kāi)文件數(shù)量達(dá)到最大

我們說(shuō)過(guò)HTTP通信依賴TCP連接，一個(gè)TCP連接就是一個(gè)套接字，對(duì)于類Unix系統(tǒng)來(lái)說(shuō)，打開(kāi)一個(gè)套接字就是打開(kāi)一個(gè)文件，如果有100個(gè)請(qǐng)求連接服務(wù)端，那么一旦連接建立成功服務(wù)端就會(huì)打開(kāi)100個(gè)文件，而Linux系統(tǒng)中一個(gè)進(jìn)程可以打開(kāi)的文件數(shù)量是有限的ulimit -f，所以如果這個(gè)數(shù)值設(shè)置的太小那么也會(huì)影響HTTP連接。而對(duì)以代理模式運(yùn)行的Nginx或者其他HTTP程序來(lái)說(shuō)，通常一個(gè)連接它就要打開(kāi)2個(gè)套接字也就會(huì)占用2個(gè)文件（命中Nginx本地緩存或者Nginx直接返回?cái)?shù)據(jù)的除外）。所以對(duì)于代理服務(wù)器這個(gè)進(jìn)程可打開(kāi)的文件數(shù)量也要設(shè)置的大一點(diǎn)。

持久連接Keepalive

首先我們要知道keepalive可以設(shè)置在2個(gè)層面上，且2個(gè)層面意義不同。TCP的keepalive是一種探活機(jī)制，比如我們常說(shuō)的心跳信息，表示對(duì)方還在線，而這種心跳信息的發(fā)送由有時(shí)間間隔的，這就意味著彼此的TCP連接要始終保持打開(kāi)狀態(tài)；而HTTP中的keep-alive是一種復(fù)用TCP連接的機(jī)制，避免頻繁建立TCP連接。所以一定明白TCP的Keepalive和HTTP的Keep-alive不是一回事。

HTTP的keep-alive機(jī)制

非持久連接會(huì)在每個(gè)HTTP事務(wù)完成后斷開(kāi)TCP連接，下一個(gè)HTTP事務(wù)則會(huì)再重新建立TCP連接，這顯然不是一種高效機(jī)制，所以在HTTP/1.1以及HTTP/1.0的增強(qiáng)版本中允許HTTP在事務(wù)結(jié)束后將TCP連接保持打開(kāi)狀態(tài)，以便后續(xù)的HTTP事務(wù)可以復(fù)用這個(gè)連接，直到客戶端或者服務(wù)器主動(dòng)關(guān)閉該連接。持久連接減少了TCP連接建立的次數(shù)同時(shí)也最大化的規(guī)避了TCP慢啟動(dòng)帶來(lái)的流量限制。

相關(guān)教程：HTTP視頻教程

再來(lái)看一下這張圖，圖中的keepalive_timeout 65s設(shè)置了開(kāi)啟http的keep-alive特性并且設(shè)置了超時(shí)時(shí)長(zhǎng)為65秒，其實(shí)還有比較重要的選項(xiàng)是keepalive_requests 100;它表示同一個(gè)TCP連接最多可以發(fā)起多少個(gè)HTTP請(qǐng)求，默認(rèn)是100個(gè)。

在HTTP/1.0中keep-alive并不是默認(rèn)使用的，客戶端發(fā)送HTTP請(qǐng)求時(shí)必須帶有Connection: Keep-alive的首部來(lái)試圖激活keep-alive，如果服務(wù)器不支持那么將無(wú)法使用，所有請(qǐng)求將以常規(guī)形式進(jìn)行，如果服務(wù)器支持那么在響應(yīng)頭中也會(huì)包括Connection: Keep-alive的信息。

在HTTP/1.1中默認(rèn)就使用Keep-alive，除非特別說(shuō)明，否則所有連接都是持久的。如果要在一個(gè)事務(wù)結(jié)束后關(guān)閉連接，那么HTTP的響應(yīng)頭中必須包含Connection: CLose首部，否則該連接會(huì)始終保持打開(kāi)狀態(tài)，當(dāng)然也不能總是打開(kāi)，也必須關(guān)閉空閑連接，就像上面Nginx的設(shè)置一樣最多保持65秒的空閑連接，超過(guò)后服務(wù)端將會(huì)主動(dòng)斷開(kāi)該連接。

TCP的keepalive

在Linux上沒(méi)有一個(gè)統(tǒng)一的開(kāi)關(guān)去開(kāi)啟或者關(guān)閉TCP的Keepalive功能，查看系統(tǒng)keepalive的設(shè)置sysctl -a | grep tcp_keepalive，如果你沒(méi)有修改過(guò)，那么在Centos系統(tǒng)上它會(huì)顯示：

1 2 3

net.ipv4.tcp_keepalive_intvl = 75   # 兩次探測(cè)直接間隔多少秒 net.ipv4.tcp_keepalive_probes = 9   # 探測(cè)頻率 net.ipv4.tcp_keepalive_time = 7200  # 表示多長(zhǎng)時(shí)間進(jìn)行一次探測(cè)，單位秒，這里也就是2小時(shí)

按照默認(rèn)設(shè)置，那么上面的整體含義就是2小時(shí)探測(cè)一次，如果第一次探測(cè)失敗，那么過(guò)75秒再探測(cè)一次，如果9次都失敗就主動(dòng)斷開(kāi)連接。

如何開(kāi)啟Nginx上的TCP層面的Keepalive，在Nginx中有一個(gè)語(yǔ)句叫做listen它是server段里面用于設(shè)置Nginx監(jiān)聽(tīng)在哪個(gè)端口的語(yǔ)句，其實(shí)它后面還有其他參數(shù)就是用來(lái)設(shè)置套接字屬性的，看下面幾種設(shè)置：

1 2 3 4 5 6 7

# 表示開(kāi)啟，TCP的keepalive參數(shù)使用系統(tǒng)默認(rèn)的 listen       80 default_server so_keepalive=on; # 表示顯式關(guān)閉TCP的keepalive listen       80 default_server so_keepalive=off; # 表示開(kāi)啟，設(shè)置30分鐘探測(cè)一次，探測(cè)間隔使用系統(tǒng)默認(rèn)設(shè)置，總共探測(cè)10次,這里的設(shè) # 置將會(huì)覆蓋上面系統(tǒng)默認(rèn)設(shè)置 listen       80 default_server so_keepalive=30m::10;

所以是否要在Nginx上設(shè)置這個(gè)so_keepalive，取決于特定場(chǎng)景，千萬(wàn)不要把TCP的keepalive和HTTP的keepalive搞混淆，因?yàn)镹ginx不開(kāi)啟so_keepalive也不影響你的HTTP請(qǐng)求使用keep-alive特性。如果客戶端和Nginx直接或者Nginx和后端服務(wù)器之間有負(fù)載均衡設(shè)備的話而且是響應(yīng)和請(qǐng)求都會(huì)經(jīng)過(guò)這個(gè)負(fù)載均衡設(shè)備，那么你就要注意這個(gè)so_keepalive了。比如在LVS的直接路由模式下就不受影響，因?yàn)轫憫?yīng)不經(jīng)過(guò)
LVS，不過(guò)要是NAT模式就需要留意，因?yàn)長(zhǎng)VS保持TCP會(huì)話也有一個(gè)時(shí)長(zhǎng)，如果該時(shí)長(zhǎng)小于后端返回?cái)?shù)據(jù)的時(shí)長(zhǎng)那么LVS就會(huì)在客戶端還沒(méi)有收到數(shù)據(jù)的情況下斷開(kāi)這條TCP連接。

感謝各位的閱讀，以上就是“影響http性能的常見(jiàn)因素是什么”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)影響http性能的常見(jiàn)因素是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

分享題目：影響http性能的常見(jiàn)因素是什么
URL地址：http://bm7419.com/article40/goceeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、網(wǎng)站維護(hù)、網(wǎng)站設(shè)計(jì)、營(yíng)銷型網(wǎng)站建設(shè)、軟件開(kāi)發(fā)、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)