HTTP/2 是 HTTP 協(xié)議自 1999 年 HTTP 1.1 發(fā)布后的首個(gè)更新，主要基于 SPDY 協(xié)議。由互聯(lián)網(wǎng)工程任務(wù)組（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小組進(jìn)行開(kāi)發(fā)。該組織于2014年12月將HTTP/2標(biāo)準(zhǔn)提議遞交至IESG進(jìn)行討論，于2015年2月17日被批準(zhǔn)。HTTP/2標(biāo)準(zhǔn)于2015年5月以RFC 7540正式發(fā)表。
那 HTTP/2 到底有哪些具體變化呢？
先來(lái)理解幾個(gè)概念：
幀：HTTP/2 數(shù)據(jù)通信的最小單位消息：指 HTTP/2 中邏輯上的 HTTP 消息。例如請(qǐng)求和響應(yīng)等，消息由一個(gè)或多個(gè)幀組成。
流：存在于連接中的一個(gè)虛擬通道。流可以承載雙向消息，每個(gè)流都有一個(gè)唯一的整數(shù)ID。
HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP 1.x 的文本格式，二進(jìn)制協(xié)議解析起來(lái)更高效。 HTTP / 1 的請(qǐng)求和響應(yīng)報(bào)文，都是由起始行，首部和實(shí)體正文（可選）組成，各部分之間以文本換行符分隔。HTTP/2 將請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼。
HTTP/2 中，同域名下所有通信都在單個(gè)連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個(gè)數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成。多個(gè)幀之間可以亂序發(fā)送，根據(jù)幀首部的流標(biāo)識(shí)可以重新組裝。
多路復(fù)用，代替原來(lái)的序列和阻塞機(jī)制。所有就是請(qǐng)求的都是通過(guò)一個(gè) TCP連接并發(fā)完成。 HTTP 1.x 中，如果想并發(fā)多個(gè)請(qǐng)求，必須使用多個(gè) TCP 鏈接，且瀏覽器為了控制資源，還會(huì)對(duì)單個(gè)域名有 6-8個(gè)的TCP鏈接請(qǐng)求限制，如下圖，紅色圈出來(lái)的請(qǐng)求就因域名鏈接數(shù)已超過(guò)限制，而被掛起等待了一段時(shí)間：
在 HTTP/2 中，有了二進(jìn)制分幀之后，HTTP /2 不再依賴(lài) 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è) TCP 連接而帶來(lái)的延時(shí)和內(nèi)存消耗。
單個(gè)連接上可以并行交錯(cuò)的請(qǐng)求和響應(yīng)，之間互不干擾。
在HTTP/2中，每個(gè)請(qǐng)求都可以帶一個(gè)31bit的優(yōu)先值，0表示高優(yōu)先級(jí)， 數(shù)值越大優(yōu)先級(jí)越低。有了這個(gè)優(yōu)先值，客戶(hù)端和服務(wù)器就可以在處理不同的流時(shí)采取不同的策略，以最優(yōu)的方式發(fā)送流、消息和幀。
服務(wù)端可以在發(fā)送頁(yè)面HTML時(shí)主動(dòng)推送其它資源，而不用等到瀏覽器解析到相應(yīng)位置，發(fā)起請(qǐng)求再響應(yīng)。例如服務(wù)端可以主動(dòng)把JS和CSS文件推送給客戶(hù)端，而不需要客戶(hù)端解析HTML時(shí)再發(fā)送這些請(qǐng)求。
服務(wù)端可以主動(dòng)推送，客戶(hù)端也有權(quán)利選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過(guò)，瀏覽器可以通過(guò)發(fā)送RST_STREAM幀來(lái)拒收。主動(dòng)推送也遵守同源策略，服務(wù)器不會(huì)隨便推送第三方資源給客戶(hù)端。
HTTP 1.1請(qǐng)求的大小變得越來(lái)越大，有時(shí)甚至?xí)笥赥CP窗口的初始大小，因?yàn)樗鼈冃枰却龓е鳤CK的響應(yīng)回來(lái)以后才能繼續(xù)被發(fā)送。HTTP/2對(duì)消息頭采用HPACK（專(zhuān)為http/2頭部設(shè)計(jì)的壓縮格式）進(jìn)行壓縮傳輸，能夠節(jié)省消息頭占用的網(wǎng)絡(luò)的流量。而HTTP/1.x每次請(qǐng)求，都會(huì)攜帶大量冗余頭信息，浪費(fèi)了很多帶寬資源。
HTTP每一次通信都會(huì)攜帶一組頭部，用于描述這次通信的的資源、瀏覽器屬性、cookie等，例如
為了減少這塊的資源消耗并提升性能， HTTP/2對(duì)這些首部采取了壓縮策略：
HTTP/2在客戶(hù)端和服務(wù)器端使用“首部表”來(lái)跟蹤和存儲(chǔ)之前發(fā)送的鍵－值對(duì)，對(duì)于相同的數(shù)據(jù)，不再通過(guò)每次請(qǐng)求和響應(yīng)發(fā)送；
首部表在HTTP/2的連接存續(xù)期內(nèi)始終存在，由客戶(hù)端和服務(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)。
我們來(lái)看一個(gè)實(shí)際的例子，下面是用WireShark抓取的訪問(wèn)google首頁(yè)的包：
上圖是是訪問(wèn) https://www.google.com/ 抓到的第一個(gè)請(qǐng)求的頭部，可以看到頭部的內(nèi)容，總共占用了437 bytes，我們選中頭部的cookie，可以看到cookie總共占用了118 bytes。接下來(lái)我們看看第二個(gè)請(qǐng)求的頭部：
從上圖可以看到，得益于頭部壓縮，第二個(gè)請(qǐng)求中cookie只占用了1個(gè)字節(jié)，我們來(lái)看看變化了的Accept字段：
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線(xiàn)，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性?xún)r(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專(zhuān)為企業(yè)上云打造定制，能夠滿(mǎn)足用戶(hù)豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
