原文3年多前發(fā)表在私人站點(diǎn)扛施，現(xiàn)遷移到簡書

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

一畅买、高帶寬和低延遲

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

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

viewport-index

延遲的因素

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

速度延時

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

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

帶寬延時

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

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

最后一公里延時-tracerouter

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

通過tracerouter工具背镇，可以查看路由拓?fù)洌詈笠还锏难舆t與提供商花履、部署方法芽世、網(wǎng)絡(luò)拓?fù)?甚至一天中的哪個時段都有很 大關(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
 1  198.11.175.248 (198.11.175.248)  0.879 ms  0.898 ms  0.950 ms
 2  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
 3  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
 4  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
 5  202.97.51.253 (202.97.51.253)  160.089 ms  160.170 ms  160.077 ms
 6  202.97.35.105 (202.97.35.105)  188.541 ms  190.518 ms  188.903 ms
 7  202.97.33.37 (202.97.33.37)  168.075 ms  168.109 ms  168.016 ms
 8  202.97.55.14 (202.97.55.14)  192.583 ms  192.572 ms  192.591 ms
 9  220.191.135.106 (220.191.135.106)  201.476 ms  201.542 ms  201.465 ms
10  115.236.101.209 (115.236.101.209)  211.315 ms  211.305 ms *
11  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
12  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

二诡壁、高帶寬和低延時

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

低延時

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

2.1 TCP三次握手

viewport-index

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

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

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

2.2 流量控制（窗口rwnd）

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

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

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

rwnd的設(shè)置

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

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

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

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

2.3 慢啟動（cwnd，擁塞窗口）

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

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

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

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

慢啟動過程

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

viewport-index

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

viewport-index

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

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

viewport-index

慢啟動的影響

無論帶寬多大,每個 TCP 連接都必須經(jīng)過慢 啟動階段哼绑。換句話說,我們不可能一上來就完全利用連接的最大帶寬岩馍。

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

對于很多 HTTP 連接,特別是一些短暫抖韩、突發(fā)的連接而言,常常會出現(xiàn)還沒 有達(dá)到最大窗口請求就被終止的情況蛀恩。換句話說,很多 Web 應(yīng)用的性能經(jīng)常受到服 務(wù)器與客戶端之間往返時間的制約。因?yàn)槁龁酉拗屏丝捎玫耐掏铝?而這對于小 文件傳輸非常不利茂浮。

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

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

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

viewport-index

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

作為對比，重用連接止喷，再發(fā)一次請求

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

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

擁塞窗口的合適值

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

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

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

2.4 擁塞預(yù)防

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

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

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

帶寬延遲積

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

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

viewport-index

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

viewport-index

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

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

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

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

viewport-index

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

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

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

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

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

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

• 增大TCP的初始擁塞窗口
  加大起始擁塞窗口可以讓 TCP 在第一次往返就傳輸較多數(shù)據(jù),而隨后的速度提 升也會很明顯管跺。對于突發(fā)性的短暫連接,這也是特別關(guān)鍵的一個優(yōu)化。

• 慢啟動重啟
  在連接空閑時禁用慢啟動可以改善瞬時發(fā)送數(shù)據(jù)的長 TCP 連接的性能禾进。

• 窗口縮放(RFC 1323) 啟用窗口縮放可以增大最大接收窗口大小,可以讓高延遲的連接達(dá)到更好吞 吐量伙菜。

• TCP快速打開
  在某些條件下,允許在第一個 SYN 分組中發(fā)送應(yīng)用程序數(shù)據(jù)。TFO(TCP Fast Open,TCP 快速打開)是一種新的優(yōu)化選項(xiàng),需要客戶端和服務(wù)器共同支持命迈。 為此,首先要搞清楚你的應(yīng)用程序是否可以利用這個特性贩绕。

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

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

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

性能檢查清單

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

參考

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