建站
咨詢
售后
建站咨詢
新聞中心
【稿件】
創(chuàng)新互聯(lián)是專業(yè)的競(jìng)秀網(wǎng)站建設(shè)公司，競(jìng)秀接單;提供做網(wǎng)站、成都網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行競(jìng)秀網(wǎng)站開(kāi)發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛(ài)的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來(lái)合作!
前言
HTTP/2 相比于 HTTP/1.1，可以說(shuō)是大幅度提高了網(wǎng)頁(yè)的性能，只需要升級(jí)到該協(xié)議就可以減少很多之前需要做的性能優(yōu)化工作，當(dāng)然兼容問(wèn)題以及如何優(yōu)雅降級(jí)應(yīng)該是國(guó)內(nèi)還不普遍使用的原因之一。
一、HTTP/1.1發(fā)明以來(lái)發(fā)生了哪些變化？
如果仔細(xì)觀察打開(kāi)那些最流行的網(wǎng)站首頁(yè)所需要下載的資源的話，會(huì)發(fā)現(xiàn)一個(gè)非常明顯的趨勢(shì)。 近年來(lái)加載網(wǎng)站首頁(yè)需要的下載的數(shù)據(jù)量在逐漸增加，并已經(jīng)超過(guò)了2100K。但在這里我們更應(yīng)該關(guān)心的是：平均每個(gè)頁(yè)面為了完成顯示與渲染所需要下載的資源數(shù)已經(jīng)超過(guò)了100個(gè)。
正如下圖所示，從2011年以來(lái)，傳輸數(shù)據(jù)大小與平均請(qǐng)求資源數(shù)量不斷持續(xù)增長(zhǎng)，并沒(méi)有減緩的跡象。該圖表中綠色直線展示了傳輸數(shù)據(jù)大小的增長(zhǎng)，紅色直線展示了平均請(qǐng)求資源數(shù)量的增長(zhǎng)。
HTTP/1.1自從1997年發(fā)布以來(lái)，我們已經(jīng)使用HTTP/1.x 相當(dāng)長(zhǎng)一段時(shí)間了，但是隨著近十年互聯(lián)網(wǎng)的爆炸式發(fā)展，從當(dāng)初網(wǎng)頁(yè)內(nèi)容以文本為主，到現(xiàn)在以富媒體（如圖片、聲音、視頻）為主,而且對(duì)頁(yè)面內(nèi)容實(shí)時(shí)性高要求的應(yīng)用越來(lái)越多(比如聊天、視頻直播)，于是當(dāng)時(shí)協(xié)議規(guī)定的某些特性，已經(jīng)無(wú)法滿足現(xiàn)代網(wǎng)絡(luò)的需求了。
二、HTTP/1.1的缺陷
1.高延遲--帶來(lái)頁(yè)面加載速度的降低
雖然近幾年來(lái)網(wǎng)絡(luò)帶寬增長(zhǎng)非常快，然而我們卻并沒(méi)有看到網(wǎng)絡(luò)延遲有對(duì)應(yīng)程度的降低。網(wǎng)絡(luò)延遲問(wèn)題主要由于隊(duì)頭阻塞(Head-Of-Line Blocking),導(dǎo)致帶寬無(wú)法被充分利用。
隊(duì)頭阻塞是指當(dāng)順序發(fā)送的請(qǐng)求序列中的一個(gè)請(qǐng)求因?yàn)槟撤N原因被阻塞時(shí)，在后面排隊(duì)的所有請(qǐng)求也一并被阻塞，會(huì)導(dǎo)致客戶端遲遲收不到數(shù)據(jù)。針對(duì)隊(duì)頭阻塞,人們嘗試過(guò)以下辦法來(lái)解決：
-
Spriting合并多張小圖為一張大圖,再用JavaScript或者CSS將小圖重新“切割”出來(lái)的技術(shù)。
-
內(nèi)聯(lián)(Inlining)是另外一種防止發(fā)送很多小圖請(qǐng)求的技巧，將圖片的原始數(shù)據(jù)嵌入在CSS文件里面的URL里，減少網(wǎng)絡(luò)請(qǐng)求次數(shù)。
- .icon1 {
- background: url(data:image/png;base64,) no-repeat;
- }
- .icon2 {
- background: url(data:image/png;base64,) no-repeat;
- }
-
拼接(Concatenation)將多個(gè)體積較小的JavaScript使用webpack等工具打包成1個(gè)體積更大的JavaScript文件,但如果其中1個(gè)文件的改動(dòng)就會(huì)導(dǎo)致大量數(shù)據(jù)被重新下載多個(gè)文件。
-
將同一頁(yè)面的資源分散到不同域名下，提升連接上限。 Chrome有個(gè)機(jī)制，同一個(gè)域名同時(shí)最多只能建立6個(gè)TCP連接，如果在同一個(gè)域名下同時(shí)有10個(gè)請(qǐng)求發(fā)生，那么其中4個(gè)請(qǐng)求會(huì)進(jìn)入排隊(duì)等待狀態(tài)，直至進(jìn)行中的請(qǐng)求完成。
2.無(wú)狀態(tài)特性--帶來(lái)的巨大HTTP頭部
由于報(bào)文Header一般會(huì)攜帶"User Agent""Cookie""Accept""Server"等許多固定的頭字段（如下圖），多達(dá)幾百字節(jié)甚至上千字節(jié)，但Body卻經(jīng)常只有幾十字節(jié)（比如GET請(qǐng)求、 204/301/304響應(yīng)），成了不折不扣的“大頭兒子”。Header里攜帶的內(nèi)容過(guò)大，在一定程度上增加了傳輸?shù)某杀?。更要命的是，成千上萬(wàn)的請(qǐng)求響應(yīng)報(bào)文里有很多字段值都是重復(fù)的，非常浪費(fèi)。
3.明文傳輸--帶來(lái)的不安全性
HTTP/1.1在傳輸數(shù)據(jù)時(shí)，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份，這在一定程度上無(wú)法保證數(shù)據(jù)的安全性。
你有沒(méi)有聽(tīng)說(shuō)過(guò)"免費(fèi)WiFi陷阱”之類的新聞呢？ 黑客就是利用了HTTP明文傳輸?shù)娜秉c(diǎn)，在公共場(chǎng)所架設(shè)一個(gè)WiFi熱點(diǎn)開(kāi)始“釣魚(yú)”，誘騙網(wǎng)民上網(wǎng)。一旦你連上了這個(gè)WiFi熱點(diǎn)，所有的流量都會(huì)被截獲保存，里面如果有銀行卡號(hào)、網(wǎng)站密碼等敏感信息的話那就危險(xiǎn)了，黑客拿到了這些數(shù)據(jù)就可以冒充你為所欲為。
4.不支持服務(wù)器推送消息
三、SPDY 協(xié)議與 HTTP/2 簡(jiǎn)介
1.SPDY 協(xié)議
上面我們提到,由于HTTP/1.x的缺陷，我們會(huì)引入雪碧圖、將小圖內(nèi)聯(lián)、使用多個(gè)域名等等的方式來(lái)提高性能。不過(guò)這些優(yōu)化都繞開(kāi)了協(xié)議，直到2009年，谷歌公開(kāi)了自行研發(fā)的 SPDY 協(xié)議，主要解決HTTP/1.1效率不高的問(wèn)題。谷歌推出SPDY，才算是正式改造HTTP協(xié)議本身。降低延遲，壓縮header等等，SPDY的實(shí)踐證明了這些優(yōu)化的效果，也最終帶來(lái)HTTP/2的誕生。
HTTP/1.1有兩個(gè)主要的缺點(diǎn)：安全不足和性能不高,由于背負(fù)著 HTTP/1.x 龐大的歷史包袱,所以協(xié)議的修改,兼容性是首要考慮的目標(biāo)，否則就會(huì)破壞互聯(lián)網(wǎng)上無(wú)數(shù)現(xiàn)有的資產(chǎn)。如上圖所示, SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)，同時(shí)可以使用已有的SSL功能。
SPDY 協(xié)議在Chrome瀏覽器上證明可行以后，就被當(dāng)作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承。
2.HTTP/2 簡(jiǎn)介
2015年，HTTP/2 發(fā)布。HTTP/2是現(xiàn)行HTTP協(xié)議（HTTP/1.x）的替代，但它不是重寫(xiě)，HTTP方法/狀態(tài)碼/語(yǔ)義都與HTTP/1.x一樣。HTTP/2基于SPDY，專注于性能，最大的一個(gè)目標(biāo)是在用戶和網(wǎng)站間只用一個(gè)連接（connection）。
HTTP/2由兩個(gè)規(guī)范（Specification）組成：
-
Hypertext Transfer Protocol version 2 - RFC7540
-
HPACK - Header Compression for HTTP/2 - RFC7541
四、HTTP/2 新特性
1.二進(jìn)制傳輸
HTTP/2傳輸數(shù)據(jù)量的大幅減少,主要有兩個(gè)原因:以二進(jìn)制方式傳輸和Header 壓縮。我們先來(lái)介紹二進(jìn)制傳輸,HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非HTTP/1.x 里純文本形式的報(bào)文 ，二進(jìn)制協(xié)議解析起來(lái)更高效。 HTTP/2 將請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼。
它把TCP協(xié)議的部分特性挪到了應(yīng)用層，把原來(lái)的"Header+Body"的消息"打散"為數(shù)個(gè)小片的二進(jìn)制"幀"(Frame),用"HEADERS"幀存放頭數(shù)據(jù)、"DATA"幀存放實(shí)體數(shù)據(jù)。HTP/2數(shù)據(jù)分幀后"Header+Body"的報(bào)文結(jié)構(gòu)就完全消失了，協(xié)議看到的只是一個(gè)個(gè)的"碎片"。
HTTP/2 中，同域名下所有通信都在單個(gè)連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個(gè)數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成。多個(gè)幀之間可以亂序發(fā)送，根據(jù)幀首部的流標(biāo)識(shí)可以重新組裝。
2.Header 壓縮
HTTP/2并沒(méi)有使用傳統(tǒng)的壓縮算法，而是開(kāi)發(fā)了專門(mén)的"HPACK”算法，在客戶端和服務(wù)器兩端建立“字典”，用索引號(hào)表示重復(fù)的字符串，還采用哈夫曼編碼來(lái)壓縮整數(shù)和字符串，可以達(dá)到50%~90%的高壓縮率。
具體來(lái)說(shuō):
-
在客戶端和服務(wù)器端使用“首部表”來(lái)跟蹤和存儲(chǔ)之前發(fā)送的鍵-值對(duì)，對(duì)于相同的數(shù)據(jù)，不再通過(guò)每次請(qǐng)求和響應(yīng)發(fā)送；
-
首部表在HTTP/2的連接存續(xù)期內(nèi)始終存在，由客戶端和服務(wù)器共同漸進(jìn)地更新；
-
每個(gè)新的首部鍵-值對(duì)要么被追加到當(dāng)前表的末尾，要么替換表中之前的值。
例如下圖中的兩個(gè)請(qǐng)求， 請(qǐng)求一發(fā)送了所有的頭部字段，第二個(gè)請(qǐng)求則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開(kāi)銷(xiāo)。
3.多路復(fù)用
在 HTTP/2 中引入了多路復(fù)用的技術(shù)。多路復(fù)用很好的解決了瀏覽器限制同一個(gè)域名下的請(qǐng)求數(shù)量的問(wèn)題，同時(shí)也接更容易實(shí)現(xiàn)全速傳輸，畢竟新開(kāi)一個(gè) TCP 連接都需要慢慢提升傳輸速度。
大家可以通過(guò) 該鏈接 直觀感受下 HTTP/2 比 HTTP/1 到底快了多少。
在 HTTP/2 中，有了二進(jìn)制分幀之后，HTTP /2 不再依賴 TCP 鏈接去實(shí)現(xiàn)多流并行了，在 HTTP/2中，
-
同域名下所有通信都在單個(gè)連接上完成。
-
單個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。
-
數(shù)據(jù)流以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成，多個(gè)幀之間可以亂序發(fā)送，因?yàn)楦鶕?jù)幀首部的流標(biāo)識(shí)可以重新組裝。
這一特性，使性能有了極大提升：
-
同個(gè)域名只需要占用一個(gè) TCP 連接，使用一個(gè)連接并行發(fā)送多個(gè)請(qǐng)求和響應(yīng),消除了因多個(gè) TCP 連接而帶來(lái)的延時(shí)和內(nèi)存消耗。
-
并行交錯(cuò)地發(fā)送多個(gè)請(qǐng)求，請(qǐng)求之間互不影響。
-
并行交錯(cuò)地發(fā)送多個(gè)響應(yīng)，響應(yīng)之間互不干擾。
-
在HTTP/2中，每個(gè)請(qǐng)求都可以帶一個(gè)31bit的優(yōu)先值，0表示最高優(yōu)先級(jí)， 數(shù)值越大優(yōu)先級(jí)越低。有了這個(gè)優(yōu)先值，客戶端和服務(wù)器就可以在處理不同的流時(shí)采取不同的策略，以最優(yōu)的方式發(fā)送流、消息和幀。
如上圖所示，多路復(fù)用的技術(shù)可以只通過(guò)一個(gè) TCP 連接就可以傳輸所有的請(qǐng)求數(shù)據(jù)。
4.Server Push
HTTP2還在一定程度上改變了傳統(tǒng)的“請(qǐng)求-應(yīng)答”工作模式，服務(wù)器不再是完全被動(dòng)地響應(yīng)請(qǐng)求，也可以新建“流”主動(dòng)向客戶端發(fā)送消息。比如，在瀏覽器剛請(qǐng)求HTML的時(shí)候就提前把可能會(huì)用到的JS、CSS文件發(fā)給客戶端，減少等待的延遲，這被稱為"服務(wù)器推送"（ Server Push，也叫 Cache push）。
例如下圖所示,服務(wù)端主動(dòng)把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML時(shí)再發(fā)送這些請(qǐng)求。
另外需要補(bǔ)充的是,服務(wù)端可以主動(dòng)推送，客戶端也有權(quán)利選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過(guò)，瀏覽器可以通過(guò)發(fā)送RST_STREAM幀來(lái)拒收。主動(dòng)推送也遵守同源策略，換句話說(shuō)，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過(guò)雙方確認(rèn)才行。
五、總結(jié)
-
HTTP/1.x 有連接無(wú)法復(fù)用、隊(duì)頭阻塞、協(xié)議開(kāi)銷(xiāo)大和安全因素等多個(gè)缺陷。
-
HTTP/2 通過(guò)多路復(fù)用、二進(jìn)制流、Header 壓縮等等技術(shù)，極大地提高了性能,http2會(huì)慢慢取代HTTP/1.x 而被廣泛采用。
參考文章
-
透視HTTP協(xié)議
-
Web協(xié)議詳解與抓包實(shí)戰(zhàn)
-
HTTP2講解
-
HTTP 2.0 協(xié)議詳解
-
前端面試之道
-
一文讀懂 HTTP/2 特性
作者介紹
浪里行舟：碩士研究生，專注于前端。個(gè)人公眾號(hào)：「前端工匠」，致力于打造適合初中級(jí)工程師能夠快速吸收的一系列優(yōu)質(zhì)文章！
【原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為.com】
網(wǎng)站標(biāo)題：詳解HTTP2四大核心特性
URL地址：http://www.5511xx.com/article/dhsjhic.html
