當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

HTTP请求的TCP瓶颈分析

發(fā)布時(shí)間：2023/12/20 编程问答 43 豆豆

生活随笔收集整理的這篇文章主要介紹了 HTTP请求的TCP瓶颈分析小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

針對(duì)三次握手、流量控制（接收窗口）、慢啟動(dòng)（cwnd，擁塞窗口）、隊(duì)首阻塞等方面看下TCP對(duì)HTTP的影響

這篇文章基本是對(duì)《Web性能權(quán)威指南》第一章和第二章的讀書(shū)筆記，另外加一些擴(kuò)展內(nèi)容,這本書(shū)確實(shí)贊，推薦

高帶寬和低延遲

所有網(wǎng)絡(luò)通信都有決定性影響的兩個(gè)方面:延遲和帶寬

延遲分組從信息源發(fā)送到目的地所需的時(shí)間。
帶寬邏輯或物理通信路徑最大的吞吐量

延遲的因素

傳播延遲?消息從發(fā)送端到接收端需要的時(shí)間（不超過(guò)光速）
傳輸延遲（帶寬/窗口）?把消息中的所有比特轉(zhuǎn)移到鏈路中需要的時(shí)間,是消息長(zhǎng)度和鏈路速率的函數(shù)（10M/s和1M/s的線路，時(shí)間不一樣）
處理延遲?處理分組首部、檢查位錯(cuò)誤及確定分組目標(biāo)所需的時(shí)間（路由器分包）
排隊(duì)延遲?到來(lái)的分組排隊(duì)等待處理的時(shí)間

速度延時(shí)

假定光通過(guò)光纖的速度約為每秒 200 000 000 米,對(duì)應(yīng)的折射率約為 1.5，從紐約到悉尼的一個(gè)往返(RTT)也要花 160 ms，分組旅行的距離比這要長(zhǎng)得多。這條線路中的每一跳都會(huì)涉及尋路、處理、排隊(duì)和傳輸延遲。結(jié)果呢,紐約到悉尼的實(shí)際 RTT, 大約在 200~300 ms 之間。

中美骨干網(wǎng)單向數(shù)據(jù)延時(shí)≈60ms，所以中國(guó)用戶訪問(wèn)美國(guó)主機(jī)數(shù)據(jù)傳輸?shù)难訒r(shí)理論值高于120ms（RTT）

帶寬延時(shí)

核心數(shù)據(jù)路徑的骨干或光纖連接,每秒能夠處理數(shù)百太比特信息，比如中美之間的海底光纖。光纖就是一根“光導(dǎo)管”,傳送光信號(hào)。金屬線則用于傳送電信號(hào),但信號(hào)損失、電磁干擾較大,同時(shí)維護(hù)成本也較高。

通過(guò)波分復(fù)用(WDM,Wavelength-Division Multiplexing)技術(shù),光纖可以同時(shí)傳輸很多不同波長(zhǎng)(信道)的光，2010年初,研究人員已經(jīng)可以在每個(gè)信道中耦合400多種波長(zhǎng)的光線,最大容量可達(dá)171Gbit/s,而一條光纖的總帶寬能夠達(dá)到70Tbit/s

最后一公里延時(shí)-tracerouter

骨干線路可以有TB的帶寬，但是網(wǎng)絡(luò)邊緣的容量就小得多了,而且很大程度上取決于部署技術(shù),比如拔號(hào)連接、 DSL、電纜、各種無(wú)線技術(shù)、光纖到戶。akamai每季度都會(huì)發(fā)布全球的帶寬報(bào)告

通過(guò)tracerouter工具，可以查看路由拓?fù)?#xff0c;最后一公里的延遲與提供商、部署方法、網(wǎng)絡(luò)拓?fù)?甚至一天中的哪個(gè)時(shí)段都有很大關(guān)系。作為最終用戶,如果你想提高自己上網(wǎng)的速度,那選擇延遲最短的ISP是最關(guān)鍵的

 Traceroute sends out three packets per TTL increment. Each column corresponds to the 
time is took to get one packet back (round-trip-time).

traceroute to xx.com (121.41.167.43), 30 hops max, 60 byte packets
198.11.175.248 (198.11.175.248)  0.879 ms  0.898 ms  0.950 ms
10.107.64.14 (10.107.64.14)  0.945 ms 10.107.64.22 (10.107.64.22)  1.033 ms 10.107.64.18 (10.107.64.18)  75.379 ms
198.11.128.162 (198.11.128.162)  135.636 ms 198.11.128.154 (198.11.128.154)  0.913 ms 198.11.128.178 (198.11.128.178)  5.472 ms
218.30.53.93 (218.30.53.93)  4.542 ms 218.30.53.97 (218.30.53.97)  2.144 ms 218.30.53.126 (218.30.53.126)  2.334 ms
202.97.51.253 (202.97.51.253)  160.089 ms  160.170 ms  160.077 ms
202.97.35.105 (202.97.35.105)  188.541 ms  190.518 ms  188.903 ms
202.97.33.37 (202.97.33.37)  168.075 ms  168.109 ms  168.016 ms
202.97.55.14 (202.97.55.14)  192.583 ms  192.572 ms  192.591 ms
220.191.135.106 (220.191.135.106)  201.476 ms  201.542 ms  201.465 ms
115.236.101.209 (115.236.101.209)  211.315 ms  211.305 ms *
42.120.244.194 (42.120.244.194)  270.211 ms 42.120.244.178 (42.120.244.178)  163.768 ms  163.700 ms
42.120.244.238 (42.120.244.238)  191.543 ms 42.120.244.246 (42.120.244.246)  248.825 ms  248.910 ms
 

目標(biāo)

高帶寬
目前還沒(méi)有理由認(rèn)為帶寬會(huì)停止增長(zhǎng)的腳步，就算技術(shù)停滯不前,還是可以鋪設(shè)更多的光纜

低延時(shí)

減少延遲相比帶寬困難的多，從很多方面來(lái)看,我們的基礎(chǔ)設(shè)施似乎也已經(jīng)達(dá)到了這個(gè)極限。這就顯得理解和調(diào)優(yōu)網(wǎng)絡(luò)協(xié)議顯得特別重要

TCP三次握手

客戶端可以在發(fā)送 ACK分組之后立即發(fā)送數(shù)據(jù),而服務(wù)器必須等接收到ACK分組之后才能發(fā)送數(shù)據(jù)。這個(gè)啟動(dòng)通信的過(guò)程適用于所有 TCP 連接,因此對(duì)所有使用TCP的應(yīng)用具有非常大的性能影響,每次傳輸應(yīng)用數(shù)據(jù)之前,都必須經(jīng)歷一次完整的往返

中美之間一次RTT最低120，假設(shè)你發(fā)起一個(gè)簡(jiǎn)單的HTTP請(qǐng)求，需要一次握手+一次數(shù)據(jù)傳輸 = 240ms，浪費(fèi)了50%的時(shí)間，這也意味著提高TCP應(yīng)用性能的關(guān)鍵在于想辦法重用連接

擴(kuò)展：TFO(TCP Fast Open,TCP 快速打開(kāi))機(jī)制,致力于減少新建 TCP 連接帶來(lái)的性能損失

流量控制（窗口rwnd）

rwnd是端到端的控制機(jī)制，預(yù)防發(fā)送過(guò)多的數(shù)據(jù),TCP連接的每一方都會(huì)通告自己的接收窗口,其中包含能夠保存數(shù)據(jù)的緩沖區(qū)空間大小信息。TCP 連接的整個(gè)生命周期:每個(gè) ACK 分組都會(huì)攜帶相應(yīng)的最新rwnd 值,以便兩端動(dòng)態(tài)調(diào)整數(shù)據(jù)流速,使之適應(yīng)發(fā)送端和接收端的容量及處理能力

窗口的值原來(lái)只有16位，即65535，所以以前rwnd的最大值不能超過(guò)64K。現(xiàn)在基本都有了“TCP 窗口縮放”(TCP Window Scaling)，把接收窗口大小由 65 535 字節(jié)提高到 1G 字節(jié)，在 Linux 中,可以通過(guò)如下命令檢查和啟用窗口縮放選項(xiàng):

1 2	$> sysctl net.ipv4.tcp_window_scaling $> sysctl -w net.ipv4.tcp_window_scaling=1

rwnd的設(shè)置

如果我們出于傳輸性能的考慮，當(dāng)然這個(gè)值設(shè)置的越大越好,Linux中通過(guò)配置內(nèi)核參數(shù)里接收緩沖的大小，進(jìn)而可以控制接收窗口的大小：

1 2	shell> sysctl -a \| grep mem net.ipv4.tcp_rmem = <MIN> <DEFAULT> <MAX>

還有個(gè)問(wèn)題,當(dāng)大量請(qǐng)求同時(shí)到達(dá)時(shí)，內(nèi)存會(huì)不會(huì)爆掉？通常不會(huì)，因?yàn)長(zhǎng)inux本身有一個(gè)緩沖大小自動(dòng)調(diào)優(yōu)的機(jī)制，窗口的實(shí)際大小會(huì)自動(dòng)在最小值和最大值之間浮動(dòng)，以期找到性能和資源的平衡點(diǎn)。

1 2	通過(guò)如下方式可以確認(rèn)緩沖大小自動(dòng)調(diào)優(yōu)機(jī)制的狀態(tài)（0：關(guān)閉、1：開(kāi)啟）： shell> sysctl -a \| grep tcp_moderate_rcvbuf

慢啟動(dòng)（cwnd，擁塞窗口）

兩端流量控制確實(shí)可以防止發(fā)送端向接收端過(guò)多發(fā)送數(shù)據(jù),但卻沒(méi)有機(jī)制預(yù)防任何一端向潛在網(wǎng)絡(luò)過(guò)多發(fā)送數(shù)據(jù)。換句話說(shuō),發(fā)送端和接收端在連接建立之初,誰(shuí)也不知道可用帶寬是多少,因此需要一個(gè)估算機(jī)制,然后根據(jù)網(wǎng)絡(luò)中不斷變化的條件而動(dòng)態(tài)改變速度:TCP能傳輸?shù)淖畲髷?shù)據(jù) = MIN（rwnd,cwnd）

慢啟動(dòng)的算法如下(cwnd全稱Congestion Window)：

1）連接建好的開(kāi)始先初始化cwnd = 1，表明可以傳一個(gè)MSS大小的數(shù)據(jù)。
2）每當(dāng)收到一個(gè)ACK，cwnd++; 呈線性上升
3）每當(dāng)過(guò)了一個(gè)RTT，cwnd = cwnd*2; 呈指數(shù)讓升
4）還有一個(gè)ssthresh（slow start threshold），是一個(gè)上限，當(dāng)cwnd >= ssthresh時(shí)，就會(huì)進(jìn)入“擁塞避免算法”（后面會(huì)說(shuō)這個(gè)算法）

最初,cwnd 的值只有1個(gè)TCP segment。99 年 4 月,RFC 2581 將其增加到了 4 個(gè) TCP segment。2013 年 4 月,RFC 6928 再次將其提高到 10 個(gè) TCP segment

慢啟動(dòng)過(guò)程

服務(wù)器向客戶端發(fā)送 4 個(gè) TCP segment,然后就必須停下來(lái)等待確認(rèn)。此后,每收到一個(gè) ACK, 慢啟動(dòng)算法就會(huì)告訴服務(wù)器可以將它的 cwnd 窗口增加 1 個(gè) TCP segment.這個(gè)階段通常被稱為指數(shù)增長(zhǎng)階段,因?yàn)榭蛻舳撕头?wù)器都在向兩者之間網(wǎng)絡(luò)路徑的有效帶寬迅速靠攏

計(jì)算達(dá)到指定窗口所需要的時(shí)間公式：

客戶端和服務(wù)器的接收窗口為 65 535 字節(jié)(64 KB);
初始的擁塞窗口:4 個(gè)segment(一個(gè)segment 一般是1460B);
往返時(shí)間是 56 ms(倫敦到紐約)。

為了達(dá)到64KB限制，我們將需要把擁塞窗口增加到45個(gè)segment，這將花費(fèi)224毫秒。

慢啟動(dòng)的影響

無(wú)論帶寬多大,每個(gè) TCP 連接都必須經(jīng)過(guò)慢啟動(dòng)階段。換句話說(shuō),我們不可能一上來(lái)就完全利用連接的最大帶寬。

慢啟動(dòng)導(dǎo)致客戶端與服務(wù)器之間經(jīng)過(guò)幾百 ms 才能達(dá)到接近最大速度的問(wèn)題,對(duì)于大型流式下載服務(wù)的影響不顯著,因?yàn)槁龁?dòng)的時(shí)間可以分?jǐn)偟秸麄€(gè)傳輸周期內(nèi)消化掉。

對(duì)于很多 HTTP 連接,特別是一些短暫、突發(fā)的連接而言,常常會(huì)出現(xiàn)還沒(méi) 有達(dá)到最大窗口請(qǐng)求就被終止的情況。換句話說(shuō),很多 Web 應(yīng)用的性能經(jīng)常受到服務(wù)器與客戶端之間往返時(shí)間的制約。因?yàn)槁龁?dòng)限制了可用的吞吐量,而這對(duì)于小文件傳輸非常不利。

慢啟動(dòng)對(duì)HTTP影響的一次計(jì)算

假設(shè)通過(guò)HTTP傳輸一個(gè)20K的文件，初始條件：

往返時(shí)間:56 ms。
客戶端到服務(wù)器的帶寬:5 Mbit/s。
客戶端和服務(wù)器接收窗口:65 535 字節(jié)。
初始的擁塞窗口:4 segment(4×1460 字節(jié) ≈ 5.7 KB)。
服務(wù)器生成響應(yīng)的處理時(shí)間:40 ms。
沒(méi)有分組丟失、每個(gè)分組都要確認(rèn)、GET 請(qǐng)求只占 1 段。

0 ms:客戶端發(fā)送 SYN 分組開(kāi)始 TCP 握手。
28 ms:服務(wù)器響應(yīng) SYN-ACK 并指定其 rwnd 大小。
56 ms:客戶端確認(rèn) SYN-ACK,指定其 rwnd 大小,并立即發(fā)送 HTTP GET 請(qǐng)求。
8 84 ms:服務(wù)器收到 HTTP 請(qǐng)求。
124 ms:服務(wù)器生成 20 KB 的響應(yīng),并發(fā)送 4 個(gè) TCP 段(初始 cwnd 大小為 4),
然后等待 ACK。
152 ms:客戶端收到 4 個(gè)段,并分別發(fā)送 ACK 確認(rèn)。
180 ms:服務(wù)器針對(duì)每個(gè) ACK 遞增 cwnd,然后發(fā)送 8 個(gè) TCP 段。
208 ms:客戶端接收 8 個(gè)段,并分別發(fā)送 ACK 確認(rèn)。
236 ms:服務(wù)器針對(duì)每個(gè) ACK 遞增 cwnd,然后發(fā)送剩余的 TCP 段。
264 ms:客戶端收到剩余的 TCP 段,并分別發(fā)送 ACK 確認(rèn)。

作為對(duì)比，重用連接，再發(fā)一次請(qǐng)求

0 ms:客戶端發(fā)送 HTTP 請(qǐng)求。
28 ms:服務(wù)器收到 HTTP 請(qǐng)求。
68 ms:服務(wù)器生成 20 KB 響應(yīng),但 cwnd 已經(jīng)大于發(fā)送文件所需的 15 段了,因
此一次性發(fā)送所有數(shù)據(jù)段。
96 ms:客戶端收到所有 15 個(gè)段,分別發(fā)送 ACK 確認(rèn)。

同一個(gè)連接、同樣的請(qǐng)求,但沒(méi)有三次握手和慢啟動(dòng),只花了 96 ms,性能提升幅度達(dá) 275% !

擁塞窗口的合適值

Google在這方面做了大量的研究，權(quán)衡了效率和穩(wěn)定性之后，最終給出的建議是10MSS。如果你的Linux版本不太舊的話，那么可以通過(guò)如下方法來(lái)調(diào)整「cwnd」初始值：

 shell> ip route | while read p; do
           ip route change $p initcwnd 10;
       done
 

需要提醒的是片面的提升發(fā)送端「cwnd」的大小并不一定有效，這是因?yàn)榍懊嫖覀冋f(shuō)過(guò)網(wǎng)絡(luò)中實(shí)際傳輸?shù)奈唇?jīng)確認(rèn)的數(shù)據(jù)大小取決于「rwnd」和「cwnd」中的小值，所以一旦接收方的「rwnd」比較小的話，會(huì)阻礙「cwnd」的發(fā)揮。

擁塞預(yù)防

擁塞預(yù)防算法把丟包作為網(wǎng)絡(luò)擁塞的標(biāo)志,即路徑中某個(gè)連接或路由器已經(jīng)擁堵了, 以至于必須采取刪包措施。因此,必須調(diào)整窗口大小,以避免造成更多的包丟失, 從而保證網(wǎng)絡(luò)暢通。

重置擁塞窗口后,擁塞預(yù)防機(jī)制按照自己的算法來(lái)增大窗口以盡量避免丟包。某個(gè) 時(shí)刻,可能又會(huì)有包丟失,于是這個(gè)過(guò)程再?gòu)念^開(kāi)始。如果你看到過(guò) TCP 連接的吞吐量跟蹤曲線,發(fā)現(xiàn)該曲線呈鋸齒狀,那現(xiàn)在就該明白為什么了。這是擁塞控制和預(yù)防算法在調(diào)整擁塞窗口,進(jìn)而消除網(wǎng)絡(luò)中的丟包問(wèn)題。

最初,TCP 使用 AIMD(Multiplicative Decrease and Additive Increase,倍減加增) 算法,即發(fā)生丟包時(shí),先將擁塞窗口減半,然后每次往返再緩慢地給窗口增加一個(gè)固定的值。不過(guò),很多時(shí)候 AIMD 算法太過(guò)保守,因此又有了很多新的算法，比如DSACK：可以讓協(xié)議知道是什么原因丟包，是重傳還是丟失

帶寬延遲積

發(fā)送端和接收端之間在途未確認(rèn)的最大數(shù)據(jù)量,取決于擁塞窗口(cwnd)和接收窗口(rwnd)的最小值。接收窗口會(huì)隨每次 ACK 一起發(fā)送,而擁塞窗口則由發(fā)送端根據(jù)擁塞控制和預(yù)防算法動(dòng)態(tài)調(diào)整.

BDP(Bandwidth-delay product,帶寬延遲積)
數(shù)據(jù)鏈路的容量與其端到端延遲的乘積。這個(gè)結(jié)果就是任意時(shí)刻處于在途未確認(rèn) 狀態(tài)的最大數(shù)據(jù)量。無(wú)論發(fā)送端發(fā)送的數(shù)據(jù)還是接收端接收的數(shù)據(jù)超過(guò)了未確認(rèn)的最大數(shù)據(jù)量,都必須停下來(lái)等待另一方 ACK 確認(rèn)某些分組才能繼續(xù)

那么,流量控制窗口(rwnd)和擁塞控制窗口(cwnd)的值多大合適?實(shí)際上,計(jì)算過(guò)程很簡(jiǎn)單。首先,假設(shè) cwnd 和 rwnd 的最小值為 16 KB,往返時(shí)間為 100 ms:

不管發(fā)送端和接收端的實(shí)際帶寬多大,這個(gè) TCP 連接的數(shù)據(jù)傳輸速率不會(huì)超過(guò) 1.31 Mbit/s !想提高吞吐量,要么增大最小窗口值,要么減少往返時(shí)間。窗口至少需要 122.1 KB 才能充分利用 10 Mbit/s 帶寬!如果沒(méi)有“窗口縮放(RFC 1323)”,TCP 接收窗口最大只有 64 KB

隊(duì)首阻塞造成的延時(shí)

每個(gè) TCP 分組都會(huì)帶著一個(gè)唯一的序列號(hào)被發(fā)出,而所有分組必須按順序傳送到接收端。如果中途有一個(gè)分組沒(méi)能到達(dá)接收端,那么后續(xù)分組必須保存在接收端的 TCP 緩沖區(qū),等待丟失的分組重發(fā)并到達(dá)接收端。這一切都發(fā)生在 TCP 層,應(yīng)用程序?qū)?TCP 重發(fā)和緩沖區(qū)中排隊(duì)的分組一無(wú)所知,必須等待分組全部到達(dá)才能訪問(wèn)數(shù)據(jù)。在此之前,應(yīng)用程序只能在通過(guò)套接字讀數(shù)據(jù)時(shí)感覺(jué)到延遲交付。這種效應(yīng)稱為?TCP 的隊(duì)首(HOL,Head of Line)阻塞

隊(duì)首阻塞造成的延遲可以讓我們的應(yīng)用程序不用關(guān)心分組重排和重組,從而讓代碼保持簡(jiǎn)潔。然而,代碼簡(jiǎn)潔也要付出代價(jià),那就是分組到達(dá)時(shí)間會(huì)存在無(wú)法預(yù)知的延遲變化。這個(gè)時(shí)間變化通常被稱為抖動(dòng)

事實(shí)上,某些場(chǎng)景下,丟包是讓 TCP 達(dá)到最佳性能的關(guān)鍵。有些應(yīng)用程序可以容忍丟失一定數(shù)量的包,比如語(yǔ)音和游戲狀態(tài)通信,就不需要可靠傳輸或按序交付

針對(duì)TCP的優(yōu)化建議

每個(gè)算法和反饋機(jī)制的具體細(xì)節(jié)可能會(huì)繼續(xù)發(fā)展,但核心原理以及它們的影響是不變的:

TCP 三次握手增加了整整一次往返時(shí)間;
TCP 慢啟動(dòng)將被應(yīng)用到每個(gè)新連接;
TCP 流量及擁塞控制會(huì)影響所有連接的吞吐量;
TCP 的吞吐量由當(dāng)前擁塞窗口大小控制。

結(jié)果,現(xiàn)代高速網(wǎng)絡(luò)中 TCP 連接的數(shù)據(jù)傳輸速度,往往會(huì)受到接收端和發(fā)送端之間往返時(shí)間的限制。另外,盡管帶寬不斷增長(zhǎng),但延遲依舊受限于光速,而且已經(jīng) 限定在了其最大值的一個(gè)很小的常數(shù)因子之內(nèi)。大多數(shù)情況下,TCP 的瓶頸都是延遲,而非帶寬

服務(wù)器配置調(diào)優(yōu)

增大TCP的初始擁塞窗口
加大起始擁塞窗口可以讓 TCP 在第一次往返就傳輸較多數(shù)據(jù),而隨后的速度提升也會(huì)很明顯。對(duì)于突發(fā)性的短暫連接,這也是特別關(guān)鍵的一個(gè)優(yōu)化。
慢啟動(dòng)重啟
在連接空閑時(shí)禁用慢啟動(dòng)可以改善瞬時(shí)發(fā)送數(shù)據(jù)的長(zhǎng) TCP 連接的性能。
窗口縮放(RFC 1323) 啟用窗口縮放可以增大最大接收窗口大小,可以讓高延遲的連接達(dá)到更好吞吐量。
TCP快速打開(kāi)
在某些條件下,允許在第一個(gè) SYN 分組中發(fā)送應(yīng)用程序數(shù)據(jù)。TFO(TCP Fast Open,TCP 快速打開(kāi))是一種新的優(yōu)化選項(xiàng),需要客戶端和服務(wù)器共同支持。為此,首先要搞清楚你的應(yīng)用程序是否可以利用這個(gè)特性。

以上幾個(gè)設(shè)置再加上最新的內(nèi)核,可以確保最佳性能:每個(gè) TCP 連接都會(huì)具有較低的延遲和較高的吞吐量。

應(yīng)用程序行為調(diào)優(yōu)

再快也快不過(guò)什么也不用發(fā)送,能少發(fā)就少發(fā)。
我們不能讓數(shù)據(jù)傳輸?shù)酶?但可以讓它們傳輸?shù)木嚯x更短。
重用 TCP 連接是提升性能的關(guān)鍵

性能檢查清單

把服務(wù)器內(nèi)核升級(jí)到最新版本(Linux:3.2+);
確保 cwnd 大小為 10;
禁用空閑后的慢啟動(dòng);
確保啟動(dòng)窗口縮放;
減少傳輸冗余數(shù)據(jù);
壓縮要傳輸?shù)臄?shù)據(jù);
把服務(wù)器放到離用戶近的地方以減少往返時(shí)間;
盡最大可能重用已經(jīng)建立的 TCP 連接

參考

美國(guó)機(jī)房及中美網(wǎng)絡(luò)延時(shí)狀況
淺談TCP優(yōu)化（rwnd和cwnd的測(cè)量和計(jì)算）
TCP 的那些事兒（上）
What is the TCP/IP Stack

總結(jié)

以上是生活随笔為你收集整理的HTTP请求的TCP瓶颈分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：操作系统进程管理（三）——进程同步方法
下一篇：崩溃优化（一）