訪問(wèn) Web 網(wǎng)站和應(yīng)用時(shí)，經(jīng)常會(huì)遇到各種各樣的性能問(wèn)題。比如網(wǎng)頁(yè)加載慢、視頻卡、網(wǎng)絡(luò)出錯(cuò)等，其中一個(gè)關(guān)鍵的影響因素就是網(wǎng)絡(luò)協(xié)議。本文會(huì)系統(tǒng)化地介紹 TCP、UDP、HTTP1.1、HTTPS（包括最新的 TLS1.3 協(xié)議）、SPDY、HTTP2 等協(xié)議存在的問(wèn)題，以及如何在特定的場(chǎng)景下通過(guò)網(wǎng)絡(luò)…
訪問(wèn) Web 網(wǎng)站和應(yīng)用時(shí)，經(jīng)常會(huì)遇到各種各樣的性能問(wèn)題。比如網(wǎng)頁(yè)加載慢、視頻卡、網(wǎng)絡(luò)出錯(cuò)等，其中一個(gè)關(guān)鍵的影響因素就是網(wǎng)絡(luò)協(xié)議。本文會(huì)系統(tǒng)化地介紹 TCP、UDP、HTTP1.1、HTTPS（包括最新的 TLS1.3 協(xié)議）、SPDY、HTTP2 等協(xié)議存在的問(wèn)題，以及如何在特定的場(chǎng)景下通過(guò)網(wǎng)絡(luò)協(xié)議的優(yōu)化實(shí)現(xiàn)訪問(wèn)速度的提升。
注：本文整理自騰訊 TEG 基礎(chǔ)架構(gòu)部高級(jí)工程師羅成在 ArchSummit 2017 深圳站上的演講。
前言：WEB 性能優(yōu)化的問(wèn)題
提到 WEB 性能優(yōu)化，那也就意味著我們遇到了很多性能方面的問(wèn)題。
Web 加速，協(xié)議先行！
如上圖所示，看到這一行字，我相信大家的腦海里一定會(huì)浮現(xiàn)出很多的場(chǎng)景畫(huà)面，比如說(shuō)無(wú)法接入網(wǎng)絡(luò)，又比如說(shuō)頁(yè)面一直在加載，或者說(shuō)內(nèi)容可能一直卡在 99% 加載不出來(lái)，包括視頻的卡頓、短視頻以及直播，還有從 wifi 切到 4G 網(wǎng)絡(luò)出現(xiàn)重新加載的情況，那遇到這么多的 web 問(wèn)題，其主要原因是什么呢？
我進(jìn)行簡(jiǎn)單羅列一下，歸納為有以下兩種情況。
Web 加速，協(xié)議先行！
直接和頁(yè)面相關(guān)的頁(yè)面大小，頁(yè)面的元素類(lèi)型的多少，也就是說(shuō)一個(gè)頁(yè)面越大，元素越多，動(dòng)態(tài)的交互越頻繁，那相應(yīng)的性能可能就會(huì)受到更大影響。頁(yè)面優(yōu)化問(wèn)題也是前端優(yōu)化的主戰(zhàn)場(chǎng)。
網(wǎng)絡(luò)環(huán)境以及端配置，包括用戶手機(jī)硬件的性能、軟件的操作系統(tǒng)版本，也會(huì)對(duì)性能產(chǎn)生影響。而這兩個(gè)主要和運(yùn)營(yíng)商以及用戶的配置有關(guān)，也是我們很難施加影響的一部分。
網(wǎng)絡(luò)協(xié)議
今天，我將著重介紹網(wǎng)絡(luò)協(xié)議。網(wǎng)絡(luò)協(xié)議是一個(gè)非常重要、非常關(guān)鍵、但又很容易被大家忽略的一個(gè)因素。那么提到網(wǎng)絡(luò)協(xié)議，我們會(huì)遇到或者會(huì)用到哪一些網(wǎng)絡(luò)協(xié)議呢？
接下來(lái)，我以現(xiàn)在最主流的互聯(lián)網(wǎng)下一代 HTTP2 協(xié)議為例，來(lái)簡(jiǎn)單地介紹一下。
Web 加速，協(xié)議先行！
如上圖所示，WEB 請(qǐng)求需要經(jīng)過(guò)的協(xié)議棧。該圖左邊是客戶端，右邊是數(shù)據(jù)中心，或者說(shuō)服務(wù)端。
請(qǐng)求從客戶端發(fā)出之后，首先會(huì)經(jīng)過(guò) HTTP1.1 協(xié)議。那為什么標(biāo)題是 HTTP2 請(qǐng)求，但卻提到的是 HTTP1.1？這是因?yàn)?HTTP2 雖然是一個(gè)全新的協(xié)議，但是它還是沿用了大部分 HTTP1.1 的語(yǔ)義。比如說(shuō) GET 請(qǐng)求、POST 請(qǐng)求，都是使用 HTTP1.1 的語(yǔ)義。對(duì)于頁(yè)面或者對(duì)于 JavaScript 來(lái)講，我們?nèi)匀皇褂弥?HTTP1.1 的語(yǔ)義。HTTP1.1 下一層就到了 HTTP2， HTTP2 使用全新的幀控制語(yǔ)義，換句話說(shuō)，HTTP2 frame 進(jìn)行封裝 HTTP1.1 的語(yǔ)義，比如說(shuō) GET 請(qǐng)求，它通過(guò)使用 HTTP2 的 HEADERS 實(shí)現(xiàn)封裝；POST 請(qǐng)求的 body 數(shù)據(jù)使用 HTTP2 的 data frame 來(lái)實(shí)現(xiàn)封裝。然后到達(dá) TLS 協(xié)議，傳輸加密層，那這里為什么會(huì)有加密呢？
其主要原因是 HTTP2 RFC7540 協(xié)議規(guī)定 HTTP2 有兩種實(shí)現(xiàn)，一種是 H2，強(qiáng)制使用 TLS 進(jìn)行加密；另外一種是 H2C，這里的 C 是 clear, 就是明文，不需要加密。雖然協(xié)議是這么規(guī)定的，但是所有的主流實(shí)現(xiàn)，包括所有的瀏覽器、所有的操作系統(tǒng)、到目前為止都是使用 TLS 加密。也就是說(shuō)，如果使用 HTTP2 就一定要使用 TLS 加密，所以在這過(guò)程中遇到 TLS 的問(wèn)題。然后再往下是 TCP 層，再繼續(xù)往下是 IP 網(wǎng)絡(luò)層，以及以太網(wǎng)、運(yùn)營(yíng)商網(wǎng)絡(luò)物理層，之后到達(dá)右邊服務(wù)端協(xié)議上。兩邊端口可以認(rèn)為是對(duì)稱(chēng)的，因此不再進(jìn)行介紹。
那這么多協(xié)議，我們應(yīng)該需要關(guān)注哪一些呢？或者說(shuō)更明確地說(shuō)，對(duì)我們大部分 WEB 應(yīng)用開(kāi)發(fā)者來(lái)講，我們需要關(guān)注哪一些呢? 上圖中白色虛線往上的部分是客戶端可以施加影響或者優(yōu)化的一部分，即協(xié)議上提出的包括 TCP、TLS 協(xié)議，以及再往上的 HTTP。明確了我們需要優(yōu)化的協(xié)議，那么接下來(lái)我來(lái)分析一下他們都會(huì)有哪些問(wèn)題。
HTTP1.1 的性能
HTTP1.1 的性能問(wèn)題
Web 加速，協(xié)議先行！
以現(xiàn)在使用最廣泛、歷史最悠久的 HTTP1.1 協(xié)議說(shuō)起。
接觸 web 開(kāi)發(fā)的同學(xué)都知道，HTTP1.1 最大的性能問(wèn)題就是單鏈路串行。當(dāng)一個(gè) TCP 鏈接上如果有多個(gè)請(qǐng)求。如上圖所示。請(qǐng)求只能一個(gè)接著一個(gè)發(fā)送，這是它最大的問(wèn)題。
第二個(gè)問(wèn)題是頭部未壓縮。頭部，尤其當(dāng) HTTP 請(qǐng)求 Cookie、Host，其瀏覽器型號(hào)都一樣，如果每次請(qǐng)求攜帶相同的信息，這顯然是重復(fù)的。這是冗余，浪費(fèi)帶寬，并且從性能問(wèn)題上會(huì)影響用戶的訪問(wèn)速度。為什么呢？因?yàn)檫\(yùn)營(yíng)商的網(wǎng)絡(luò)上下行帶寬嚴(yán)重不對(duì)稱(chēng)，上行帶寬很可能只有下行帶寬 1/10 甚至小于 1/10，也就是說(shuō)，若其帶寬有十兆或者一兆，那么它上行鏈路可能只有 100K 甚至幾十 K。如果頭部平均大小是 1500 個(gè)字節(jié)，其一次傳出可能有十個(gè)頭部，并且在帶寬層面會(huì)影響用戶訪問(wèn)性能。因此在 3G、4G 的移動(dòng)網(wǎng)絡(luò)環(huán)境下，頭部未壓縮問(wèn)題顯得更為重要。
HTTP1.1 的優(yōu)化
優(yōu)化的手段、優(yōu)化的策略非常多，也非常有效，那么有哪些呢？
Web 加速，協(xié)議先行！
概括來(lái)講，HTTP1.1 的優(yōu)化方向主要是兩點(diǎn)。
第一點(diǎn)是增加并發(fā)連接數(shù)量；第二點(diǎn)是減少往外發(fā)出的請(qǐng)求數(shù)量。如上圖，不管是單域名多 TCP 連接，還是域名分片，使用多個(gè)域名都是為了提升并發(fā)連接的數(shù)量。需要注意的是并發(fā)連接不是并發(fā)請(qǐng)求。因?yàn)?HTTP1.1 嘗試在單鏈接上實(shí)現(xiàn)并發(fā)請(qǐng)求，但是失敗了。比如 pipelining，因?yàn)樗嬖陉?duì)頭阻塞。所以它只能通過(guò)提升并發(fā)連接的數(shù)量來(lái)提升用戶的訪問(wèn)性能。此外，也有其他一些優(yōu)化策略，包括緩存、CSS Sprite、data uri，圖片內(nèi)聯(lián)等。其本質(zhì)都是為了減少發(fā)出請(qǐng)求的數(shù)量，即將多個(gè)響應(yīng)放在一個(gè)響應(yīng)里面返回，以此減少請(qǐng)求數(shù)量。
以上這些 HTTP1.1 優(yōu)化策略和手段在 HTTP1.1 時(shí)代取得非常好的效果, 并且也行之有效。
HTTPS/HTTP2 加速 HTTP1.1 的淘汰
隨著 HTTPS 的全站趨勢(shì)越來(lái)越明顯， HTTP2 正式發(fā)布漸成主流，HTTP1.1 的優(yōu)化策略隨之失效了。為什么這么說(shuō)呢？
HTTPS 性能的一個(gè)特點(diǎn)或者說(shuō)缺點(diǎn)是連接成本非常高，如果 HTTP1.1 使用增加并發(fā)連接的方式來(lái)提升性能，由于其連接成本很高，那么并發(fā)連接的并發(fā)成本也就會(huì)高，反而降低了性能。
HTTP2 的特性是支持多路復(fù)用。在一個(gè)鏈接上允許發(fā)出多個(gè)請(qǐng)求，允許并發(fā)請(qǐng)求。那 HTTP1.1 減少請(qǐng)求數(shù)量就顯得有點(diǎn)多余，相反地，有可能會(huì)降低緩存命中率，降低性能。
所以從這個(gè)層面來(lái)講， http1.1 的優(yōu)化策略有可能行不通，并且產(chǎn)生副作用的。
HTTP 與 HTTPS 的比較
HTTP VS HTTPS 連接成本
接下來(lái)我簡(jiǎn)單介紹一下 HTTPS 的連接成本為什么會(huì)高？從協(xié)議層面，它的連接成本高在哪里？
Web 加速，協(xié)議先行！
如上圖，左邊圖是一次 HTTP1.1 的請(qǐng)求過(guò)程或者說(shuō)是成本。HTTP1.1 請(qǐng)求非常簡(jiǎn)單，只需要建立 TCP 連接，然后發(fā)送 HTTP 請(qǐng)求和響應(yīng)就完成了?？傔^(guò)程只需要兩個(gè) RTT 就可以實(shí)現(xiàn)一次 HTTP 請(qǐng)求。
右邊圖是一次 HTTPS 的請(qǐng)求。首先 HTTPS 通過(guò)三次握手建立 TCP 連接；然后發(fā)送 HTTP1.1 請(qǐng)求. 這里為什么是 HTTP1.1 的數(shù)據(jù)呢？因?yàn)槿绻層脩糁鲃?dòng)輸入 URL，大多數(shù)用戶不會(huì)主動(dòng)輸入 HTTPS，比如說(shuō)，訪問(wèn)騰訊網(wǎng), 他們不會(huì)輸入 https://www.qq.com, 而是輸入 www.qq.com 或者 http://www.qq.com。為了強(qiáng)制用戶使用 HTTPS 就會(huì)返回一個(gè) 302 跳轉(zhuǎn)，關(guān)于 302 跳轉(zhuǎn)，HTTPS 使用的端口是 443，HTTP 是 80；新的端口就必須重新建立一個(gè)新的 TCP 連接，這樣又多了一次 TCP 連接的建立過(guò)程；建立 TCP 連接之后，開(kāi)始進(jìn)行 TLS 握手階段。
TLS 握手有兩個(gè)階段，完全握手階段一，協(xié)商協(xié)議版本、密碼套件、請(qǐng)求證書(shū)、校驗(yàn)證書(shū)；客戶端拿到證書(shū)之后即使證書(shū)的簽名沒(méi)有問(wèn)題，證書(shū)時(shí)間也有效，但是仍然需要校驗(yàn)證書(shū)的狀態(tài)，因?yàn)橛锌赡艽嬖谥鲃?dòng)撤銷(xiāo)證書(shū)的情況，證書(shū)的匙鑰也有可能被泄露或者說(shuō) CA 被攻擊，所以查詢(xún)證書(shū)狀態(tài)是必要的。查詢(xún)證書(shū)狀態(tài)就是 OCSP，在線證書(shū)狀態(tài)檢查，查詢(xún)證書(shū)狀態(tài)需要解析個(gè) CA 的三點(diǎn) DNS，又需要建立 TCP 連接，然后又需要建立包括 OCSP 的請(qǐng)求響應(yīng)，通過(guò) HTTP 請(qǐng)求完成，三次握手、狀態(tài)沒(méi)問(wèn)題之后，開(kāi)始進(jìn)行 TLS 完全握手階段二，協(xié)商對(duì)稱(chēng)密鑰，即非對(duì)稱(chēng)密鑰交換計(jì)算；完成之后，整個(gè) TLS 過(guò)程協(xié)商完畢，開(kāi)始發(fā)送 HTTP 加密數(shù)據(jù)。至此達(dá)到第九個(gè) RTT，相比 http1.1 多出 7 個(gè) RTT，這是什么概念呢？
未經(jīng)優(yōu)化的 HTTPS 速度明顯慢于 HTTP
Web 加速，協(xié)議先行！
如上圖，現(xiàn)在最好的 wifi 網(wǎng)絡(luò)環(huán)境下平均 RTT 是 70 毫秒，7 個(gè) RTT 就是 490 毫秒，4G 是 100 毫秒，3G 是 200 毫秒， 7 個(gè) RTT 就是一秒多鐘。且這僅僅是一次請(qǐng)求，一個(gè)頁(yè)面一般會(huì)有很多個(gè)請(qǐng)求，并且請(qǐng)求之間還可能有依賴(lài)，產(chǎn)生阻塞。以此情況下，一個(gè)頁(yè)面多出幾秒鐘是非常正常的現(xiàn)象，且該耗時(shí)僅僅為網(wǎng)絡(luò)耗時(shí)；而由于協(xié)議的規(guī)定，它必須要進(jìn)行網(wǎng)絡(luò)交互，還包括很多其他的耗時(shí)，比如說(shuō)計(jì)算耗時(shí)，證書(shū)校驗(yàn)、密鑰計(jì)算、內(nèi)容對(duì)稱(chēng)的加解密等計(jì)算，由于移動(dòng)端性能相對(duì)要弱，所以在這計(jì)算層面多出幾百毫秒也是非常正常的現(xiàn)象。
經(jīng)過(guò)以上分析，我們可以得出一個(gè)基本結(jié)論，就是未經(jīng)優(yōu)化的 HTTPS 要比 HTTP 慢很多，那么 HTTPS 是不是就是 slow，就是慢的意思呢？
為了找到慢的原因或者說(shuō)找到性能的瓶頸，以上我們僅僅從網(wǎng)絡(luò)協(xié)議理論進(jìn)行分析，而事實(shí)上，在實(shí)驗(yàn)環(huán)境下、業(yè)務(wù)真實(shí)環(huán)境下、用戶場(chǎng)景下面，它是不是還是這么慢，又慢在哪里呢？
為此，我們進(jìn)行了兩個(gè)層面的分析。
線下模擬測(cè)試
第一個(gè)就是線下模擬測(cè)試。線下模擬測(cè)試主要針對(duì)移動(dòng)端，因?yàn)橐苿?dòng)端手機(jī)性能是流量越來(lái)越多的、都是往移動(dòng)端傾斜。移動(dòng)端有兩個(gè)特點(diǎn)，第一，手機(jī)屏幕比較小，查看數(shù)據(jù)或者查看頁(yè)面性能，調(diào)試日志也不太方便；第二，不太方便運(yùn)行數(shù)據(jù)的分析腳本、控制腳本。所以我們將手機(jī)和 PC 使用 USB 連接起來(lái)，通過(guò)遠(yuǎn)程調(diào)試協(xié)議來(lái)控制手機(jī)上的瀏覽器來(lái)不斷的重復(fù)訪問(wèn)我們所構(gòu)造的不同的頁(yè)面。該頁(yè)面所涉及的元素一定是非常多的，不同的類(lèi)型也都有。
因此我們進(jìn)行線下模擬測(cè)試一定要自動(dòng)化，靠人為實(shí)現(xiàn)是沒(méi)有效率的，并且也測(cè)試不了那么多的頁(yè)面和場(chǎng)景。而且要注意數(shù)據(jù)的同比、環(huán)比，如果沒(méi)有，即使測(cè)試拿到了一百條數(shù)據(jù)，一千條數(shù)據(jù)也是不能說(shuō)明問(wèn)題的，因?yàn)閿?shù)據(jù)誤差尤其多，周期性的同比、環(huán)比要求數(shù)據(jù)超過(guò)一萬(wàn)條才認(rèn)為它可能有一定的說(shuō)明意義。
另外一個(gè)大誤差是 WIFI。即使是在洲際酒店、騰訊大廈，或者朗科大廈，使用的 wifi 還是經(jīng)常出現(xiàn)網(wǎng)絡(luò)抖動(dòng)的情況，這對(duì)數(shù)據(jù)、對(duì)協(xié)議的分析有巨大影響，因?yàn)閰f(xié)議很可能僅僅就是那么一個(gè) IT，那么幾百毫秒的差異，在抖動(dòng)的網(wǎng)絡(luò)環(huán)境下很容易出現(xiàn)問(wèn)題干擾結(jié)論。所以為了排除這些誤差，我們也經(jīng)常將手機(jī)和 PC 用 USB 連接起來(lái)，繞開(kāi) wifi 直接使用有線網(wǎng)絡(luò)，因?yàn)橛芯€相比無(wú)線，特別是 wifi，要穩(wěn)定非常多。
關(guān)于工具的話就是 traffic control，因?yàn)槲覀冋鎸?shí)用戶的網(wǎng)絡(luò)環(huán)境是千差萬(wàn)別的。不同 IP，不同的帶寬，不同的丟包率，因此我們采用該工具來(lái)模擬在實(shí)驗(yàn)室里模擬環(huán)境。線下模擬數(shù)據(jù)，顯然不能代表我們真實(shí)業(yè)務(wù)的性能。
線上業(yè)務(wù)速度數(shù)據(jù)采集
第二個(gè)部分是線上分析數(shù)據(jù)。
Web 加速，協(xié)議先行！
在服務(wù)端進(jìn)行數(shù)據(jù)采集的方案有兩個(gè)優(yōu)勢(shì)。
第一點(diǎn)它能采集到客戶端采集不到的數(shù)據(jù)，采集到更低層信息和業(yè)務(wù)信息。如上圖，左邊是客戶端，即可用手機(jī)、STW 或者是負(fù)載均衡器，右邊是業(yè)務(wù)服務(wù)器。關(guān)于業(yè)務(wù)信息，通過(guò) LB 和業(yè)務(wù)服務(wù)器的交互可以獲得業(yè)務(wù)整體處理時(shí)間，這是客戶端拿不到的。第二點(diǎn)關(guān)于協(xié)議信息，包括 TCP 的 RTT、TCP 是否連接復(fù)用、是否 TLS SESSION 復(fù)用、 TLS 協(xié)議版本，密碼套件、握手時(shí)間以及非對(duì)稱(chēng)密鑰交換計(jì)算時(shí)間，HTTP2 頭部壓縮比等，這些都是客戶拿不到的信息。
有些信息客戶端能采集到，但客戶端的開(kāi)發(fā)成本很高，因?yàn)榘沧坑胁煌陌姹荆热缬?IOS、有 windows，需要針對(duì)不同操作系統(tǒng)進(jìn)行開(kāi)發(fā)，而在服務(wù)端只需要一次開(kāi)發(fā)即可，將數(shù)據(jù)放到 COOKIE 里返回給客戶端，客戶端通過(guò) JS 或者普通頁(yè)面就能獲取到信息，拿到信息之后，將協(xié)議相關(guān)的信息組合起來(lái)放到一條數(shù)據(jù)內(nèi)統(tǒng)一上報(bào)到數(shù)據(jù)平臺(tái)進(jìn)行分析。
那么拿出這么多數(shù)據(jù)，我們數(shù)據(jù)平臺(tái)如何去分析呢？
多維數(shù)據(jù)分析
Web 加速，協(xié)議先行！
如上圖，由于數(shù)據(jù)龐大，僅截取幾條進(jìn)行分析。左邊是數(shù)據(jù)維度，比如 TCP-reuse 表示 TCP 連接復(fù)用，TLS1.2 表示 TLS 協(xié)議版本是 1.2；右邊是與用戶性能相關(guān)的監(jiān)控指標(biāo)，比如說(shuō)開(kāi)始加載時(shí)間，頁(yè)面可活動(dòng)時(shí)間，業(yè)務(wù)處理時(shí)間等維度，這些維度也可互相組合并得出三四百個(gè)維度。如上圖所示，騰訊 X 五內(nèi)核瀏覽器在 4G 網(wǎng)絡(luò)下使用 HTTP2 并且是使用 TLS1.2 協(xié)議并且使用 ECDHE 并且沒(méi)有復(fù)用 TLS Session 的首屏?xí)r間是多少？通過(guò)多維度對(duì)比，我們很容易就可以區(qū)別出它慢的因素， X5 在 4G 是這么多，那么在 3G 下面是多少，wifi 下面是多少呢？通過(guò)多維度綜合的對(duì)比就能從表面看出瓶頸在哪里。
因此多維度數(shù)據(jù)分析，最終目的就是為了找到性能瓶頸以及速度優(yōu)化方向，那么有哪些優(yōu)化方向呢？
WEB 訪問(wèn)速度優(yōu)化方向
優(yōu)化方向有三個(gè)。第一個(gè)協(xié)議；第二個(gè)資源；第三個(gè)用戶行為。
協(xié)議
TCP 速度優(yōu)化
Web 加速，協(xié)議先行！
那么協(xié)議層面如何進(jìn)行優(yōu)化呢？協(xié)議的最底層是 TCP，而 TCP 最顯而易見(jiàn)的性能問(wèn)題是需要三次握手才能建立一個(gè) TCP 連接，然后發(fā)送應(yīng)用層數(shù)據(jù)，與普通握手相比，浪費(fèi)一個(gè) RTT。如上圖左邊是普通握手。每個(gè) TCP 的連接需要建立握手，并且發(fā)送 SYN 包沒(méi)有任何運(yùn)動(dòng)組數(shù)據(jù)，RTT 就浪費(fèi)了。
TFO 是 TCP FAST OPEN。在 SYN 包發(fā)出的同時(shí)將應(yīng)用層數(shù)據(jù)發(fā)出來(lái)，然而它的前提是第一次建立握手、建立連接的時(shí)候也需要發(fā) SYN 包，不同的是，服務(wù)器返回 SYN+ACK 時(shí)會(huì)返回一個(gè) COOKIE，在這之后用戶發(fā)起 TCP 連接，發(fā)出 SYN 包的同時(shí)會(huì)帶上這個(gè) COOKIE，然后可以直接帶上 HTTP 數(shù)據(jù)。換句話說(shuō)，在 SYN 包發(fā)出的同時(shí)將應(yīng)用層數(shù)據(jù)一起發(fā)出來(lái)，減少了一個(gè) RTT 對(duì)性能的影響。TCP FAST OPEN 性能是一個(gè)收益數(shù)據(jù)，我們發(fā)現(xiàn) 80 分的數(shù)據(jù)提升了將近一百毫秒。然而它的缺點(diǎn)是需要操作系統(tǒng)的支持，需要 IOS9+ 或者 linux kervel3.7+，并且不支持 Windows 系統(tǒng)。另一個(gè)優(yōu)化方案是擁塞控制，將三個(gè)擁塞窗口增加到十個(gè)。
總的來(lái)說(shuō)，在 TCP 協(xié)議層面來(lái)提升速度優(yōu)化的空間有限，因?yàn)閮?yōu)化成本非常高，而高在哪里呢？它需要操作系統(tǒng)、需要內(nèi)核的支持，如果僅僅是服務(wù)端升級(jí)，我們支持與研發(fā)，其成本還能夠控制，但是最重要的是需要用戶的操作系統(tǒng)升級(jí)，需要廣大網(wǎng)絡(luò)設(shè)備上的軟協(xié)議棧或者操作系統(tǒng)升級(jí)，而在這個(gè)層面部署的壓力非常大。所以 TCP 層面優(yōu)化成本非常高。
TLS 速度優(yōu)化 -session reuse
TLS 是加密層，加密層最大的問(wèn)題是完全握手。關(guān)于完全握手，接觸過(guò)的同學(xué)應(yīng)該很清楚它的 session ID，它的過(guò)程我就不做介紹了。
Web 加速，協(xié)議先行！
在這里，我主要分享兩點(diǎn)。如上圖。第一點(diǎn)，關(guān)于 IOS Qzone 優(yōu)化，通過(guò) session id 握手時(shí)間大概能夠提升 50%；第二點(diǎn)，session ticket 的機(jī)制雖然更加先進(jìn)，因?yàn)樗恍枰?wù)端提供緩存去提供內(nèi)存存儲(chǔ)，發(fā)送 ticket，服務(wù)端進(jìn)行校驗(yàn)即可。而 session ID 需要提供內(nèi)存進(jìn)行存儲(chǔ)，然后查找到 session cache 是否命中，由于 IOS 不支持 session ticket，所以大家一定要注意通過(guò)分布式 session cache 來(lái)提升 IOS 的 session ID 的緩存命中率。很多場(chǎng)景是沒(méi)有辦法實(shí)現(xiàn)簡(jiǎn)化握手的，比如說(shuō)用戶第一次打開(kāi) APP、打開(kāi)瀏覽器，又比如說(shuō)用戶退出了再重新重啟瀏覽器，或者說(shuō)把瀏覽器頁(yè)面關(guān)閉掉，再打開(kāi)，都可能會(huì)導(dǎo)致 session cache 簡(jiǎn)化握手無(wú)法實(shí)現(xiàn)，因?yàn)?session ticket 都是基于內(nèi)存的，而不是存儲(chǔ)在硬盤(pán)里面。
TLS 速度優(yōu)化——False Start
Web 加速，協(xié)議先行！
針對(duì)完全握手的優(yōu)化方法是 false start，即搶跑。與 TFO 思路類(lèi)似，如上圖左邊是普通握手，必須要進(jìn)行 TLS 的兩個(gè) RTT 四次握手才能建立連接，發(fā)送應(yīng)用層數(shù)據(jù)。false start 是在 clientKeyExchange 沒(méi)有交換的時(shí)候，即在完全握手的第二個(gè)階段將應(yīng)用層數(shù)據(jù)一起發(fā)出來(lái)，提升了一個(gè) RTT。那怎么啟用 false start 呢？其實(shí)現(xiàn)在客戶端基本都已經(jīng)支持了，如果服務(wù)端要啟用需要注意將支持 PFS（完美前向密碼）加密的算法配置在前，比如說(shuō) ECDHE、DHE 算法配置在前即可，并且其握手時(shí)間將提升 30%。
TLS 速度優(yōu)化——OCSP Stapling
OCSP Stapling。剛才提到的一些場(chǎng)景就是主動(dòng)撤銷(xiāo)證書(shū)，所以一定要進(jìn)行證書(shū)狀態(tài)的檢查，因?yàn)樵谀承┣闆r下，單純地進(jìn)行校驗(yàn)證書(shū)的簽名、校驗(yàn)證書(shū)的時(shí)間是發(fā)現(xiàn)不了證書(shū)的狀態(tài)，它需要更加實(shí)時(shí)的檢查。我們證書(shū)頒布 3 年，學(xué)校中間可能出問(wèn)題，所以他會(huì)進(jìn)行周期性的檢查。
Web 加速，協(xié)議先行！
他普通的過(guò)程與之類(lèi)似， client hello 獲取到證書(shū)時(shí)，③④⑤這過(guò)程中增加的 3 個(gè) RTT 需要去 CA 站點(diǎn)請(qǐng)求 OCSP 的狀態(tài)和內(nèi)容。如上圖，右邊是 OCSP Stapling，它的過(guò)程相當(dāng)于服務(wù)器代理實(shí)現(xiàn)了 CA 的證書(shū)狀態(tài)頒發(fā)的功能, 它提前向 CA 站點(diǎn)請(qǐng)求 OCSP 內(nèi)容，并保存在本地服務(wù)器端，然后在握手的同時(shí)，將像簽名的內(nèi)容返回給客戶端，然后客戶端對(duì)該內(nèi)容進(jìn)行校驗(yàn)。它不需要直接和 CA 站點(diǎn)進(jìn)行交互，因此這樣看來(lái) OCSP Stapling 減少了三個(gè) RTT，效果應(yīng)該非常明顯。
但是，事實(shí)上不是這樣的，為什么？因?yàn)榭蛻舳藭?huì)對(duì) OCSP 進(jìn)行緩存，沒(méi)請(qǐng)求一次就可能可以緩存七天，也就是在這七天時(shí)期，如果用戶訪問(wèn)該網(wǎng)站次數(shù)非常多，可能成千上萬(wàn)次，因?yàn)橐粋€(gè)頁(yè)面有非常多的請(qǐng)求，所以可能只有 1‰的概率來(lái)增加這三個(gè) RTT。大家需要注意的，并不是一定就有這個(gè)效果。
TLS 速度優(yōu)化——dynamic record size
Web 加速，協(xié)議先行！
現(xiàn)在來(lái)分析一下 dynamic record size，即記錄塊大小的動(dòng)態(tài)的調(diào)整。
先簡(jiǎn)單講解一下 TLS 協(xié)議層面的隊(duì)頭阻塞，即 head of line blocking 問(wèn)題產(chǎn)生的背景，因?yàn)?TLS 協(xié)議傳輸?shù)淖罨締挝皇?record，一個(gè)記錄塊最大不能超過(guò) 16K，而一些服務(wù)端的實(shí)現(xiàn)，比如說(shuō) Nginx 最早期版本默認(rèn)大小 16K。那么 16K 會(huì)產(chǎn)生什么情況呢？如果你中間丟了一個(gè)字節(jié)，或者說(shuō)由于 TCP 的籌碼丟了一個(gè) segment，將導(dǎo)致這 16K 沒(méi)有辦法被校驗(yàn)，就算接收到 15.99K 的數(shù)據(jù)，也沒(méi)有辦法處理，因?yàn)橐粋€(gè)數(shù)據(jù)的丟失、一個(gè)包的丟失，導(dǎo)致整個(gè) record 沒(méi)有辦法被處理。
那怎么解決呢？方法有兩個(gè)。
第一個(gè)就是適當(dāng)?shù)恼{(diào)小 buffer，比如說(shuō)改成 4K，不用實(shí)名制，即使丟失了也只影響這 4k 數(shù)據(jù)，而不是 16K 數(shù)據(jù)。
第二個(gè)，借鑒 TCP 的 slow start 原理。cloud flare 提供一個(gè) patch，在 TLS 連接剛剛建立的時(shí)候，由于不知道網(wǎng)絡(luò)狀況以及擁塞情況，將 record 設(shè)置縮小，比如變成 1K, 在發(fā)送速度提升之后，再將 record size 設(shè)置為 16K。它大概是這么個(gè)思路，也有開(kāi)源代碼，大家有興趣的話可以了解一下。
剛才提到這些優(yōu)化策略都是針對(duì) TLS1.2 以及之前的版本。接下去介紹 TLS1.3 版本，這是一個(gè)革命性的、非常創(chuàng)新的、具有里程碑意義的協(xié)議。
TLS1.3 速度優(yōu)化
TLS1.3 速度優(yōu)化——ORTT Handshake
在性能方面的創(chuàng)新點(diǎn)是它能實(shí)現(xiàn) 1RTT 的完全握手，以及實(shí)現(xiàn) 0RTT 的簡(jiǎn)化握手。也就是說(shuō)，TLS 連接層面沒(méi)有握手原則不會(huì)增加 RTT 的延時(shí)。TLS1.3 現(xiàn)在仍處于草稿階段，這里介紹它，是因?yàn)槿绻蠹蚁雵L鮮已經(jīng)可以使用了，因?yàn)?OpenSSL1.1.1，Nginx1.13.0 已經(jīng)分別支持 TLS1.3 的最新的草稿 draft20。而且 TLS1.3 上的最新的討論，可能將于今年秋季正式發(fā)布。如果客戶端是自己可以控制的，那可以嘗試，包括 Firefox 也支持 TLS1.3。當(dāng)然這些都是草稿版本，所以這里給大家介紹一下，具體的過(guò)程其實(shí)也比較復(fù)雜，我這里就不做詳細(xì)介紹了。
HTTPS 速度優(yōu)化
HTTPS 速度優(yōu)化——HSTS 減少 302 跳轉(zhuǎn)
HSTS 其實(shí)是 HTTP 的頭部，它的作用是服務(wù)端告訴客戶端，你以后訪問(wèn)我的網(wǎng)站，在指定的時(shí)間內(nèi)，你必須使用 HTTPS，你不要使用 HTTP。然而他存在一個(gè)問(wèn)題是 HSTS 是通過(guò) HTTP 返回的，很有可能被中間者所劫持。也就是說(shuō)，客戶端可能永遠(yuǎn)不知道服務(wù)端曾經(jīng)發(fā)送 HSTS，也就沒(méi)有辦法使用 https。這樣的話，有一個(gè)薄弱的預(yù)加載名單機(jī)制，比如說(shuō) chrome 瀏覽器將把你的網(wǎng)站內(nèi)置在白名單里，當(dāng)你發(fā)出訪問(wèn)請(qǐng)求時(shí)，它會(huì)默認(rèn)使用 HTTPS；客戶端同理。
HTTPS 速度優(yōu)化——SPDY&&HTTP2
SPDY 和 HTTP2。為什么會(huì)提到 SPDY？主要有兩點(diǎn)。
第一點(diǎn)，因?yàn)楝F(xiàn)在 HTTP2 很流行，并且正式發(fā)布了，但是它的所有特性和最主要特性都是沿用于 SPDY，除了頭部壓縮算法，所以我最開(kāi)始研究的也是 SPDY 的協(xié)議，而且現(xiàn)在可能很多人只知道 HTTP2 而不知道 SPDY。所以也是為了向該協(xié)議致敬，因?yàn)樗潜亲妗?
第二點(diǎn)，大多數(shù)老客戶端只支持 SPDY，比如說(shuō)安卓 4.4 以前版本，以及 IOS 現(xiàn)在還支持 SPDY，為了兼容老版本，提升他們性能同時(shí)支持 SPDY 和 HTTP2。
它有三個(gè)特性。
第一個(gè)，多路復(fù)用。在單個(gè)鏈接上同時(shí)發(fā)送多個(gè)請(qǐng)求，并且請(qǐng)求和請(qǐng)求之間在協(xié)議層面可以不依賴(lài)也可以依賴(lài)。比如說(shuō)第二個(gè)請(qǐng)求先處理完了可以提前返回，相比較 HTTP1.1，它也做過(guò) pipelining 的努力，它允許客戶端同時(shí)發(fā)出多個(gè)請(qǐng)求，但是服務(wù)器必須按照嚴(yán)格順序返回，否則就會(huì)亂套。它不知道哪個(gè)請(qǐng)求和哪個(gè)響應(yīng)對(duì)應(yīng)的。這樣會(huì)導(dǎo)致即使第三個(gè)請(qǐng)求先處理完了也不能提前返回；或者說(shuō)四個(gè)請(qǐng)求都處理完，但是第三個(gè)請(qǐng)求丟了，那整個(gè)順序也就出問(wèn)題了。HTTP2 最強(qiáng)大的特性就是多路復(fù)用，它能將一百個(gè)請(qǐng)求甚至設(shè)置一百多個(gè)請(qǐng)求在一起發(fā)出去。
關(guān)于 SPDY 和 HTTP2，大家可能容易忽略的兩點(diǎn)。第一點(diǎn)頭部壓縮，壓縮的數(shù)據(jù)、宣傳的頁(yè)面大概會(huì)有 89% 或者 90% 的壓縮比，但事實(shí)上是這樣的嗎？通過(guò)測(cè)試發(fā)現(xiàn)在一個(gè) TCP 連接發(fā)送第一個(gè)請(qǐng)求的時(shí)候，當(dāng)時(shí)的 HTTP2 壓縮比只有 30%，發(fā)生第二個(gè)請(qǐng)求的時(shí)候壓縮比能達(dá)到 60%，發(fā)生第三個(gè)請(qǐng)求以及之后才可能達(dá)到 90%，因?yàn)?SPDY 使用的是基于 zlib 壓縮算法，而 HTTP2 使用的是基于 Hpack 壓縮算法，他們都是基于狀態(tài)空間進(jìn)行壓縮，因此如果信息越冗余、越重復(fù)，當(dāng)你在這個(gè)連接上重復(fù)性閱讀，壓縮比才會(huì)越高。所以第一個(gè)請(qǐng)求發(fā)生時(shí)，頭部沒(méi)有那么冗余，壓縮比可能就只有 30%。
這給我們性能優(yōu)化方面的一個(gè)啟發(fā)就是如果一個(gè)頁(yè)面要放到下一個(gè)頁(yè)面，我們可以提前給頁(yè)面或者域名的連接發(fā)送兩個(gè)空請(qǐng)求，積累數(shù)據(jù)。當(dāng)真實(shí)的用戶請(qǐng)求發(fā)起的時(shí)候已經(jīng)達(dá)到了第三個(gè)合作之后了，以至于用戶的頭部壓縮比就能達(dá)到 90%。
第二個(gè)是 server push。由于 Nginx 不支持 server push，所以現(xiàn)在這個(gè)應(yīng)用在國(guó)內(nèi)用得還很少，但它作用確實(shí)很大。比如說(shuō)客戶端請(qǐng)求一個(gè) html， html 里面含有 css 和圖片，按照正常來(lái)講，解析 html 之后要分別發(fā)出 CSS 的請(qǐng)求和圖片的請(qǐng)求，但是如果服務(wù)端得知頁(yè)面支持 server push，客戶端便只需要發(fā)出 http 請(qǐng)求，而服務(wù)器直接將 css 和圖片一起發(fā)出去，以致請(qǐng)求多個(gè)響應(yīng)未發(fā)先至。這就是 server push 的作用，和 inlining 有點(diǎn)類(lèi)似，但是相比 inlining 有兩個(gè)好處，inlining 會(huì)影響緩存，會(huì)增大 html 的體積，包括后臺(tái)模板的維護(hù)，這也便增加開(kāi)發(fā)和維護(hù)成本，對(duì)于客戶而言?xún)H僅是多個(gè)請(qǐng)求。
HTTP2 實(shí)踐建議
關(guān)于 HTTP2P 的實(shí)踐建議以及原理性的知識(shí)，在網(wǎng)上資料已經(jīng)非常多了，所以我主要是告訴大家一些我們自己在實(shí)踐中遇到的一些經(jīng)驗(yàn)和心得。
第一，使用一個(gè)連接或者說(shuō)使用更少的鏈接。不用使用很多連接，為什么？第一，連接少，握手成本就少。第二，壓縮比高，因?yàn)橐粋€(gè)連接上積累的信息很多，壓縮比會(huì)更高。第三，更好地利用 TCP 的特性，為什么？因?yàn)?TCP 的擁塞控制流量控制都是基于單個(gè)連接的，如果使用很多個(gè)連接，特別是在網(wǎng)絡(luò)擁塞的情況下，會(huì)放大擁塞的系數(shù)，加劇網(wǎng)絡(luò)擁塞，如果使用一個(gè)連接，當(dāng)?shù)弥摯翱谝呀?jīng)擁塞，響應(yīng)很慢便不會(huì)繼續(xù)發(fā)送了，但是多個(gè)連接的情況，可能大家都會(huì)嘗試發(fā)一下，而導(dǎo)致加劇網(wǎng)絡(luò)擁塞。
第二，使用更少的域名，這也是為了更好地使用連接，并且減少了 DNS 解析時(shí)間。
第三，如果一定要使用很多域名，那就盡量將多個(gè)域名解析到相同的 ip，使用相同的證書(shū)。因?yàn)榭蛻舳藢?shí)現(xiàn)的角度標(biāo)準(zhǔn)就是如果多個(gè)域名能夠復(fù)用相同的 ip 和相同的證書(shū)，那我就會(huì)復(fù)用這個(gè)連接，我不會(huì)新建連接。比如 chrome 瀏覽器；靈活運(yùn)用 server push，代替 inlining；關(guān)于 TLS1.2, 若其默認(rèn)使用 TLS1.2 之前的版本，HTPP2 便沒(méi)有辦法使用。TLS1.2 并不是支持所有的密碼套件，它有很多密碼套件屬于黑名單，這也是在 HTPP2 現(xiàn)在的使用率比較低的一個(gè)原因；HTPP2 并不能解決所有問(wèn)題，它適用于多元素、多連接的場(chǎng)景，如果你的頁(yè)面本身很簡(jiǎn)單，只有幾個(gè)請(qǐng)求，就用普通 TLS 也沒(méi)問(wèn)題，它并不能提升該場(chǎng)景下的訪問(wèn)性能。但是總的來(lái)說(shuō)肯定還是推薦大家使用。
用戶行為
預(yù)建連接
預(yù)建連接是一個(gè)最簡(jiǎn)單、最有效的速度優(yōu)化的方案，為什么？預(yù)建連接的思路是在用戶發(fā)起真正的連接之前，提前建立好連接。這樣的話，對(duì)于用戶而言，由連接所導(dǎo)致的成本和延時(shí)是感覺(jué)不到的。之前的一系列優(yōu)化方案，即使是 0 RTT 握手，也存在一些計(jì)算，比如 ticket 的校驗(yàn)。
那怎么樣來(lái)預(yù)建連接呢？共有兩點(diǎn)方法。
第一點(diǎn)通過(guò) link 頭部標(biāo)簽，比如說(shuō)連接告訴瀏覽器，即服務(wù)端，可以返回；或者告訴瀏覽器，頁(yè)面可能需要訪問(wèn)下一個(gè)頁(yè)面，那提前跟我建立好預(yù)連接。這是支持 link 頭部的瀏覽器可以實(shí)現(xiàn)的。如果不支持該特性，那怎么辦呢？
第二點(diǎn)通過(guò)控制頁(yè)面 JS。比如說(shuō)，后臺(tái)頁(yè)面上有個(gè) JS，對(duì)于即將訪問(wèn)的頁(yè)面，可以提前與它建立好連接。當(dāng)用戶發(fā)起請(qǐng)求時(shí)，JS 已經(jīng)提前給它預(yù)建連接了。還有很多場(chǎng)景，第一個(gè)是首頁(yè)可以提前預(yù)建子頁(yè)面連接，比如說(shuō)百度首頁(yè)，百度首頁(yè)很簡(jiǎn)單，它的搜索結(jié)果千差萬(wàn)別，但是搜索結(jié)果的網(wǎng)站也可以固定好 AA.com，這樣便于建立連接；第二個(gè) QQ 空間，有的用戶打開(kāi) QQ 空間可能會(huì)相冊(cè)，有些用戶會(huì)經(jīng)常訪問(wèn)商城掛件、商城訪問(wèn)禮物，那我們就可以根據(jù)用戶經(jīng)常訪問(wèn)的頁(yè)面給它提前建立好不同的直接預(yù)連接，預(yù)建好的連接也有可能會(huì)超時(shí)斷開(kāi)。
那么如何避免呢？可以使用長(zhǎng)連接保持。比如說(shuō)瀏覽器 HTTP2 超過(guò)三分鐘就會(huì)斷掉，HTTP 超過(guò)五分鐘就會(huì)斷掉，為了維持住長(zhǎng)連接，我們可以使用 JS 周期性給這些頁(yè)面發(fā)起長(zhǎng)連接保持的請(qǐng)求，這樣的話，連接相當(dāng)于一直會(huì)保持住用戶在訪問(wèn)時(shí)候建立好的狀態(tài)，這便是預(yù)建連接的一個(gè)好處。
Web 加速，協(xié)議先行！
關(guān)于 HTTPS 速度的一個(gè)基本結(jié)論是 HTTPS 的訪問(wèn)速度可以超越 HTTP1.1。其最關(guān)鍵、最核心的一點(diǎn)是 HTTPS 可以使用多路復(fù)用，而 HTTP1.1 不行。關(guān)于優(yōu)化手段節(jié)點(diǎn)，如上圖，這是兩年前的數(shù)據(jù)，它們的優(yōu)化策略是一樣的，包括 HTTP2、SPDY 都沒(méi)有本質(zhì)區(qū)別。
HTTP2 是未來(lái)嗎？
Web 加速，協(xié)議先行！
之前提到 HTTP2 的一些強(qiáng)特性，對(duì)我們非常有幫助。如今 HTTP2 被認(rèn)為是互聯(lián)網(wǎng)下一代協(xié)議，但是它真的是我們未來(lái)嗎？或者說(shuō)，HTTP2 是下一個(gè)十年最具有性能權(quán)威、最具有統(tǒng)治力的一個(gè)協(xié)議嗎？回答是肯定的。是。因?yàn)樗暮芏嗵匦?，比如多路?fù)用、頭部壓縮、server push、優(yōu)先級(jí)等，設(shè)計(jì)非常先進(jìn)，性能也及其優(yōu)良，解決了很多性能問(wèn)題。
但回答也可以說(shuō)不是。為什么？因?yàn)楝F(xiàn)在的 HTTP2 是基于 TCP 協(xié)議和 TLS 協(xié)議而構(gòu)建，存在著些問(wèn)題。
首先 TCP 協(xié)議 3 次握手。雖然它可以支持 TFO，但是 TFO 需要操作系統(tǒng)支持。并且 TFO 第一次建立連接獲取 COOKIE 時(shí)還需要一次額外的 RTT 才能實(shí)現(xiàn)握手。此外 TLS1.3 支持 0RTT 握手，但 TLS 對(duì) TCP 頭部沒(méi)有進(jìn)行驗(yàn)證，可能存在被篡改的風(fēng)險(xiǎn)，比如修改窗口數(shù)、修改序列號(hào)等，都存在被劫持的可能。
而最大的問(wèn)題是 TCP 的隊(duì)頭阻塞，比如說(shuō)當(dāng)我們傳輸 segment 時(shí)，如果第二個(gè) segment 丟了，那便傳輸失敗，為了保證它的可靠性和有序性，需要等到第二個(gè) segment 到達(dá)才能往上傳給應(yīng)用層，而糟糕的是，由于 HTTP2 多路復(fù)用的特性，如果將假設(shè)的 50 個(gè)請(qǐng)求在一個(gè) TCP 平臺(tái)上發(fā)送，它會(huì)加劇隊(duì)頭阻塞的問(wèn)題。關(guān)于 TCP 的重傳，重傳的序列號(hào)和最原始的序列號(hào)是相同一個(gè)序列號(hào)，這會(huì)導(dǎo)致重傳的模糊性問(wèn)題。關(guān)于擁塞控制，需要操作系統(tǒng)升級(jí)，但是 TCP 的升級(jí)成本高，需要用戶、網(wǎng)絡(luò)設(shè)備中間商去升級(jí)來(lái)支持。
所以從協(xié)議層面來(lái)講，HTTP2 不是下一個(gè)十年最具有統(tǒng)治力或者最有心的、有權(quán)威的一個(gè)協(xié)議，那什么才是非常具有競(jìng)爭(zhēng)力的一個(gè)協(xié)議呢？它就是 QUIC 協(xié)議，即使用 UDP 實(shí)現(xiàn) HTTP2。以下是它的特性。
擁抱 QUIC 協(xié)議
Web 加速，協(xié)議先行！
它支持 HTTP2 的所有特性，比如多路復(fù)用、隊(duì)頭阻塞、頭部壓縮、server push；支持使用 TLS 1.3 的 0RTT 握手；使用 UDP 傳輸使用；基于 packet 加密，對(duì) packet 頭部進(jìn)行一致性的驗(yàn)證，一旦發(fā)生修改即可發(fā)現(xiàn)。
以上我所提及到的協(xié)議優(yōu)化，騰訊云也都進(jìn)行了很好的支持。另外，我們騰訊云 CLB 也正式支持了 QUIC 協(xié)議，平均性能提升了 15%以上，歡迎大家試用。
作者介紹
Web 加速，協(xié)議先行！
羅成，2011 年畢業(yè)于浙江大學(xué)，2011 年至 2015 年任職于百度運(yùn)維部，主要負(fù)責(zé)文件分發(fā)、統(tǒng)一接入、安全搜索等事項(xiàng)，2015 年開(kāi)始任職于騰訊，騰訊 TEG 基礎(chǔ)架構(gòu)部，高級(jí)工程師，目前主要負(fù)責(zé)騰訊 STGW（騰訊安全云網(wǎng)關(guān)）的相關(guān)工作。對(duì) HTTPS，SPDY，HTTP2，QUIC 等應(yīng)用層協(xié)議、高性能服務(wù)器技術(shù)、云網(wǎng)絡(luò)技術(shù)、用戶訪問(wèn)速度、分布式文件傳輸?shù)扔休^深的理解。
福德麟管理咨詢(xún)福德麟管理咨詢(xún)http://www.qdfoodlin.com
咨詢(xún)電話
15050695302
13771112364
咨詢(xún)QQ
1309844028