前端技術(shù)優(yōu)選 今天以下文章來源于前端工匠 ，作者浪里行舟君 前言HTTP/2 相比于 HTTP/1.1，可以說是大幅度提高了網(wǎng)頁的性能，只需要升級到該協(xié)議就可以減少很多之前需要做的性能優(yōu)化工作，當然兼容問題以及如何優(yōu)雅降級應該是國內(nèi)還不普遍使用的原因之一。 雖然 HTTP/2 提高了網(wǎng)頁的性能，但是并不代表它已經(jīng)是完美的了，HTTP/3 就是為了解決 HTTP/2 所存在的一些問題而被推出來的。 一、HTTP/1.1發(fā)明以來發(fā)生了哪些變化？如果仔細觀察打開那些最流行的網(wǎng)站首頁所需要下載的資源的話，會發(fā)現(xiàn)一個非常明顯的趨勢。近年來加載網(wǎng)站首頁需要的下載的數(shù)據(jù)量在逐漸增加，并已經(jīng)超過了2100K。但在這里我們更應該關(guān)心的是：平均每個頁面為了完成顯示與渲染所需要下載的資源數(shù)已經(jīng)超過了100個。 正如下圖所示，從2011年以來,傳輸數(shù)據(jù)大小與平均請求資源數(shù)量不斷持續(xù)增長，并沒有減緩的跡象。該圖表中綠色直線展示了傳輸數(shù)據(jù)大小的增長，紅色直線展示了平均請求資源數(shù)量的增長。 HTTP/1.1自從1997年發(fā)布以來，我們已經(jīng)使用HTTP/1.x 相當長一段時間了，但是隨著近十年互聯(lián)網(wǎng)的爆炸式發(fā)展，從當初網(wǎng)頁內(nèi)容以文本為主,到現(xiàn)在以富媒體（如圖片、聲音、視頻）為主,而且對頁面內(nèi)容實時性高要求的應用越來越多(比如聊天、視頻直播),于是當時協(xié)議規(guī)定的某些特性，已經(jīng)無法滿足現(xiàn)代網(wǎng)絡(luò)的需求了。 二、HTTP/1.1的缺陷1.高延遲--帶來頁面加載速度的降低雖然近幾年來網(wǎng)絡(luò)帶寬增長非?？?，然而我們卻并沒有看到網(wǎng)絡(luò)延遲有對應程度的降低。網(wǎng)絡(luò)延遲問題主要由于隊頭阻塞(Head-Of-Line Blocking),導致帶寬無法被充分利用。 隊頭阻塞是指當順序發(fā)送的請求序列中的一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一并被阻塞，會導致客戶端遲遲收不到數(shù)據(jù)。針對隊頭阻塞,人們嘗試過以下辦法來解決:
.icon1 { background: url(data:image/png;base64,<data>) no-repeat; }.icon2 { background: url(data:image/png;base64,<data>) no-repeat; }
2.無狀態(tài)特性--帶來的巨大HTTP頭部由于報文Header一般會攜帶"User Agent""Cookie""Accept""Server"等許多固定的頭字段（如下圖），多達幾百字節(jié)甚至上千字節(jié)，但Body卻經(jīng)常只有幾十字節(jié)（比如GET請求、 204/301/304響應），成了不折不扣的“大頭兒子”。Header里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀?。更要命的是，成千上萬的請求響應報文里有很多字段值都是重復的，非常浪費。 3.明文傳輸--帶來的不安全性HTTP/1.1在傳輸數(shù)據(jù)時，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務器端都無法驗證對方的身份，這在一定程度上無法保證數(shù)據(jù)的安全性。 你有沒有聽說過"免費WiFi陷阱”之類的新聞呢？黑客就是利用了HTTP明文傳輸?shù)娜秉c，在公共場所架設(shè)一個WiFi熱點開始“釣魚”，誘騙網(wǎng)民上網(wǎng)。一旦你連上了這個WiFi熱點，所有的流量都會被截獲保存，里面如果有銀行卡號、網(wǎng)站密碼等敏感信息的話那就危險了，黑客拿到了這些數(shù)據(jù)就可以冒充你為所欲為。 4.不支持服務器推送消息三、SPDY 協(xié)議與 HTTP/2 簡介1.SPDY 協(xié)議上面我們提到,由于HTTP/1.x的缺陷，我們會引入雪碧圖、將小圖內(nèi)聯(lián)、使用多個域名等等的方式來提高性能。不過這些優(yōu)化都繞開了協(xié)議，直到2009年，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，主要解決HTTP/1.1效率不高的問題。谷歌推出SPDY，才算是正式改造HTTP協(xié)議本身。降低延遲，壓縮header等等，SPDY的實踐證明了這些優(yōu)化的效果，也最終帶來HTTP/2的誕生。 HTTP/1.1有兩個主要的缺點：安全不足和性能不高，由于背負著 HTTP/1.x 龐大的歷史包袱,所以協(xié)議的修改,兼容性是首要考慮的目標，否則就會破壞互聯(lián)網(wǎng)上無數(shù)現(xiàn)有的資產(chǎn)。如上圖所示, SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。 SPDY 協(xié)議在Chrome瀏覽器上證明可行以后，就被當作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承。 2.HTTP/2 簡介2015年，HTTP/2 發(fā)布。HTTP/2是現(xiàn)行HTTP協(xié)議（HTTP/1.x）的替代，但它不是重寫，HTTP方法/狀態(tài)碼/語義都與HTTP/1.x一樣。HTTP/2基于SPDY，專注于性能，最大的一個目標是在用戶和網(wǎng)站間只用一個連接（connection）。從目前的情況來看，國內(nèi)外一些排名靠前的站點基本都實現(xiàn)了HTTP/2的部署，使用HTTP/2能帶來20%~60%的效率提升。 HTTP/2由兩個規(guī)范（Specification）組成：
四、HTTP/2 新特性1.二進制傳輸HTTP/2傳輸數(shù)據(jù)量的大幅減少,主要有兩個原因:以二進制方式傳輸和Header 壓縮。我們先來介紹二進制傳輸,HTTP/2 采用二進制格式傳輸數(shù)據(jù)，而非HTTP/1.x 里純文本形式的報文 ，二進制協(xié)議解析起來更高效。HTTP/2 將請求和響應數(shù)據(jù)分割為更小的幀，并且它們采用二進制編碼。 它把TCP協(xié)議的部分特性挪到了應用層，把原來的"Header+Body"的消息"打散"為數(shù)個小片的二進制"幀"(Frame),用"HEADERS"幀存放頭數(shù)據(jù)、"DATA"幀存放實體數(shù)據(jù)。HTP/2數(shù)據(jù)分幀后"Header+Body"的報文結(jié)構(gòu)就完全消失了，協(xié)議看到的只是一個個的"碎片"。 HTTP/2 中，同域名下所有通信都在單個連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個或多個幀組成。多個幀之間可以亂序發(fā)送，根據(jù)幀首部的流標識可以重新組裝。 2.Header 壓縮HTTP/2并沒有使用傳統(tǒng)的壓縮算法，而是開發(fā)了專門的"HPACK”算法，在客戶端和服務器兩端建立“字典”，用索引號表示重復的字符串，還采用哈夫曼編碼來壓縮整數(shù)和字符串，可以達到50%~90%的高壓縮率。 具體來說:
例如下圖中的兩個請求， 請求一發(fā)送了所有的頭部字段，第二個請求則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷 3.多路復用在 HTTP/2 中引入了多路復用的技術(shù)。多路復用很好的解決了瀏覽器限制同一個域名下的請求數(shù)量的問題，同時也接更容易實現(xiàn)全速傳輸，畢竟新開一個 TCP 連接都需要慢慢提升傳輸速度。 大家可以通過 該鏈接 直觀感受下 HTTP/2 比 HTTP/1 到底快了多少。
這一特性，使性能有了極大提升：
4.Server PushHTTP2還在一定程度上改變了傳統(tǒng)的“請求-應答”工作模式，服務器不再是完全被動地響應請求，也可以新建“流”主動向客戶端發(fā)送消息。比如，在瀏覽器剛請求HTML的時候就提前把可能會用到的JS、CSS文件發(fā)給客戶端，減少等待的延遲，這被稱為"服務器推送"（ Server Push，也叫 Cache push） 例如下圖所示,服務端主動把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML時再發(fā)送這些請求。 另外需要補充的是,服務端可以主動推送，客戶端也有權(quán)利選擇是否接收。如果服務端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送RST_STREAM幀來拒收。主動推送也遵守同源策略，換句話說，服務器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過雙方確認才行。 5.提高安全性出于兼容的考慮，HTTP/2延續(xù)了HTTP/1的“明文”特點，可以像以前一樣使用明文傳輸數(shù)據(jù)，不強制使用加密通信，不過格式還是二進制，只是不需要解密。 但由于HTTPS已經(jīng)是大勢所趨，而且主流的瀏覽器Chrome、Firefox等都公開宣布只支持加密的HTTP/2，所以“事實上”的HTTP/2是加密的。也就是說，互聯(lián)網(wǎng)上通常所能見到的HTTP/2都是使用"https”協(xié)議名，跑在TLS上面。HTTP/2協(xié)議定義了兩個字符串標識符：“h2"表示加密的HTTP/2，“h2c”表示明文的HTTP/2。 六、HTTP/3 新特性1.HTTP/2 的缺點雖然 HTTP/2 解決了很多之前舊版本的問題，但是它還是存在一個巨大的問題，主要是底層支撐的 TCP 協(xié)議造成的。HTTP/2的缺點主要有以下幾點：
HTTP/2都是使用TCP協(xié)議來傳輸?shù)?，而如果使用HTTPS的話，還需要使用TLS協(xié)議進行安全傳輸，而使用TLS也需要一個握手過程，這樣就需要有兩個握手延遲過程： ①在建立TCP連接的時候，需要和服務器進行三次握手來確認連接成功，也就是說需要在消耗完1.5個RTT之后才能進行數(shù)據(jù)傳輸。 ②進行TLS連接，TLS有兩個版本——TLS1.2和TLS1.3，每個版本建立連接所花的時間不同，大致是需要1~2個RTT。 總之，在傳輸數(shù)據(jù)之前，我們需要花掉 3～4 個 RTT。
上文我們提到在HTTP/2中，多個請求是跑在一個TCP管道中的。但當出現(xiàn)了丟包時，HTTP/2 的表現(xiàn)反倒不如 HTTP/1 了。因為TCP為了保證可靠傳輸，有個特別的“丟包重傳”機制，丟失的包必須要等待重新傳輸確認，HTTP/2出現(xiàn)丟包時，整個 TCP 都要開始等待重傳，那么就會阻塞該TCP連接中的所有請求（如下圖）。而對于 HTTP/1.1 來說，可以開啟多個 TCP 連接，出現(xiàn)這種情況反到只會影響其中一個連接，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。 讀到這里，可能就會有人考慮為什么不直接去修改 TCP 協(xié)議？其實這已經(jīng)是一件不可能完成的任務了。因為 TCP 存在的時間實在太長，已經(jīng)充斥在各種設(shè)備中，并且這個協(xié)議是由操作系統(tǒng)實現(xiàn)的，更新起來不大現(xiàn)實。 2.HTTP/3簡介Google 在推SPDY的時候就已經(jīng)意識到了這些問題，于是就另起爐灶搞了一個基于 UDP 協(xié)議的“QUIC”協(xié)議，讓HTTP跑在QUIC上而不是TCP上。而這個“HTTP over QUIC”就是HTTP協(xié)議的下一個大版本，HTTP/3。它在HTTP/2的基礎(chǔ)上又實現(xiàn)了質(zhì)的飛躍，真正“完美”地解決了“隊頭阻塞”問題。
QUIC 雖然基于 UDP，但是在原本的基礎(chǔ)上新增了很多功能，接下來我們重點介紹幾個QUIC新功能。不過HTTP/3目前還處于草案階段，正式發(fā)布前可能會有變動，所以本文盡量不涉及那些不穩(wěn)定的細節(jié)。 3.QUIC新功能上面我們提到QUIC基于UDP，而UDP是“無連接”的，根本就不需要“握手”和“揮手”，所以就比TCP來得快。此外QUIC也實現(xiàn)了可靠傳輸，保證數(shù)據(jù)一定能夠抵達目的地。它還引入了類似HTTP/2的“流”和“多路復用”，單個“流"是有序的，可能會因為丟包而阻塞，但其他“流”不會受到影響。具體來說QUIC協(xié)議有以下特點：
雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎(chǔ)之上增加了一層來保證數(shù)據(jù)可靠性傳輸。它提供了數(shù)據(jù)包重傳、擁塞控制以及其他一些TCP中存在的特性。
由于QUIC是基于UDP的，所以QUIC可以實現(xiàn)使用0-RTT或者1-RTT來建立連接，這意味著QUIC可以用最快的速度來發(fā)送和接收數(shù)據(jù)，這樣可以大大提升首次打開頁面的速度。0RTT 建連可以說是 QUIC 相比 HTTP2 最大的性能優(yōu)勢。
目前QUIC使用的是TLS1.3，相較于早期版本TLS1.3有更多的優(yōu)點，其中最重要的一點是減少了握手所花費的RTT個數(shù)。
和TCP不同，QUIC實現(xiàn)了在同一物理連接上可以有多個獨立的邏輯數(shù)據(jù)流（如下圖）。實現(xiàn)了數(shù)據(jù)流的單獨傳輸，就解決了TCP中隊頭阻塞的問題。
七、總結(jié)
參考文章
|
|
|
來自： 風聲之家 > 《服務器與開發(fā)》
在 HTTP/2 中，有了二進制分幀之后，HTTP /2 不再依賴 TCP 鏈接去實現(xiàn)多流并行了，在 HTTP/2中,
如上圖所示，多路復用的技術(shù)可以只通過一個 TCP 連接就可以傳輸所有的請求數(shù)據(jù)。
