2015年2月19日，HTTP協(xié)議規(guī)范的標(biāo)準(zhǔn)化組織The Internet Engineering Task Force's HTTP Working Group，正式發(fā)布了HTTP 2協(xié)議。HTTP協(xié)議工作組實(shí)際上發(fā)布了兩個(gè)相關(guān)的規(guī)范：

1）HTTP/2協(xié)議
2）HPACK

HPACK是HTTP/2協(xié)議Header部分的壓縮規(guī)范。

HTTP/2協(xié)議規(guī)范的制定工作是從2012年開始的，是為了響應(yīng)Google的SPDY協(xié)議而制定。

HTTP/1.x協(xié)議最大的問(wèn)題是使用了多個(gè)連接來(lái)并行地載入資源，因?yàn)楫?dāng)客戶端和服務(wù)器之間使用單個(gè)連接來(lái)請(qǐng)求網(wǎng)頁(yè)所需的多種不同的對(duì)象（圖片、CSS以及JavaScript等）時(shí)，這些對(duì)象必須按順序依次傳輸，一個(gè)接一個(gè)。如果某個(gè)對(duì)象需要花很多時(shí)間才能完成傳輸，那么就可能占據(jù)大量的服務(wù)器的創(chuàng)建時(shí)間，而其后的對(duì)象都必須等待。
這導(dǎo)致了大多數(shù)HTTP/1.x連接僅被用于請(qǐng)求單個(gè)的對(duì)象。Web客戶端根據(jù)需求并行地載入它們需要的對(duì)象，以至于不得不要求服務(wù)器創(chuàng)建多個(gè)連接。這使得服務(wù)器的開銷巨大：它耗光了額外的網(wǎng)絡(luò)資源，占據(jù)了額外的處理時(shí)間，而且客戶端與服務(wù)器之間的每一個(gè)連接都需要數(shù)個(gè)往返通信。

HTTP/2協(xié)議直接解決了這個(gè)問(wèn)題。在HTTP/2協(xié)議中，在單個(gè)TCP連接上，客戶端和服務(wù)器之間是全雙工的數(shù)據(jù)流的多路復(fù)用。每一個(gè)流都可以攜帶一對(duì)請(qǐng)求/響應(yīng)，客戶端向服務(wù)器發(fā)起多個(gè)請(qǐng)求時(shí)只需使用多路復(fù)用即可。而且，所有的數(shù)據(jù)流彼此是相互獨(dú)立的。如果某個(gè)數(shù)據(jù)流很慢，HTTP/2連接可以繼續(xù)傳輸其它數(shù)據(jù)流的數(shù)據(jù)。同樣地，客戶端可以請(qǐng)求某個(gè)很大的對(duì)象，再請(qǐng)求某個(gè)小對(duì)象，那么小對(duì)象的響應(yīng)可能先返回，大對(duì)象的響應(yīng)可能需一段時(shí)間后才得到響應(yīng)。在HTTP/2協(xié)議中，無(wú)需HTTP/1.x協(xié)議的等待和順序處理。HTTP/2協(xié)議規(guī)范建議客戶端和服務(wù)器都需要支持在單個(gè)連接上傳輸至少100種不同的數(shù)據(jù)流。

HTTP/2協(xié)議還有其它的性能和功能方面的改進(jìn)。傳統(tǒng)的HTTP/1.x協(xié)議是一個(gè)文本協(xié)議，其請(qǐng)求和響應(yīng)都使用了可讀的純文本格式。而HTTP/2協(xié)議是一個(gè)二進(jìn)制協(xié)議，它把請(qǐng)求和響應(yīng)拆分成了不可讀的順序幀，在TCP連接上傳輸。HTTP/2協(xié)議還允許服務(wù)器直接推送數(shù)據(jù)流到客戶端，無(wú)需客戶端發(fā)起最初的請(qǐng)求。

作為一個(gè)二進(jìn)制協(xié)議，HTTP/2協(xié)議沒(méi)有改變HTTP連接的底層語(yǔ)義。每一個(gè)請(qǐng)求和響應(yīng)都仍然包括Header部分和Body部分，Header部分通常用于標(biāo)識(shí)Body部分的元數(shù)據(jù)信息。不過(guò)，HTTP/2協(xié)議在表示同樣的消息設(shè)計(jì)時(shí)更富有效率。

HTTP/2協(xié)議在很大程度上基于了Google的SPDY協(xié)議而制定，但是有一些SPDY協(xié)議的特性在HTTP/2協(xié)議中沒(méi)有采納。HTTP/2協(xié)議還是需要TLS（Transport Layer Security，傳輸層安全）來(lái)增強(qiáng)隱私和安全。HTTP/2協(xié)議在這方面是可選的，既可以在TLS上傳輸，又可以在純TCP上傳輸。但是，目前業(yè)界有部分HTTP/2協(xié)議的服務(wù)提供商宣稱自己只支持加密TLS連接的HTTP/2通信，以便保護(hù)用戶的隱私。

SPDY協(xié)議最初在雙向傳輸上還使用了gzip來(lái)壓縮Header部分。但是在2012年，gzip在Header部分的使用被發(fā)現(xiàn)是很危險(xiǎn)的，它在遭受攻擊時(shí)很容易暴露用戶的隱私，從而導(dǎo)致犯罪。隨后SPDY協(xié)議做了改變，停止了gzip壓縮的使用。HTTP/2協(xié)議規(guī)范的第二部分解決了這個(gè)問(wèn)題：HPACK。

HPACK是一種壓縮HTTP/2連接的Header部分的方法，可以有效地避免用戶隱私的泄露。與gzip不同，HPACK是一種面向通用目標(biāo)的壓縮算法，以滿足HTTP/2協(xié)議的需求。
隨著IETF簽署通過(guò)了HTTP/2協(xié)議，接下來(lái)HTTP/2協(xié)議將由RFC正式發(fā)布。

可以預(yù)見(jiàn)，未來(lái)各瀏覽器都將很好地支持HTTP/2協(xié)議，Google最新的Chrome 40版將包含對(duì)HTTP/2協(xié)議的支持，并且Google宣稱在2016年年初將會(huì)從Chrome瀏覽器中移除對(duì)SPDY協(xié)議的支持。這也預(yù)示著SPDY協(xié)議的壽命在明年將會(huì)走到盡頭。Mozilla瀏覽器宣布，F(xiàn)irefox 36版將會(huì)支持HTTP/2協(xié)議的第14版草案，在Firefox 37或38版將會(huì)支持到HTTP/2協(xié)議的第16版草案，再往后的版本將會(huì)完全支持HTTP/2協(xié)議。微軟的Windows 10操作系統(tǒng)的技術(shù)預(yù)覽版也包含了對(duì)HTTP/2協(xié)議的第14版草案的支持，其新的瀏覽器項(xiàng)目Spartan將會(huì)完全替代IE瀏覽器，提供對(duì)HTTP/2協(xié)議的完整支持。