?2016-2026 Matools All rights reserved,
粵ICP備17059708號(hào)
更多內(nèi)容，歡迎關(guān)注微信公眾號(hào)：全菜工程師小輝。公眾號(hào)回復(fù)關(guān)鍵詞，領(lǐng)取免費(fèi)學(xué)習(xí)資料。
HTTP版本簡(jiǎn)史
* HTTP/0.9：
（1991年）基于GET請(qǐng)求的文本傳輸協(xié)議
* HTTPS：
（1994年）安全的HTTP傳輸協(xié)議
* HTTP/1.0：
（1996年）增加HTTP頭、擴(kuò)展PUT、POST等方法
* HTTP/1.1：
（1999年）長(zhǎng)連接、流水線支持，最廣泛使用的HTTP傳輸協(xié)議
* SPDY：
（2012年）針對(duì)HTTP的增強(qiáng)，工作在SSL層之上、HTTP層之下
* HTTP/2：
（2015年）二進(jìn)制格式、多路復(fù)用、服務(wù)器“推送”、頭部壓縮
HTTP/2的開發(fā)基于SPDY進(jìn)行躍進(jìn)式改進(jìn)在諸多修改中，最顯著的改進(jìn)在于，HTTP/2使用了一份經(jīng)過(guò)定制的壓縮算法，基于霍夫曼編碼，以此替代了SPDY的動(dòng)態(tài)流壓縮算法，以避免對(duì)協(xié)議的Oracle攻擊——這一類攻擊以CRIME為代表。此外，HTTP/2禁用了諸多加密包，以保證基于TLS的連接的前向安全（參考Wiki）
2015年9月，Google宣布了移除對(duì)SPDY的支持，擁抱 HTTP/2，并將在Chrome 51中生效。
HTTP/2和HTTP/1.1的速度對(duì)比，可以點(diǎn)擊查看下面兩個(gè)網(wǎng)頁(yè)：
https://http2.akamai.com/demo <https://http2.akamai.com/demo>
http://http2.cdnpe.com/index.html <http://http2.cdnpe.com/index.html>
相比HTTP/1.1的改進(jìn)
1. 解決串行的文件傳輸和隊(duì)頭阻塞問題
在HTTP/1.1中，當(dāng)請(qǐng)求a文件時(shí)，b文件只能等待，等待a連接到服務(wù)器、服務(wù)器處理文件、服務(wù)器返回文件，這三個(gè)步驟。我們假設(shè)這三步用時(shí)都是1秒，那么a文件用時(shí)為3秒，b文件傳輸完成用時(shí)為6秒，依此類推。
此項(xiàng)計(jì)算有一個(gè)前提條件，就是瀏覽器和服務(wù)器是單通道傳輸
在HTTP/1.1的協(xié)議中，由于傳輸?shù)膔equest和response都是基本于文本的，這樣就會(huì)引發(fā)一個(gè)問題：所有的數(shù)據(jù)必須按順序傳輸，比如需要傳輸：hello，只能從h到o一個(gè)一個(gè)的傳輸，不能并行傳輸，因?yàn)榻邮斩瞬⒉恢肋@些字符的順序，所以并行傳輸在HTTP1.1是不能實(shí)現(xiàn)的。
此外，隊(duì)頭阻塞問題在HTTP/2終于得到解決。
隊(duì)頭阻塞問題：每個(gè) TCP 連接同時(shí)只能處理一個(gè)請(qǐng)求 - 響應(yīng)，瀏覽器按 FIFO 原則處理請(qǐng)求，如果上一個(gè)響應(yīng)沒返回，后續(xù)請(qǐng)求 -
響應(yīng)都會(huì)受阻。為了解決此問題，出現(xiàn)了 管線化 - pipelining
技術(shù)，但是管線化存在諸多問題，比如第一個(gè)響應(yīng)慢還是會(huì)阻塞后續(xù)響應(yīng)、服務(wù)器為了按序返回相應(yīng)需要緩存多個(gè)響應(yīng)占用更多資源、瀏覽器中途斷連重試服務(wù)器可能得重新處理多個(gè)請(qǐng)求、還有必須客戶端
- 代理 - 服務(wù)器都支持管線化。
解決方案
HTTP/2引入二進(jìn)制數(shù)據(jù)幀和流的概念，其中幀對(duì)數(shù)據(jù)進(jìn)行順序標(biāo)識(shí)，這樣瀏覽器收到數(shù)據(jù)之后，就可以按照序列對(duì)數(shù)據(jù)進(jìn)行合并，而不會(huì)出現(xiàn)合并后數(shù)據(jù)錯(cuò)亂的情況。同樣是因?yàn)橛辛诵蛄?，服?wù)器就可以并行的傳輸數(shù)據(jù)，這就是流所做的事情。
此外，HTTP/2里的每個(gè)stream都可以設(shè)置依賴 (Dependency)和權(quán)重，可以按依賴樹分配優(yōu)先級(jí)，解決了關(guān)鍵請(qǐng)求被阻塞的問題
2. 解決連接數(shù)過(guò)多。
我們假設(shè)Apache設(shè)置了最大并發(fā)數(shù)為300，因?yàn)闉g覽器限制，瀏覽器發(fā)起的最大請(qǐng)求數(shù)為6，也就是服務(wù)器能承載的最高并發(fā)為50，當(dāng)?shù)?1個(gè)人訪問時(shí)，就需要等待前面某個(gè)請(qǐng)求處理完成。
解決方案
我們來(lái)看一下，HTTP/2的多路復(fù)用是如何解決的。
HTTP/2對(duì)同一域名下所有請(qǐng)求都是基于流，也就是說(shuō)同一域名不管訪問多少文件，也只建立一路連接。同樣Apache的最大連接數(shù)為300，因?yàn)橛辛诉@個(gè)新特性，最大的并發(fā)就可以提升到300，比原來(lái)提升了6倍！
此外，HTTP/2支持服務(wù)器推送。
瀏覽器發(fā)送一個(gè)請(qǐng)求，服務(wù)器主動(dòng)向?yàn)g覽器推送與這個(gè)請(qǐng)求相關(guān)的資源，這樣瀏覽器就不用發(fā)起后續(xù)請(qǐng)求。
這主要是針對(duì)資源內(nèi)聯(lián)做出的優(yōu)化，相較于HTTP/1.1 資源內(nèi)聯(lián)的優(yōu)勢(shì):
* 客戶端可以緩存推送的資源
* 客戶端可以拒收推送過(guò)來(lái)的資源
* 推送資源可以由不同頁(yè)面共享
* 服務(wù)器可以按照優(yōu)先級(jí)推送資源
3. Header內(nèi)容冗余問題。
Header內(nèi)容內(nèi)容多，而且每次請(qǐng)求Header不會(huì)變化太多，沒有相應(yīng)的壓縮傳輸優(yōu)化方案
解決方案
使用HPACK算法來(lái)壓縮首部?jī)?nèi)容。
升級(jí)之后可以節(jié)省的成本
* JS文件的合并
我們現(xiàn)在優(yōu)化的一個(gè)主要方向就是盡量的減少HTTP的請(qǐng)求數(shù)，
對(duì)我們工程中的代碼，研發(fā)時(shí)分模塊開發(fā)，上線時(shí)我們會(huì)把所有的代碼進(jìn)行壓縮合并，合并成一個(gè)文件，這樣不管多少模塊，都請(qǐng)求一個(gè)文件，減少了HTTP的請(qǐng)求數(shù)。但是這樣做有一個(gè)非常嚴(yán)重的問題：文件的緩存。當(dāng)我們有100個(gè)模塊時(shí)，有一個(gè)模塊改了東西，按照之前的方式，整個(gè)文件瀏覽器都需要重新下載，不能被緩存?，F(xiàn)在我們有了HTTP/2了，模塊就可以單獨(dú)的壓縮上線，而不影響其他沒有修改的模塊。根據(jù)上面講的原理，我們盡可能將資源細(xì)?；?，文件分解地盡可能散，不用擔(dān)心請(qǐng)求數(shù)多
雪碧圖，文件合并同理可以棄用
* 多域名提高瀏覽器的下載速度
之前我們有一個(gè)優(yōu)化就是把css文件和js文件放到2個(gè)域名下面，這樣瀏覽器就可以對(duì)這兩個(gè)類型的文件進(jìn)行同時(shí)下載，避免了瀏覽器6個(gè)通道的限制，這樣做的缺點(diǎn)也是明顯的：
1.DNS的解析時(shí)間會(huì)變長(zhǎng)。
2.增加了服務(wù)器的壓力。
有了HTTP/2之后，請(qǐng)不要使用域名分片。
更多內(nèi)容，歡迎關(guān)注微信公眾號(hào)：全菜工程師小輝。公眾號(hào)回復(fù)關(guān)鍵詞，領(lǐng)取免費(fèi)學(xué)習(xí)資料。
熱門工具 換一換