HTTP2改進(jìn)了哪些功能

今天小編給大家分享一下HTTP2改進(jìn)了哪些功能的相關(guān)知識(shí)點(diǎn)，內(nèi)容詳細(xì)，邏輯清晰，相信大部分人都還太了解這方面的知識(shí)，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來(lái)了解一下吧。

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的開(kāi)發(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的連接的前向安全

2015年9月，Google宣布了移除對(duì)SPDY的支持，擁抱 HTTP/2，并將在Chrome 51中生效。

相比HTTP/1.1的改進(jìn)

1. 解決串行的文件傳輸和隊(duì)頭阻塞問(wèn)題

在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è)問(wèn)題：所有的數(shù)據(jù)必須按順序傳輸，比如需要傳輸：hello，只能從h到o一個(gè)一個(gè)的傳輸，不能并行傳輸，因?yàn)榻邮斩瞬⒉恢肋@些字符的順序，所以并行傳輸在HTTP1.1是不能實(shí)現(xiàn)的。

此外，隊(duì)頭阻塞問(wèn)題在HTTP/2終于得到解決。
隊(duì)頭阻塞問(wèn)題：每個(gè) TCP 連接同時(shí)只能處理一個(gè)請(qǐng)求 - 響應(yīng)，瀏覽器按 FIFO 原則處理請(qǐng)求，如果上一個(gè)響應(yīng)沒(méi)返回，后續(xù)請(qǐng)求 - 響應(yīng)都會(huì)受阻。為了解決此問(wèn)題，出現(xiàn)了 管線化 - pipelining 技術(shù)，但是管線化存在諸多問(wèn)題，比如第一個(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)重，可以按依賴樹(shù)分配優(yōu)先級(jí)，解決了關(guān)鍵請(qǐng)求被阻塞的問(wèn)題

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è)人訪問(wèn)時(shí)，就需要等待前面某個(gè)請(qǐng)求處理完成。

解決方案

我們來(lái)看一下，HTTP/2的多路復(fù)用是如何解決的。 HTTP/2對(duì)同一域名下所有請(qǐng)求都是基于流，也就是說(shuō)同一域名不管訪問(wèn)多少文件，也只建立一路連接。同樣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)容冗余問(wèn)題

Header內(nèi)容內(nèi)容多，而且每次請(qǐng)求Header不會(huì)變化太多，沒(méi)有相應(yīng)的壓縮傳輸優(yōu)化方案

解決方案

使用HPACK算法來(lái)壓縮首部?jī)?nèi)容。

升級(jí)之后可以節(jié)省的成本

1. JS文件的合并
   我們現(xiàn)在優(yōu)化的一個(gè)主要方向就是盡量的減少HTTP的請(qǐng)求數(shù)， 對(duì)我們工程中的代碼，研發(fā)時(shí)分模塊開(kāi)發(fā)，上線時(shí)我們會(huì)把所有的代碼進(jìn)行壓縮合并，合并成一個(gè)文件，這樣不管多少模塊，都請(qǐng)求一個(gè)文件，減少了HTTP的請(qǐng)求數(shù)。但是這樣做有一個(gè)非常嚴(yán)重的問(wèn)題：文件的緩存。當(dāng)我們有100個(gè)模塊時(shí)，有一個(gè)模塊改了東西，按照之前的方式，整個(gè)文件瀏覽器都需要重新下載，不能被緩存?，F(xiàn)在我們有了HTTP/2了，模塊就可以單獨(dú)的壓縮上線，而不影響其他沒(méi)有修改的模塊。根據(jù)上面講的原理，我們盡可能將資源細(xì)?；?，文件分解地盡可能散，不用擔(dān)心請(qǐng)求數(shù)多

2. 多域名提高瀏覽器的下載速度
   之前我們有一個(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)不要使用域名分片。

以上就是“HTTP2改進(jìn)了哪些功能”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會(huì)為大家更新不同的知識(shí)，如果還想學(xué)習(xí)更多的知識(shí)，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。