[[332931]]

 1 前言

今天一起來(lái)研究Http協(xié)議的一些事情，通過(guò)本文你將了解到以下內(nèi)容：

• Http協(xié)議各版本的對(duì)比和優(yōu)缺點(diǎn)
• Http2.0協(xié)議相關(guān)的SPDY協(xié)議、二進(jìn)制分幀協(xié)議、多路復(fù)用、首部壓縮、服務(wù)推送等基本原理

乘風(fēng)破浪前往知識(shí)的海洋吧， 大白船長(zhǎng) 要開(kāi)船了!

2. Http協(xié)議各版本的對(duì)比

Http超文本傳輸協(xié)議同空氣一般， 感觸不到它的存在但是又無(wú)處不在 ，筆者從維基百科摘錄了一些Http協(xié)議的發(fā)展歷程的簡(jiǎn)單信息，一起來(lái)看下吧：

超文本傳輸協(xié)議是 分布式協(xié)作超媒體信息系統(tǒng)的應(yīng)用協(xié)議 。超文本傳輸協(xié)議是萬(wàn)維網(wǎng)數(shù)據(jù)通信的基礎(chǔ)，在萬(wàn)維網(wǎng)中超文本文檔包括到用戶可以輕松訪問(wèn)的其他資源的超鏈接。

蒂姆·伯納斯·李于1989年在歐洲核子研究中心發(fā)起了超文本傳輸協(xié)議的開(kāi)發(fā)。早期的超文本傳輸協(xié)議征求意見(jiàn)(RFCs)的開(kāi)發(fā)是由互聯(lián)網(wǎng)工程任務(wù)組(IETF)和萬(wàn)維網(wǎng)聯(lián)盟(W3C)共同努力的結(jié)果，其工作后來(lái)轉(zhuǎn)移到IETF。

萬(wàn)維網(wǎng)之父蒂姆·伯納斯·李簡(jiǎn)介

Tim Berners-Lee是英國(guó)工程師和計(jì)算機(jī)科學(xué)家，最著名的是萬(wàn)維網(wǎng)的發(fā)明者。他是 牛津大學(xué)計(jì)算機(jī)科學(xué)教授和麻省理工學(xué)院教授 。

他于1989年3月12日提出了一種信息管理系統(tǒng)，然后在同年11月中旬通過(guò)Internet實(shí)現(xiàn)了超文本傳輸協(xié)議HTTP客戶端和服務(wù)器之間的 首次成功通信 。

他是萬(wàn)維網(wǎng)聯(lián)盟W3C的負(fù)責(zé)人，該聯(lián)盟負(fù)責(zé)監(jiān)督Web的持續(xù)發(fā)展，他還是 萬(wàn)維網(wǎng)基金會(huì)的創(chuàng)始人 ，還是麻省理工學(xué)院計(jì)算機(jī)科學(xué)和人工智能實(shí)驗(yàn)室CSAIL的3Com創(chuàng)始人主席和高級(jí)研究員，他也是網(wǎng)絡(luò)科學(xué)研究計(jì)劃WSRI的主任和MIT集體智慧中心的顧問(wèn)委員會(huì)成員，他也是開(kāi)放數(shù)據(jù)研究所的 創(chuàng)始人兼總裁 ，目前是社交網(wǎng)絡(luò)MeWe的顧問(wèn)。

2004年，伯納斯·李因其開(kāi)創(chuàng)性工作而被女王伊麗莎白二世 封為爵士 。在2009年4月，他當(dāng)選為 美國(guó)國(guó)家科學(xué)院外籍研究員 ，位列《時(shí)代》雜志的 20世紀(jì)100位最重要人物 名單被譽(yù)為“萬(wàn)維網(wǎng)發(fā)明者”獲得了2016年 圖靈獎(jiǎng) 。

http各個(gè)版本的基本情況

http協(xié)議經(jīng)過(guò)20多年的演進(jìn)出現(xiàn)過(guò) 0.9、1.0、1.1、2.0、3.0 五個(gè)主要版本，筆者畫(huà)了張圖看下：

A.Http0.9版本

0.9是鼻祖版本，它的主要特點(diǎn)包括：

• 請(qǐng)求方法支持有限只支持GET請(qǐng)求方式，不支持其他請(qǐng)求方式 因此客戶端向服務(wù)端傳輸信息的量非常有限，也就是現(xiàn)在常用的Post請(qǐng)求無(wú)法使用
• 不支持請(qǐng)求頭header不能在請(qǐng)求中指定版本號(hào)，服務(wù)端只具有返回HTML字符串的能力
• 響應(yīng)即關(guān)閉服務(wù)端相響應(yīng)之后，立即關(guān)閉TCP連接

B.Http1.0版本

1.0版本主要是對(duì)0.9版本的強(qiáng)化，效果也比較明顯，主要特性和缺點(diǎn)包括：

• 豐富請(qǐng)求方法請(qǐng)求方式新增了POST，DELETE，PUT，HEADER等方式，提高了客戶端向服務(wù)端發(fā)送信息的量級(jí)
• 增加請(qǐng)求頭和響應(yīng)頭增添了請(qǐng)求頭和響應(yīng)頭的概念，可以在通信中指定了HTTP協(xié)議版本號(hào)，以及其他header信息，使得C/S交互更加靈活方便
• 豐富數(shù)據(jù)傳輸內(nèi)容擴(kuò)充了傳輸內(nèi)容格式包括： 圖片、音視頻資源、二進(jìn)制 等都可以進(jìn)行傳輸，相比0.9的只能傳輸html內(nèi)容讓http的應(yīng)用場(chǎng)景更多
• 鏈接復(fù)用性差1.0版本中每個(gè)TCP連接只能發(fā)送一個(gè)請(qǐng)求，數(shù)據(jù)發(fā)送完畢連接就關(guān)閉，如果還要請(qǐng)求其他資源，就必須重新建立連接。TCP為了保證正確性和可靠性需要客戶端和服務(wù)器三次握手和四次揮手，因此建立連接成本很高，基于擁塞控制開(kāi)始時(shí)發(fā)送速率較慢，所以1.0版本的 性能并不理想 。
• 無(wú)狀態(tài)無(wú)連接的弊端1.0版本是 無(wú)狀態(tài)且無(wú)連接 的，換句話說(shuō)就是服務(wù)器不跟蹤不記錄請(qǐng)求過(guò)的狀態(tài)，客戶端每次請(qǐng)求都需要建立tcp連接不能復(fù)用，并且1.0規(guī)定在前一個(gè)請(qǐng)求響應(yīng)到達(dá)之后下一個(gè)請(qǐng)求才能發(fā)送，如果前一個(gè)阻塞后面的請(qǐng)求就會(huì)被阻塞。 丟包和亂序問(wèn)題 和高成本的鏈接過(guò)程讓復(fù)用和 隊(duì)頭阻塞 產(chǎn)生很多問(wèn)題，所以 無(wú)連接無(wú)狀態(tài) 是1.0版本的一個(gè) 弱肋 。

C.Http1.1版本

1.1版本在1.0版本發(fā)布后大約1年就推出了，是 對(duì)1.0版本的優(yōu)化和完善 ，1.1版本的主要特點(diǎn)包括：

• 增加長(zhǎng)連接新增Connection字段，可以設(shè)置keep-alive值保持連接不斷開(kāi)，即 TCP 連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用，這也是1.1版本很重要的優(yōu)化，但是在S端服務(wù)器只有處理完一個(gè)回應(yīng)，才會(huì)進(jìn)行下一個(gè)回應(yīng)。要是前面的回應(yīng)特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著，仍然存在隊(duì)頭阻塞問(wèn)題。
• 管道化在長(zhǎng)連接的基礎(chǔ)上，管道化可以不等第一個(gè)請(qǐng)求響應(yīng)繼續(xù)發(fā)送后面的請(qǐng)求，但響應(yīng)的順序還是按照請(qǐng)求的順序返回，即在同一個(gè)TCP連接中，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求，進(jìn)一步改進(jìn)了HTTP協(xié)議的傳輸效率。
• 更多的請(qǐng)求方法增加了 PUT、PATCH、OPTIONS、DELETE 等請(qǐng)求方式。
• host字段Host字段用來(lái)指定服務(wù)器的域名，這樣就可以將多種請(qǐng)求發(fā)往同一臺(tái)服務(wù)器上的不同網(wǎng)站，提高了機(jī)器的復(fù)用，這個(gè)也是重要的優(yōu)化

D.Http2.0版本

2.0版本是個(gè)里程碑式的版本，相比1.x版本有了非常多的優(yōu)化去適應(yīng)當(dāng)前的網(wǎng)絡(luò)場(chǎng)景，其中幾個(gè)重要功能點(diǎn)包括：

• 二進(jìn)制格式1.x是文本協(xié)議，然而2.0是以二進(jìn)制幀為基本單位，可以說(shuō)是一個(gè)二進(jìn)制協(xié)議，將所有傳輸?shù)男畔⒎指顬橄⒑蛶⒉捎枚M(jìn)制格式的編碼，一幀中包含數(shù)據(jù)和標(biāo)識(shí)符，使得網(wǎng)絡(luò)傳輸變得高效而靈活。
• 多路復(fù)用這是一個(gè)非常重要的改進(jìn)，1.x中建立多個(gè)連接的消耗以及效率都存在問(wèn)題，2.0版本的多路復(fù)用多個(gè)請(qǐng)求共用一個(gè)連接，多個(gè)請(qǐng)求可以同時(shí)在一個(gè)TCP連接上并發(fā)，主要借助于二進(jìn)制幀中的標(biāo)識(shí)進(jìn)行區(qū)分實(shí)現(xiàn)鏈路的復(fù)用。
• 頭部壓縮2.0版本使用使用HPACK算法對(duì)頭部header數(shù)據(jù)進(jìn)行壓縮，從而減少請(qǐng)求的大小提高效率，這個(gè)非常好理解，之前每次發(fā)送都要帶相同的header，顯得很冗余，2.0版本對(duì)頭部信息進(jìn)行增量更新有效減少了頭部數(shù)據(jù)的傳輸。
• 服務(wù)端推送這個(gè)功能有點(diǎn)意思，之前1.x版本服務(wù)端都是收到請(qǐng)求后被動(dòng)執(zhí)行，在2.0版本允許服務(wù)器主動(dòng)向客戶端發(fā)送資源，這樣在客戶端可以起到加速的作用。

3 Http2.0 詳解

前面對(duì)比了幾個(gè)版本的演進(jìn)和優(yōu)化過(guò)程，接下來(lái)深入研究下2.0版本的一些特性及其基本實(shí)現(xiàn)原理。

從對(duì)比來(lái)看2.0版本并不是在1.1版本上的一些 優(yōu)化而是革新 ，因?yàn)?.0背負(fù)了更多的 性能目標(biāo)任務(wù) ，1.1雖然增加了長(zhǎng)連接和管道化，但是從根本上并沒(méi)有實(shí)現(xiàn)真正的高性能。

2.0的設(shè)計(jì)目標(biāo)是在 兼容1.x語(yǔ)義和操作 的基礎(chǔ)上，給用戶帶來(lái) 更快捷、更簡(jiǎn)單、更安全 的體驗(yàn)高效地利用當(dāng)前的網(wǎng)絡(luò)帶寬，為此2.0做了很多調(diào)整主要包括： 二進(jìn)制化分幀、多路復(fù)用、頭部壓縮 等。

akamai做了http2.0和http1.1在加載過(guò)程中的對(duì)比效果( 實(shí)驗(yàn)中加載379個(gè)小片段 在筆者的電腦上的加載時(shí)間是0.99s VS 5.80s )：

https://http2.akamai.com/demo

3.1 SPDY協(xié)議

要說(shuō)2.0版本標(biāo)準(zhǔn)和新特性就必須提谷歌的 SPDY協(xié)議 ，看一下百度百科:

SPDY是Google開(kāi)發(fā)的基于TCP的會(huì)話層協(xié)議，用以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗(yàn)。SPDY并不是一種用于替代HTTP的協(xié)議，而是對(duì)HTTP協(xié)議的增強(qiáng)。

新協(xié)議的功能包括 數(shù)據(jù)流的多路復(fù)用、請(qǐng)求優(yōu)先級(jí)以及HTTP報(bào)頭壓縮 。谷歌表示引入SPDY協(xié)議后，在實(shí)驗(yàn)室測(cè)試中頁(yè)面加載速度比原先快64%。

隨后SPDY協(xié)議得到 Chrome、Firefox 等大型瀏覽器的支持，在一些大型網(wǎng)站和小型網(wǎng)站種部署，這個(gè)高效的協(xié)議引起了 HTTP工作組 的注意，在 此基礎(chǔ)上制定了官方Http2.0標(biāo)準(zhǔn) 。

之后幾年SPDY和Http2.0繼續(xù)演進(jìn)相互促進(jìn)，Http2.0讓服務(wù)器、瀏覽器和網(wǎng)站開(kāi)發(fā)者在新協(xié)議中獲得更好的體驗(yàn)，很快被大眾所認(rèn)可。

3.2 二進(jìn)制分幀層

二進(jìn)制分幀層 binary framing layer 在不修改請(qǐng)求方法和語(yǔ)義的基礎(chǔ)上，重新設(shè)計(jì)了 編碼機(jī)制 ，如圖為http2.0分層結(jié)構(gòu)( 圖片來(lái)自參考4 )：

二進(jìn)制編碼機(jī)制使得通信可以在 單個(gè)TCP連接 上進(jìn)行，該連接在整個(gè)對(duì)話期間一直處于活躍狀態(tài)。

二進(jìn)制協(xié)議將通信 數(shù)據(jù)分解為更小的幀 ，數(shù)據(jù)幀充斥在C/S之間的雙向數(shù)據(jù)流中，就像雙向多車道的高速路，來(lái)往如織川流不息：

要理解二進(jìn)制分幀層需要知道四個(gè)概念：

• 鏈接Link就是指一條C/S之間的TCP鏈接，這是個(gè)基礎(chǔ)的鏈路數(shù)據(jù)的高速公路
• 數(shù)據(jù)流Stream已建立的TCP連接內(nèi)的雙向字節(jié)流，TCP鏈接中可以承載一條或多條消息
• 消息Message消息屬于一個(gè)數(shù)據(jù)流，消息就是邏輯請(qǐng)求或響應(yīng)消息對(duì)應(yīng)的完整的一系列幀，也就是幀組成了消息
• 幀F(xiàn)rame幀是通信的最小單位，每個(gè)幀都包含幀頭和消息體，標(biāo)識(shí)出當(dāng)前幀所屬的數(shù)據(jù)流

四者是 一對(duì)多的 包含 關(guān)系，筆者畫(huà)了一張圖：

再來(lái)看一下HeadersFrame頭部幀的結(jié)構(gòu)：

再來(lái)看一下HeadersFrame頭部幀的結(jié)構(gòu)：從各個(gè)域可以看到長(zhǎng)度、類型、標(biāo)志位、 流標(biāo)識(shí)符、 數(shù)據(jù)凈荷等，感興趣可以閱讀rfc7540相關(guān)文檔。

https://httpwg.org/specs/rfc7540.html 

總之 2.0版本將通信數(shù)據(jù)分解為二進(jìn)制編碼幀進(jìn)行交換，每個(gè)幀對(duì)應(yīng)著特定數(shù)據(jù)流中的特定消息，所有幀和流都在一個(gè)TCP連接內(nèi)復(fù)用，二進(jìn)制分幀協(xié)議是2.0其他功能和性能優(yōu)化的重要基礎(chǔ)。

3.3 多路復(fù)用

1.1版本中存在 隊(duì)首阻塞問(wèn)題 ，因此如果客戶端要發(fā)起多個(gè)并行請(qǐng)求來(lái)提升性能，必須使用 多個(gè)TCP連接 ，這樣就要承受 更大延時(shí)和建鏈拆鏈成本 ，不能有效利用TCP鏈接。

由于2.0版本中使用新的二進(jìn)制分幀協(xié)議突破了1.0的諸多限制，從根本上實(shí)現(xiàn)了真正的 請(qǐng)求和響應(yīng)多路復(fù)用 。

客戶端和服務(wù)器將交互數(shù)據(jù)分解為 相互獨(dú)立的幀 ，互不影響地 交錯(cuò)傳輸 ，最后再在對(duì)端根據(jù) 幀頭中的流標(biāo)識(shí)符 把它們 重新組裝 起來(lái)，從而實(shí)現(xiàn)了TCP鏈接的多路復(fù)用。

如圖展示了2.0版本的基于幀的消息通信過(guò)程 ( 圖片來(lái)自參考4 ) ：

3.4 首部壓縮

A.Header冗余傳輸

我們都知道http請(qǐng)求都有header部分，每個(gè)包都有并且相對(duì)于一條鏈接而言 大部分的包的header部分都是相同 的，這樣的話每次傳輸相同的部分確實(shí) 非常浪費(fèi) 。

現(xiàn)代網(wǎng)絡(luò)中每個(gè)網(wǎng)頁(yè)平均包含100多個(gè)http請(qǐng)求，每個(gè)請(qǐng)求頭平均有300-500字節(jié)，總數(shù)據(jù)量達(dá)到幾十KB以上，這樣可能造成數(shù)據(jù)延時(shí)，尤其復(fù)雜 的WiFi環(huán)境或者蜂窩網(wǎng)絡(luò) ，這樣只能看到手機(jī)在轉(zhuǎn)圈，但是這些請(qǐng)求頭之間通常幾乎沒(méi)有變化，在本已經(jīng)擁擠的鏈路中多次傳輸相同的數(shù)據(jù)部分確實(shí)不是高效做法。

基于TCP設(shè)計(jì)的 擁塞控制 具有 線增積減AIMD特性 ，如果發(fā)生丟包那么傳輸速率將大幅度下降，這樣在擁擠的網(wǎng)絡(luò)環(huán)境中大的包頭意味著只能 加劇擁塞控制造成的低速率傳輸 。

B.Http壓縮和犯罪攻擊

在2.0版本的HPACK算法之前，http壓縮使用gzip去壓縮，后來(lái)提出的SPDY算法對(duì)Headers進(jìn)行特殊設(shè)計(jì)，但是它依舊使用的是 DEFLATE算法 。

在后面的一些實(shí)際應(yīng)用中發(fā)現(xiàn) DEFLATE和SPDY都有被攻擊的危險(xiǎn) ，因?yàn)镈EFLATE算法使用后向 字符串匹配和動(dòng)態(tài)Huffman編碼 ，攻擊者可以控制部分請(qǐng)求頭部通過(guò)修改請(qǐng)求部分然后看壓縮之后大小改變多少，如果變小了攻擊者就知道注入的文本和請(qǐng)求中的某些內(nèi)容有重復(fù)。

這個(gè)過(guò)程有點(diǎn)像 俄羅斯方塊的消除過(guò)程 ，這樣經(jīng)過(guò)一段時(shí)間的嘗試數(shù)據(jù)內(nèi)容就可能被全部搞清楚，由于這種風(fēng)險(xiǎn)的存在才研發(fā)出更安全的壓縮算法。

C.HPACK算法

2.0版本中HPACK算法在C/S中使用 首部表 來(lái)存儲(chǔ)之前發(fā)送的鍵值對(duì)，對(duì)于相同的數(shù)據(jù)通信期間幾乎不會(huì)改變的通用鍵值對(duì)只需發(fā)送一次即可。

極端情況如果請(qǐng)求頭每次沒(méi)有變化，那么傳輸中則不包含首部，也就是首部開(kāi)銷就是 零字節(jié)。如果首部鍵值對(duì)發(fā)生變化了，也只需要發(fā)送變化的數(shù)據(jù)，并且將 新增或修改的首部幀會(huì)被追加到首部表 ，首部表在鏈接存活期始終存在, 并且由客戶端和服務(wù)器 共同更新和維護(hù) 。

簡(jiǎn)單說(shuō)就是客戶端和服務(wù)端共同維護(hù)了一個(gè) key-value 的結(jié)構(gòu)，發(fā)生變化時(shí)則更新傳輸，否則就不傳輸，這樣相當(dāng)于 首次全量傳輸之后增量更新傳輸 即可，這個(gè)思想在日常開(kāi)發(fā)中也非常普遍，不用想的太復(fù)雜。

如圖展示了首部表的更新過(guò)程 ( 圖片來(lái)自參考4 ) ：

hpack算法的相關(guān)文檔：

https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12 

3.5 服務(wù)端推送

服務(wù)端推送是2.0版本新增的一個(gè)強(qiáng)大功能，和一般的 一問(wèn)一答 式的C/S交互不同， 推送式交互中服務(wù)器可以對(duì)客戶端的一個(gè)請(qǐng)求發(fā)送多個(gè)響應(yīng) ，除了對(duì)最初請(qǐng)求的響應(yīng)外還向客戶端推送額外資源，無(wú)需客戶端明確地請(qǐng)求也可以推送。

舉個(gè)栗子：

想象一下你去餐廳吃飯，服務(wù)好的快餐廳在你點(diǎn)好一份牛肉面之后，還會(huì)給你送上餐巾紙、筷子、勺子甚至調(diào)料等，這樣主動(dòng)式的服務(wù)，節(jié)約了客人的時(shí)間并且提高了用餐體驗(yàn)。

在實(shí)際的C/S交互中這種 主動(dòng)推送額外資源 的方法很有效，因?yàn)閹缀趺總€(gè)網(wǎng)絡(luò)應(yīng)用都會(huì)包含多種資源，客戶端需要全部逐個(gè)獲取它們，此時(shí)如果讓服務(wù)器提前推送這些資源，從而可以 有效減少額外的延遲時(shí) 間 ，因?yàn)榉?wù)器可以知道客戶端下一步要請(qǐng)求什么資源。

如圖為服務(wù)端推送的簡(jiǎn)單過(guò)程 ( 圖片來(lái)自參考4 ) ：

4. 總結(jié)

本文通過(guò)介紹Http協(xié)議的歷史演進(jìn)、各個(gè)版本的主要特征和優(yōu)缺點(diǎn)、重點(diǎn)介紹了Http2.0協(xié)議的一些特性，包括： SPDY協(xié)議、二進(jìn)制分幀協(xié)議、多路復(fù)用、首部壓縮、服務(wù)端推送 等重要功能， 篇幅有限不能展開(kāi)太多 。

雖然http2.0版本協(xié)議有很多非常優(yōu)秀的功能并且在 2015年正式發(fā)布 ，現(xiàn)在國(guó)內(nèi)外一些大廠基本都有使用http2.0承擔(dān)部分請(qǐng)求，但是目前仍 然未廣泛普及 。

目前http3.0版本在2018年也推出來(lái)了，至于http2.0和http3.0的推廣和普及是需要時(shí)間的，但是堅(jiān)信我們的網(wǎng)絡(luò)可以 更安全、更快捷、更節(jié)約 。