Http協(xié)議，對(duì)于擁有豐富開發(fā)經(jīng)驗(yàn)的程序員來(lái)說(shuō)簡(jiǎn)直是信手拈來(lái)，家常便飯。雖然天天見，但是對(duì)于http協(xié)議的問題，可能很多人在沒有積極準(zhǔn)備的情況下，不一定能很好的回答出來(lái)。

[[271469]]

今天，我們就來(lái)講講http 2.0和之前版本的區(qū)別。

一、HTTP定義

HTTP協(xié)議(HyperTextTransferProtocol，超文本傳輸協(xié)議)是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議。

二、HTTP發(fā)展史

三、HTTP 2.0 vs 1.0 性能

HTTP 2.0 的出現(xiàn)，相比于 HTTP 1.x ，大幅度的提升了 web 性能。

這是 Akamai 公司建立的一個(gè)官方的演示，用以說(shuō)明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同時(shí)請(qǐng)求 379 張圖片，從Load time 的對(duì)比可以看出 HTTP/2 在速度上的優(yōu)勢(shì)。

四、HTTP 2.0 和 1.1 區(qū)別

后面我們將通過(guò)幾個(gè)方面來(lái)說(shuō)說(shuō)HTTP 2.0 和 HTTP1.1 區(qū)別，并且和你解釋下其中的原理。

區(qū)別一：多路復(fù)用

多路復(fù)用允許單一的 HTTP/2 連接同時(shí)發(fā)起多重的請(qǐng)求-響應(yīng)消息?？磦€(gè)例子：

整個(gè)訪問流程第一次請(qǐng)求index.html頁(yè)面,之后瀏覽器會(huì)去請(qǐng)求style.css和scripts.js的文件。左邊的圖是順序加載兩個(gè)個(gè)文件的，右邊則是并行加載兩個(gè)文件。

我們知道HTTP底層其實(shí)依賴的是TCP協(xié)議，那問題是在同一個(gè)連接里面同時(shí)發(fā)生兩個(gè)請(qǐng)求響應(yīng)著是怎么做到的?

首先你要知道，TCP連接相當(dāng)于兩根管道(一個(gè)用于服務(wù)器到客戶端，一個(gè)用于客戶端到服務(wù)器)，管道里面數(shù)據(jù)傳輸是通過(guò)字節(jié)碼傳輸，傳輸是有序的，每個(gè)字節(jié)都是一個(gè)一個(gè)來(lái)傳輸。

例如客戶端要向服務(wù)器發(fā)送Hello、World兩個(gè)單詞，只能是先發(fā)送Hello再發(fā)送World，沒辦法同時(shí)發(fā)送這兩個(gè)單詞。不然服務(wù)器收到的可能就是HWeolrllod(注意是穿插著發(fā)過(guò)去了，但是順序還是不會(huì)亂)。這樣服務(wù)器就懵b了。

接上面的問題，能否同時(shí)發(fā)送Hello和World兩個(gè)單詞能，當(dāng)然也是可以的，可以將數(shù)據(jù)拆成包，給每個(gè)包打上標(biāo)簽。發(fā)的時(shí)候是這樣的①H ②W ①e ②o ①l ②r ①l ②l ①o ②d。這樣到了服務(wù)器，服務(wù)器根據(jù)標(biāo)簽把兩個(gè)單詞區(qū)分開來(lái)。實(shí)際的發(fā)送效果如下圖：

要實(shí)現(xiàn)上面的效果我們引入一個(gè)新的概念就是：二進(jìn)制分幀。

二進(jìn)制分幀層 在 應(yīng)用層(HTTP/2)和傳輸層(TCP or UDP)之間。HTTP/2并沒有去修改TCP協(xié)議而是盡可能的利用TCP的特性。

在二進(jìn)制分幀層中， HTTP/2 會(huì)將所有傳輸?shù)男畔⒎指顬閹?frame),并對(duì)它們采用二進(jìn)制格式的編碼 ，其中 首部信息會(huì)被封裝到 HEADER frame，而相應(yīng)的 Request Body 則封裝到 DATA frame 里面。

HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬，而是低延遲。TCP 連接會(huì)隨著時(shí)間進(jìn)行自我「調(diào)諧」，起初會(huì)限制連接的最大速度，如果數(shù)據(jù)成功傳輸，會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣?。這種調(diào)諧則被稱為 TCP 慢啟動(dòng)。由于這種原因，讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效。

HTTP/2 通過(guò)讓所有數(shù)據(jù)流共用同一個(gè)連接，可以更有效地使用 TCP 連接，讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升。

通過(guò)下面兩張圖，我們可以更加深入的認(rèn)識(shí)多路復(fù)用：

HTTP/1

HTTP/2

總結(jié)下：多路復(fù)用技術(shù)：?jiǎn)芜B接多資源的方式，減少服務(wù)端的鏈接壓力,內(nèi)存占用更少,連接吞吐量更大;由于減少TCP 慢啟動(dòng)時(shí)間，提高傳輸?shù)乃俣取?/p>

區(qū)別二：首部壓縮

為什么要壓縮?在 HTTP/1 中，HTTP 請(qǐng)求和響應(yīng)都是由「狀態(tài)行、請(qǐng)求 / 響應(yīng)頭部、消息主體」三部分組成。一般而言，消息主體都會(huì)經(jīng)過(guò) gzip 壓縮，或者本身傳輸?shù)木褪菈嚎s過(guò)后的二進(jìn)制文件(例如圖片、音頻)，但狀態(tài)行和頭部卻沒有經(jīng)過(guò)任何壓縮，直接以純文本傳輸。

隨著 Web 功能越來(lái)越復(fù)雜，每個(gè)頁(yè)面產(chǎn)生的請(qǐng)求數(shù)也越來(lái)越多，導(dǎo)致消耗在頭部的流量越來(lái)越多，尤其是每次都要傳輸 UserAgent、Cookie 這類不會(huì)頻繁變動(dòng)的內(nèi)容，完全是一種浪費(fèi)。

我們?cè)儆猛ㄋ椎恼Z(yǔ)言解釋下，壓縮的原理。頭部壓縮需要在支持 HTTP/2 的瀏覽器和服務(wù)端之間。

• 維護(hù)一份相同的靜態(tài)字典(Static Table)，包含常見的頭部名稱，以及特別常見的頭部名稱與值的組合;
• 維護(hù)一份相同的動(dòng)態(tài)字典(Dynamic Table)，可以動(dòng)態(tài)的添加內(nèi)容;
• 支持基于靜態(tài)哈夫曼碼表的哈夫曼編碼(Huffman Coding);

靜態(tài)字典的作用有兩個(gè)：

1. 對(duì)于完全匹配的頭部鍵值對(duì)，例如 “:method :GET”，可以直接使用一個(gè)字符表示;
2. 對(duì)于頭部名稱可以匹配的鍵值對(duì)，例如 “cookie :xxxxxxx”，可以將名稱使用一個(gè)字符表示。

HTTP/2 中的靜態(tài)字典如下(以下只截取了部分，完整表格在這里)：

同時(shí)，瀏覽器和服務(wù)端都可以向動(dòng)態(tài)字典中添加鍵值對(duì)，之后這個(gè)鍵值對(duì)就可以使用一個(gè)字符表示了。需要注意的是，動(dòng)態(tài)字典上下文有關(guān)，需要為每個(gè) HTTP/2 連接維護(hù)不同的字典。在傳輸過(guò)程中使用，使用字符代替鍵值對(duì)大大減少傳輸?shù)臄?shù)據(jù)量。

區(qū)別三：HTTP2支持服務(wù)器推送

服務(wù)端推送是一種在客戶端請(qǐng)求之前發(fā)送數(shù)據(jù)的機(jī)制。當(dāng)代網(wǎng)頁(yè)使用了許多資源:HTML、樣式表、腳本、圖片等等。在HTTP/1.x中這些資源每一個(gè)都必須明確地請(qǐng)求。這可能是一個(gè)很慢的過(guò)程。瀏覽器從獲取HTML開始，然后在它解析和評(píng)估頁(yè)面的時(shí)候，增量地獲取更多的資源。因?yàn)榉?wù)器必須等待瀏覽器做每一個(gè)請(qǐng)求，網(wǎng)絡(luò)經(jīng)常是空閑的和未充分使用的。

為了改善延遲，HTTP/2引入了server push，它允許服務(wù)端推送資源給瀏覽器，在瀏覽器明確地請(qǐng)求之前。一個(gè)服務(wù)器經(jīng)常知道一個(gè)頁(yè)面需要很多附加資源，在它響應(yīng)瀏覽器第一個(gè)請(qǐng)求的時(shí)候，可以開始推送這些資源。這允許服務(wù)端去完全充分地利用一個(gè)可能空閑的網(wǎng)絡(luò)，改善頁(yè)面加載時(shí)間。