建站
咨詢
售后
建站咨詢
新聞中心
無(wú)論你在做前端、后端還是運(yùn)維，HTTP都是不得不打交道的網(wǎng)絡(luò)協(xié)議。它是最常用的應(yīng)用層協(xié)議，對(duì)它的優(yōu)化，既能通過(guò)降低時(shí)延帶來(lái)更好的體驗(yàn)性，也能通過(guò)降低資源消耗帶來(lái)更高的并發(fā)性。
10年積累的網(wǎng)站制作、網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有下陸免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
可是，學(xué)習(xí)HTTP不久的同學(xué)，很難全面說(shuō)出HTTP的所有優(yōu)化點(diǎn)。這既有可能是你沒(méi)好好準(zhǔn)備過(guò)大廠的面試，也有可能你沒(méi)有加入一個(gè)快速發(fā)展的項(xiàng)目，當(dāng)產(chǎn)品的用戶量不斷翻番時(shí)，需求會(huì)倒逼著你優(yōu)化HTTP協(xié)議。
這篇文章是根據(jù)我在2019年GOPS全球運(yùn)維大會(huì)上海站的演講PPT，重新提煉文字后的總結(jié)。我希望能從四個(gè)全新的維度，帶你覆蓋絕大部分的HTTP優(yōu)化技巧。這樣，即使還不需要極致方法去解決當(dāng)前的性能瓶頸，也會(huì)知道優(yōu)化方向在哪，當(dāng)需求來(lái)臨時(shí)，能夠到Google上定向查閱資料。
第一個(gè)維度，是從編碼效率上，更快速地把消息轉(zhuǎn)換成更短的字符流。這是最直接的性能優(yōu)化點(diǎn)。
一、編碼效率優(yōu)化
如果你對(duì)HTTP/1.1協(xié)議做過(guò)抓包分析，就會(huì)發(fā)現(xiàn)它是用“whitespace-delimited”方式編碼的。用空格、回車來(lái)編碼，是因?yàn)镠TTP在誕生之初追求可讀性，這樣更有利于它的推廣。
然而在當(dāng)下，這種低效的編碼方式已經(jīng)嚴(yán)重影響性能了，所以2009年Google推出了基于二進(jìn)制的SPDY協(xié)議，大幅提升了編碼效率。2015年，稍做改進(jìn)后它被確定為HTTP/2協(xié)議，現(xiàn)在50%以上的站點(diǎn)都在使用它。
這是編碼優(yōu)化的大方向，包括即將推出的HTTP/3。
然而這些新技術(shù)到底是怎樣提升性能的呢？那還得拆開(kāi)了看，先從數(shù)據(jù)的壓縮談起。你抓包看到的是數(shù)據(jù)，它并不等于信息。數(shù)據(jù)其實(shí)是信息和冗余數(shù)據(jù)之和，而壓縮技術(shù)，就是盡量地去除冗余數(shù)據(jù)。
壓縮分為無(wú)損壓縮和有損壓縮。針對(duì)圖片、音視頻，我們每天都在與有損壓縮打交道。比如，當(dāng)瀏覽器只需要縮略圖時(shí)，就沒(méi)有必要浪費(fèi)帶寬傳輸高清圖片。而高清視頻做過(guò)有損壓縮后，在肉眼無(wú)法分清時(shí)，已經(jīng)被壓縮了上千倍。
這是因?yàn)?，聲音、視頻都可以做增量壓縮。還記得曾經(jīng)的VCD嗎？當(dāng)光盤有劃痕時(shí)，整張盤都無(wú)法播放，就是因?yàn)槟菚r(shí)的視頻做了增量壓縮，而且關(guān)鍵幀太少，導(dǎo)致關(guān)鍵幀損壞時(shí)，后面的增量幀全部無(wú)法播放了。
再來(lái)看無(wú)損壓縮，你肯定用過(guò)gzip，它讓http body實(shí)現(xiàn)了無(wú)損壓縮。肉眼閱讀壓縮后的報(bào)文全是亂碼，但接收端解壓后，可以看到發(fā)送端的原文。然而，gzip的效率其實(shí)并不高，以Google推出的brotli做對(duì)比，你就知道它的缺陷了：
評(píng)價(jià)壓縮算法時(shí)，我們重點(diǎn)看兩個(gè)指標(biāo)：壓縮率和壓縮速度。上圖中可以看到，無(wú)論用gzip 9個(gè)壓縮級(jí)別中的哪一個(gè)，它的壓縮率都低于brotli（相比gzip，壓縮級(jí)別它還可以配置為10），壓縮速度也更慢。所以，如果可以，應(yīng)該盡快更新你的gzip壓縮算法了。
說(shuō)完對(duì)body的壓縮，再來(lái)看HTTP header的壓縮。對(duì)于HTTP/1.x來(lái)說(shuō)，header就是性能殺手。特別是當(dāng)下cookie泛濫的時(shí)代，每次請(qǐng)求都要攜帶幾個(gè)KB的頭部，很浪費(fèi)帶寬、CPU、內(nèi)存！HTTP2通過(guò) HPACK 技術(shù)大幅度降低了header編碼后的體積，這也是HTTP3的演進(jìn)方向。HPACK 到底是怎樣實(shí)現(xiàn) header 壓縮的呢？
HPACK通過(guò)Huffman算法、靜態(tài)表、動(dòng)態(tài)表對(duì)三種header都做了壓縮。比如上圖中，method GET存在于靜態(tài)表，用1個(gè)字節(jié)表示的整數(shù)2表達(dá)即可；user-agent Mozilla這行頭部非常長(zhǎng)，當(dāng)它第2次出現(xiàn)時(shí)，用2個(gè)字節(jié)的整數(shù)62表示即可；即使它第1次出現(xiàn)時(shí)，也可以用Huffman算法壓縮Mozilla這段很長(zhǎng)的瀏覽器標(biāo)識(shí)符，可以獲得最多5/8的壓縮率。
靜態(tài)表中只存放最常見(jiàn)的header，有的只有name，有的同時(shí)包括name和value。靜態(tài)表的大小很有限，目前只有61個(gè)元素。
動(dòng)態(tài)表應(yīng)用了增量編碼的思想，即，第1次出現(xiàn)時(shí)加入動(dòng)態(tài)表，第2次出現(xiàn)的時(shí)候，傳輸它在動(dòng)態(tài)表中的序號(hào)即可。
Huffman編碼在winrar等壓縮軟件中廣為使用，但HPACK中的Huffman有所不同，它使用的是靜態(tài)huffman編碼。即，它統(tǒng)計(jì)了互聯(lián)網(wǎng)上幾年內(nèi)的HTTP頭部，按照每個(gè)字符出現(xiàn)的概率，重建huffman樹(shù)，這樣，根據(jù)規(guī)則，出現(xiàn)次數(shù)最多的a、c、e或者1、2、3這些字符就只用5個(gè)bit位表示，而很少出現(xiàn)的字符則用幾十個(gè)bit位表示。
說(shuō)完header，再來(lái)看http body的編碼。這里只舉3個(gè)例子：1、只有幾十字節(jié)的小圖標(biāo)，沒(méi)有必要用獨(dú)立的HTTP請(qǐng)求傳輸，根據(jù)RFC2397的規(guī)則，可以把它直接嵌入到HTML或者CSS文件中，而瀏覽器在解析時(shí)會(huì)識(shí)別出它們，就像下圖中的頭像：
2、JS源碼文件中，可能有許多小文件，這些文件中也有許多空行、注釋，通過(guò)WebPack工具，先在服務(wù)器端打包為一個(gè)文件，并去除冗余的字符，編碼效果也很好。
3、在表單中，可以一次傳輸多個(gè)元素，比如既有復(fù)選框，也可以有文件。這就減少了HTTP請(qǐng)求的個(gè)數(shù)。
可見(jiàn)，http協(xié)議從header到 body，都有許多編碼手段，可以讓傳輸?shù)膱?bào)文更短小，既節(jié)省了帶寬，也降低了時(shí)延。
編碼效率優(yōu)化完后，再來(lái)看“信道”，這雖然是通訊領(lǐng)域的詞匯，但用來(lái)概括HTTP的優(yōu)化點(diǎn)非常合適，這里就借用下了。
二、信道利用率優(yōu)化
信道利用率包括3個(gè)優(yōu)化點(diǎn)，第一個(gè)優(yōu)化點(diǎn)是多路復(fù)用！高速的低層信道上，可以跑許多低速的高層信道。比如，主機(jī)上只有一塊網(wǎng)卡，卻能同時(shí)讓瀏覽器、微信、釘釘收發(fā)消息；一個(gè)進(jìn)程可以同時(shí)服務(wù)幾萬(wàn)個(gè)TCP連接；一個(gè)TCP連接上可以同時(shí)傳遞多個(gè)HTTP2 STREAM消息。
其次，為了讓信道有更高的利用率，還得及時(shí)恢復(fù)錯(cuò)誤。所以，TCP工作的很大一部分，都是在及時(shí)的發(fā)現(xiàn)丟包、亂序報(bào)文，并快速的處理它們。
最后，就像經(jīng)濟(jì)學(xué)里說(shuō)的，資源總是稀缺的。有限的帶寬下，如何公平的對(duì)待不同的連接、用戶和對(duì)象呢？比如下載頁(yè)面時(shí)，如果把CSS和圖片以同等優(yōu)先級(jí)下載就有問(wèn)題，圖片晚點(diǎn)顯示沒(méi)關(guān)系，但CSS沒(méi)獲取到頁(yè)面就無(wú)法顯示。另外，傳輸消息時(shí)，報(bào)文頭報(bào)并不承載目標(biāo)信息，但它又是必不可少的，如何降低這些控制信息的占比呢？
我們先從多路復(fù)用談起。廣義上來(lái)說(shuō)，多線程、協(xié)程都屬于多路復(fù)用，但這里我主要指http2的stream。因?yàn)閔ttp協(xié)議被設(shè)計(jì)為client先發(fā)request，server才能回復(fù)response，這樣收發(fā)消息，是沒(méi)辦法跑滿帶寬的。最有效率的方式是，發(fā)送端源源不斷地發(fā)請(qǐng)求、接收端源源不斷地發(fā)響應(yīng)，這對(duì)于長(zhǎng)肥網(wǎng)絡(luò)尤為有效：
HTTP2的stream就是這樣復(fù)用連接的。我們知道，chrome對(duì)一個(gè)站點(diǎn)最多同時(shí)建立6個(gè)連接，而有了HTTP2后，只需要一個(gè)連接就能高效的傳輸頁(yè)面上的數(shù)百個(gè)對(duì)象。我特意讓我的個(gè)人站點(diǎn)www.taohui.pub同時(shí)支持HTTP1和HTTP2，下圖是連接視角上HTTP2和HTTP1的區(qū)別。
熟悉chrome Network網(wǎng)絡(luò)面板的同學(xué)，肯定很熟悉waterfall，它可以幫助你分析HTTP請(qǐng)求到底慢在哪里，是請(qǐng)求發(fā)出的慢，還是響應(yīng)接收的慢，又或者是解析得太慢了。下圖還是我的站點(diǎn)在waterfall視角下的對(duì)比。
從這兩張圖可以看出，HTTP2全面優(yōu)于HTTP1。
再來(lái)看網(wǎng)絡(luò)錯(cuò)誤的恢復(fù)。在應(yīng)用層，lingering_time通過(guò)延遲關(guān)閉連接來(lái)避免瀏覽器因RST錯(cuò)誤收不到http response，而timeout則是用定時(shí)器及時(shí)發(fā)現(xiàn)錯(cuò)誤并釋放資源。
在傳輸層，通過(guò)timestamp=1可以讓TCP更精準(zhǔn)的測(cè)量出定時(shí)器的超時(shí)時(shí)間RTO。當(dāng)然，timestamp還有一個(gè)用途，就是防止長(zhǎng)肥網(wǎng)絡(luò)中的序列號(hào)回繞。
什么是序列號(hào)回繞呢？我們知道，TCP每個(gè)報(bào)文都有序列號(hào)，它不是指報(bào)文的次序，而是已經(jīng)發(fā)送的字節(jié)數(shù)。由于它是32位整數(shù)，所以最多可以處理232也就是4.2GB的飛行中報(bào)文。像上圖中，當(dāng)1G-2G這些報(bào)文在網(wǎng)絡(luò)中飛行時(shí)間過(guò)長(zhǎng)時(shí)，就會(huì)與5G-6G報(bào)文重疊，引發(fā)錯(cuò)誤。
網(wǎng)絡(luò)錯(cuò)誤還有很多種，比如報(bào)文的次序也是無(wú)法保證的。打開(kāi)tcp_sack可以減少亂序時(shí)的重發(fā)報(bào)文量，降低帶寬消耗。
用Chrome瀏覽器直接下載大文件時(shí)，網(wǎng)絡(luò)不好時(shí)，一出錯(cuò)就得全部重傳，體驗(yàn)很差。改用迅雷下載就快了很多。這是因?yàn)檠咐装汛笪募鸪珊芏嘈K，可以多線程下載，而且每個(gè)小塊出錯(cuò)后，重新下載這一個(gè)塊即可，效率很高。這個(gè)斷點(diǎn)續(xù)傳、多線程下載技術(shù)，就是HTTP的Range協(xié)議。如果你的服務(wù)是緩存，也可以使用Range協(xié)議，比如Nginx的Slice模塊就做了這件事。
實(shí)際上對(duì)于網(wǎng)絡(luò)錯(cuò)誤恢復(fù)，最精妙的算法是擁塞控制，它可以全面提升網(wǎng)絡(luò)性能。有同學(xué)會(huì)問(wèn)，TCP不是有流量控制，為什么還會(huì)發(fā)生網(wǎng)絡(luò)擁塞呢？這是因?yàn)?，TCP鏈路中的各個(gè)路由器，處理能力并不互相匹配。
就像上圖，R1的峰值網(wǎng)絡(luò)是700M/s，R2的峰值網(wǎng)絡(luò)是600M/s，它們都需要通過(guò)R3才能到達(dá)R4。然而，R3的最大帶寬只有1000M/s！當(dāng)R1、R2中的TCP全速使用各自帶寬時(shí)，就會(huì)引發(fā)R3丟包。擁塞控制就是解決丟包問(wèn)題的。
自1982年TCP誕生起，就在使用傳統(tǒng)的擁塞控制算法，它是發(fā)現(xiàn)丟包后再剎車減速，效果很不好。為什么呢？你可以觀察下圖，路由器中會(huì)有緩沖隊(duì)列，當(dāng)隊(duì)列為空時(shí)，ping的時(shí)延最短；當(dāng)隊(duì)列將滿時(shí)，ping的時(shí)延很大，但還未發(fā)生丟包；當(dāng)隊(duì)列已滿時(shí)，丟包才會(huì)發(fā)生。
所以，當(dāng)隊(duì)列出現(xiàn)積壓時(shí)，丟包沒(méi)有發(fā)生。雖然此時(shí)峰值帶寬不會(huì)減少，但網(wǎng)絡(luò)時(shí)延變大了，這是要避免的。而測(cè)量驅(qū)動(dòng)的擁塞控制算法，就在隊(duì)列剛出現(xiàn)積壓這個(gè)點(diǎn)上開(kāi)始剎車減速。在當(dāng)今內(nèi)存越來(lái)越便宜，隊(duì)列越來(lái)越大的年代，新算法尤為有效。
當(dāng)Linux內(nèi)核更新到4.9版本時(shí)，原先的CUBIC擁塞控制算法就被替換為Google的BBR算法了。從下圖中可以看到，當(dāng)丟包率達(dá)到0.01%時(shí)，CUBIC就沒(méi)法用了，而B(niǎo)BR并沒(méi)有問(wèn)題，直到丟包率達(dá)到5%時(shí)BBR的帶寬才劇烈下降。
再來(lái)看資源的平衡分配。為了公平的對(duì)待連接、用戶，服務(wù)器會(huì)做限速。比如下圖中的Leacky Bucket算法，它能夠平滑突增的流量，更公平的分配帶寬。
再比如HTTP2中的優(yōu)先級(jí)功能。一個(gè)頁(yè)面上有幾百個(gè)對(duì)象，這些對(duì)象的重要性不同，有些之間還互相依賴。比如，有些JS文件會(huì)包含jQuery.js，如果同等對(duì)待的話，即使先下載完前者，也無(wú)法使用。
HTTP2允許瀏覽器下載對(duì)象時(shí)，根據(jù)解析規(guī)則，在stream中設(shè)置每一個(gè)對(duì)象的weight優(yōu)先級(jí)（255最大，0最?。?。而各代理、資源服務(wù)器都會(huì)根據(jù)優(yōu)先級(jí)，分配內(nèi)存和帶寬，提升網(wǎng)絡(luò)效率。
最后看下TCP的報(bào)文效率，它也會(huì)影響之上的HTTP性能。比如開(kāi)啟Nagle算法后，網(wǎng)絡(luò)中的小報(bào)文數(shù)量大幅減少，考慮到40字節(jié)的報(bào)文頭部，信息占比更高。
Cork算法與Nagle算法相似，但會(huì)更激進(jìn)的控制小報(bào)文。Cork與Nagle是從發(fā)送端控制小報(bào)文，quickack則從接收端控制純ack小報(bào)文的數(shù)量，提高信息占比。
說(shuō)完相對(duì)微觀一些的信道，我們?cè)賮?lái)從宏觀上看第三個(gè)優(yōu)化點(diǎn)：傳輸路徑的優(yōu)化。
三、傳輸路徑優(yōu)化
傳輸路徑的第一個(gè)優(yōu)化點(diǎn)是緩存，瀏覽器、CDN、負(fù)載均衡等組件中，緩存無(wú)處不在。
緩存的基本用法你大概很熟悉了，這里我只講過(guò)期緩存的用法。把過(guò)期緩存直接丟掉是很浪費(fèi)的，因?yàn)椤斑^(guò)期”是客戶端的定時(shí)器決定的，并不代表資源真正失效。所以，可以把它的標(biāo)識(shí)符帶給源服務(wù)器，服務(wù)器會(huì)判斷緩存是否仍然有效，如果有效，直接返回304和空body就可以了，非常節(jié)省帶寬。
對(duì)于負(fù)載均衡而言，過(guò)期緩存還能夠保護(hù)源服務(wù)器，限制回源請(qǐng)求。當(dāng)源服務(wù)器掛掉后，還能以過(guò)期緩存給用戶帶來(lái)降級(jí)后的服務(wù)體驗(yàn)，這比返回503要好得多。
傳輸路徑的第二個(gè)優(yōu)化點(diǎn)是慢啟動(dòng)。系統(tǒng)自帶的TCP協(xié)議棧，為了避免瓶頸路由器丟包，會(huì)緩緩加大傳輸速度。它的起始速度就叫做初始擁塞窗口。
早期的初始擁塞窗口是1個(gè)MSS（通常是576字節(jié)），后來(lái)改到3個(gè)MSS（Linux 2.5.32），在Google的建議下又改到10個(gè)MSS（Linux 3.0）。之所以要不斷提升起始窗口，是因?yàn)殡S著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)頁(yè)越來(lái)越豐富，體積也越來(lái)越大。起始窗口太小，就需要更長(zhǎng)的時(shí)間下載第一個(gè)網(wǎng)頁(yè)，體驗(yàn)很差。
當(dāng)然，修改起始窗口很簡(jiǎn)單，下圖中是Linux下調(diào)整窗口的方法。
修改起始窗口是常見(jiàn)的性能優(yōu)化手段，比如CDN廠商都改過(guò)起始窗口，下圖是主流CDN廠商2014和2017年的起始窗口大小。
可見(jiàn)，有些窗口14年調(diào)得太大了，17年又縮回去了。所以，起始窗口并不是越大越好，它會(huì)增加瓶頸路由器的壓力。
再來(lái)看傳輸路徑上，如何從拉模式升級(jí)到推模式。比如index.html文件中包含，在HTTP/1中，必須先下載完index.html，才能去下載some.css，這是兩個(gè)RTT的時(shí)間。但在HTTP/2中，服務(wù)器可以通過(guò)2個(gè)stream，同時(shí)并行傳送index.html和some.css，節(jié)約了一半的時(shí)間。
其實(shí)當(dāng)出現(xiàn)丟包時(shí)，HTTP2的stream并行發(fā)送會(huì)嚴(yán)重退化，因?yàn)門CP的隊(duì)頭阻塞問(wèn)題沒(méi)有解決。
上圖中的SPDY與HTTP2是等價(jià)的。在紅綠色這3個(gè)stream并發(fā)傳輸時(shí)，TCP層仍然會(huì)串行化，假設(shè)紅色的stream在最先發(fā)送的，如果紅色報(bào)文丟失，那么即使接收端已經(jīng)收到了完整的藍(lán)、綠stream，TCP也不會(huì)把它交給HTTP2，因?yàn)門CP自身必須保證報(bào)文有序。這樣并發(fā)就沒(méi)有保證了，這就是隊(duì)頭阻塞問(wèn)題。
解決隊(duì)頭阻塞的辦法就是繞開(kāi)TCP，使用UDP協(xié)議實(shí)現(xiàn)HTTP，比如Google的GQUIC協(xié)議就是這么做的，B站在幾年前就使用它提供服務(wù)了。
UDP協(xié)議自身是不能保證可靠傳輸?shù)?，所以GQUIC需要重新在UDP之上實(shí)現(xiàn)TCP曾經(jīng)做過(guò)的事。這是HTTP的發(fā)展方向，所以目前HTTP3就基于GQUIC在制定標(biāo)準(zhǔn)。
最后，再?gòu)木W(wǎng)絡(luò)信息安全的角度，談?wù)勅绾巫鰞?yōu)化。它實(shí)際上與編碼、信道、傳輸路徑都有關(guān)聯(lián)，但其實(shí)又是獨(dú)立的環(huán)節(jié)，所以放在最后討論。
四、信息安全優(yōu)化
互聯(lián)網(wǎng)世界的信息安全，始于1995年的SSL3.0。到現(xiàn)在，許多大型網(wǎng)站都更新到2018年推出的TLS1.3了。
TLS1.2有什么問(wèn)題呢？最大問(wèn)題就是，它支持古老的密鑰協(xié)商協(xié)議，這些協(xié)議現(xiàn)在已經(jīng)不安全了。比如2015年出現(xiàn)的FREAK中間人攻擊，就可以用Amazon上的虛擬機(jī)，分分鐘攻陷支持老算法的服務(wù)器。
TLS1.3針對(duì)這一情況，取消了在當(dāng)前的計(jì)算力下，數(shù)學(xué)上已經(jīng)不再安全的非對(duì)稱密鑰協(xié)商算法。在Openssl的最新實(shí)現(xiàn)中，僅支持5種安全套件：
TLS1.3的另一個(gè)優(yōu)勢(shì)是握手速度。在TLS1.2中，由于需要2個(gè)RTT才能協(xié)商完密鑰，才誕生了session cache和session ticket這兩個(gè)工具，它們都把協(xié)商密鑰的握手降低為1個(gè)RTT。但是，這兩種方式都無(wú)法應(yīng)對(duì)重放攻擊。
而TLS1.2中的安全套件協(xié)商、ECDHE公鑰交換這兩步，在TLS1.3中被合并成一步，這大大提升了握手速度。
如果你還在使用TLS1.2，盡快升級(jí)到1.3吧，除了安全性，還有性能上的收益。
小結(jié)
HTTP的性能優(yōu)化手段眾多，從這四個(gè)維度出發(fā)，可以建立起樹(shù)狀的知識(shí)體系，囊括絕大部分的HTTP優(yōu)化點(diǎn)。
編碼效率優(yōu)化包括http header和body ，它可以使傳輸?shù)臄?shù)據(jù)更短小緊湊，從而獲得更低的時(shí)延和更高的并發(fā)。同時(shí)，好的編碼算法也可以減少編解碼時(shí)的CPU消耗。
信道利用率的優(yōu)化，可以從多路復(fù)用、錯(cuò)誤發(fā)現(xiàn)及恢復(fù)、資源分配這3個(gè)角度出發(fā)，讓快速的底層信道，有效的承載慢速的應(yīng)用層信道。
傳輸路徑的優(yōu)化，包括各級(jí)緩存、慢啟動(dòng)、消息傳送模式等，它能夠讓消息更及時(shí)的發(fā)給瀏覽器，提升用戶體驗(yàn)。
當(dāng)下互聯(lián)網(wǎng)中的信息安全，主要還是建立在TLS協(xié)議之上的。TLS1.3從安全性、性能上都有很大的提升，我們應(yīng)當(dāng)及時(shí)的升級(jí)。
希望這些知識(shí)能夠幫助你全面、高效地優(yōu)化HTTP協(xié)議！
分享標(biāo)題：四個(gè)全新維度，優(yōu)化你的HTTP性能到極致
網(wǎng)頁(yè)網(wǎng)址：http://www.dlmjj.cn/article/dhejjdg.html
