1 前言

前面寫了10多篇關於Redis底層實現、工程架構、實際應用的文章，感興趣的讀者可以進行閱讀，如有問題歡迎交流：

1.Redis面試熱點之底層實現篇-1
2.Redis面試熱點之底層實現篇-2
3.Redis面試熱點之工程架構篇-1
4.Redis面試熱點之工程架構篇-2
5.基於Redis的分散式鎖和Redlock演算法
6.淺談叢集版Redis和Gossip協議
7.理解Redis的反應堆模式
8.理解Redis單執行緒執行模式
9.淺析Redis 4.0新特性之LazyFree
10.理解Redis持久化
11.深入理解跳錶在Redis中的應用

接下來本號將推出TCP/IP協議棧相關的系列文章，TCP/IP協議棧是Linux核心中非常重要的部分，無論怎麼寫都不能事無鉅細面面俱到，因此本號仍然只能挑選一些熱門或小眾但有趣的話題來展開。

今天一起來研究Http協議的一些事情，通過本文你將瞭解到以下內容：

1. Http協議各版本的對比和優缺點
2. Http2.0協議相關的SPDY協議、二進位制分幀協議、多路複用、首部壓縮、服務推送等基本原理

乘風破浪前往知識的海洋吧，大白船長要開船了！

2. Http協議各版本的對比

Http超文字傳輸協議同空氣一般，感觸不到它的存在但是又無處不在，筆者從維基百科摘錄了一些Http協議的發展歷程的簡單資訊，一起來看下吧：

超文字傳輸協議是分散式協作超媒體資訊系統的應用協議。超文字傳輸協議是全球資訊網資料通訊的基礎，在全球資訊網中超文字文件包括到使用者可以輕鬆訪問的其他資源的超連結。
蒂姆·伯納斯·李於1989年在歐洲核子研究中心發起了超文字傳輸協議的開發。早期的超文字傳輸協議徵求意見(RFCs)的開發是由網際網路工程任務組(IETF)和全球資訊網聯盟(W3C)共同努力的結果，其工作後來轉移到IETF。

全球資訊網之父蒂姆·伯納斯·李簡介

Tim Berners-Lee是英國工程師和電腦科學家，最著名的是全球資訊網的發明者。他是牛津大學電腦科學教授和麻省理工學院教授。
他於1989年3月12日提出了一種資訊管理系統，然後在同年11月中旬通過Internet實現了超文字傳輸協議HTTP客戶端和伺服器之間的首次成功通訊。
他是全球資訊網聯盟W3C的負責人，該聯盟負責監督Web的持續發展，他還是全球資訊網基金會的創始人，還是麻省理工學院電腦科學和人工智慧實驗室CSAIL的3Com創始人主席和高階研究員，他也是網路科學研究計劃WSRI的主任和MIT集體智慧中心的顧問委員會成員，他也是開放資料研究所的創始人兼總裁，目前是社交網路MeWe的顧問。
2004年，伯納斯·李因其開創性工作而被女王伊麗莎白二世封為爵士。在2009年4月，他當選為美國國家科學院外籍研究員，位列《時代》雜誌的20世紀100位最重要人物名單被譽為“全球資訊網發明者”獲得了2016年圖靈獎。

http各個版本的基本情況

http協議經過20多年的演進出現過0.9、1.0、1.1、2.0、3.0五個主要版本，畫張圖看下：

A.Http0.9版本
0.9是鼻祖版本，它的主要特點包括：

1. 請求方法支援有限
   只支援GET請求方式，不支援其他請求方式 因此客戶端向服務端傳輸資訊的量非常有限，也就是現在常用的Post請求無法使用
2. 不支援請求頭header
   不能在請求中指定版本號，服務端只具有返回HTML字串的能力
3. 響應即關閉
   服務端相響應之後，立即關閉TCP連線

B.Http1.0版本

1.0版本主要是對0.9版本的強化，效果也比較明顯，主要特性和缺點包括：

1. 豐富請求方法
   請求方式新增了POST，DELETE，PUT，HEADER等方式，提高了客戶端向服務端傳送資訊的量級
2. 增加請求頭和響應頭
   增添了請求頭和響應頭的概念，可以在通訊中指定了HTTP協議版本號，以及其他header資訊，使得C/S互動更加靈活方便
3. 豐富資料傳輸內容
   擴充了傳輸內容格式包括：圖片、音視訊資源、二進位制等都可以進行傳輸，相比0.9的只能傳輸html內容讓http的應用場景更多
4. 連結複用性差
   1.0版本中每個TCP連線只能傳送一個請求，資料傳送完畢連線就關閉，如果還要請求其他資源，就必須重新建立連線。TCP為了保證正確性和可靠性需要客戶端和伺服器三次握手和四次揮手，因此建立連線成本很高，基於擁塞控制開始時傳送速率較慢，所以1.0版本的效能並不理想。
5. 無狀態無連線的弊端
   1.0版本是無狀態且無連線的，換句話說就是伺服器不跟蹤不記錄請求過的狀態，客戶端每次請求都需要建立tcp連線不能複用，並且1.0規定在前一個請求響應到達之後下一個請求才能傳送，如果前一個阻塞後面的請求就會被阻塞。 丟包和亂序問題和高成本的連結過程讓複用和隊頭阻塞產生很多問題，所以無連線無狀態是1.0版本的一個弱肋。

C.Http1.1版本
1.1版本在1.0版本釋出後大約1年就推出了，是對1.0版本的優化和完善，1.1版本的主要特點包括：

1. 增加長連線
   新增Connection欄位，可以設定keep-alive值保持連線不斷開，即 TCP 連線預設不關閉，可以被多個請求複用，這也是1.1版本很重要的優化，但是在S端伺服器只有處理完一個迴應，才會進行下一個迴應。要是前面的迴應特別慢，後面就會有許多請求排隊等著，仍然存在隊頭阻塞問題。
2. 管道化
   在長連線的基礎上，管道化可以不等第一個請求響應繼續傳送後面的請求，但響應的順序還是按照請求的順序返回，即在同一個TCP連線中，客戶端可以同時傳送多個請求，進一步改進了HTTP協議的傳輸效率。
3. 更多的請求方法
   增加了 PUT、PATCH、OPTIONS、DELETE 等請求方式。
4. host欄位
   Host欄位用來指定伺服器的域名，這樣就可以將多種請求發往同一臺伺服器上的不同網站，提高了機器的複用，這個也是重要的優化

D.Http2.0版本
2.0版本是個里程碑式的版本，相比1.x版本有了非常多的優化去適應當前的網路場景，其中幾個重要功能點包括：

1. 二進位制格式
   1.x是文字協議，然而2.0是以二進位制幀為基本單位，可以說是一個二進位制協議，將所有傳輸的資訊分割為訊息和幀，並採用二進位制格式的編碼，一幀中包含資料和識別符號，使得網路傳輸變得高效而靈活。
2. 多路複用
   這是一個非常重要的改進，1.x中建立多個連線的消耗以及效率都存在問題，2.0版本的多路複用多個請求共用一個連線，多個請求可以同時在一個TCP連線上併發，主要藉助於二進位制幀中的標識進行區分實現鏈路的複用。
3. 頭部壓縮
   2.0版本使用使用HPACK演算法對頭部header資料進行壓縮，從而減少請求的大小提高效率，這個非常好理解，之前每次傳送都要帶相同的header，顯得很冗餘，2.0版本對頭部資訊進行增量更新有效減少了頭部資料的傳輸。
4. 服務端推送
   這個功能有點意思，之前1.x版本服務端都是收到請求後被動執行，在2.0版本允許伺服器主動向客戶端傳送資源，這樣在客戶端可以起到加速的作用。

3 Http2.0 詳解

前面對比了幾個版本的演進和優化過程，接下來深入研究下2.0版本的一些特性及其基本實現原理。

從對比來看2.0版本並不是在1.1版本上的一些優化而是革新，因為2.0揹負了更多的效能目標任務，1.1雖然增加了長連線和管道化，但是從根本上並沒有實現真正的高效能。

2.0的設計目標是在相容1.x語義和操作的基礎上，給使用者帶來更快捷、更簡單、更安全的體驗高效地利用當前的網路頻寬，為此2.0做了很多調整主要包括：二進位制化分幀、多路複用、頭部壓縮等。

akamai做了http2.0和http1.1在載入過程中的對比效果(實驗中載入379個小片段 在筆者的電腦上的載入時間是0.99s VS 5.80s)：

https://http2.akamai.com/demo

3.1 SPDY協議

要說2.0版本標準和新特性就必須提谷歌的SPDY協議，看一下百度百科:

SPDY是Google開發的基於TCP的會話層協議，用以最小化網路延遲，提升網路速度，優化使用者的網路使用體驗。SPDY並不是一種用於替代HTTP的協議，而是對HTTP協議的增強。
新協議的功能包括資料流的多路複用、請求優先順序以及HTTP報頭壓縮。谷歌表示引入SPDY協議後，在實驗室測試中頁面載入速度比原先快64%。

隨後SPDY協議得到Chrome、Firefox等大型瀏覽器的支援，在一些大型網站和小型網站種部署，這個高效的協議引起了HTTP工作組的注意，在此基礎上制定了官方Http2.0標準。

之後幾年SPDY和Http2.0繼續演進相互促進，Http2.0讓伺服器、瀏覽器和網站開發者在新協議中獲得更好的體驗，很快被大眾所認可。

3.2 二進位制分幀層

二進位制分幀層binary framing layer在不修改請求方法和語義的基礎上，重新設計了編碼機制，如圖為http2.0分層結構(圖片來自參考4)：

二進位制編碼機制使得通訊可以在單個TCP連線上進行，該連線在整個對話期間一直處於活躍狀態。

二進位制協議將通訊資料分解為更小的幀，資料幀充斥在C/S之間的雙向資料流中，就像雙向多車道的高速路，來往如織川流不息：

要理解二進位制分幀層需要知道四個概念：

1. 連結Link
   就是指一條C/S之間的TCP連結，這是個基礎的鏈路資料的高速公路
2. 資料流Stream
   已建立的TCP連線內的雙向位元組流，TCP連結中可以承載一條或多條訊息
3. 訊息Message
   訊息屬於一個數據流，訊息就是邏輯請求或響應訊息對應的完整的一系列幀，也就是幀組成了訊息
4. 幀Frame
   幀是通訊的最小單位，每個幀都包含幀頭和訊息體，標識出當前幀所屬的資料流

四者是一對多的包含關係，筆者畫了一張圖：

再來看一下HeadersFrame頭部幀的結構：

再來看一下HeadersFrame頭部幀的結構：從各個域可以看到長度、型別、標誌位、流識別符號、資料淨荷等，感興趣可以閱讀rfc7540相關文件。

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

總之2.0版本將通訊資料分解為二進位制編碼幀進行交換，每個幀對應著特定資料流中的特定訊息，所有幀和流都在一個TCP連線內複用，二進位制分幀協議是2.0其他功能和效能優化的重要基礎。

3.3 多路複用

1.1版本中存在隊首阻塞問題，因此如果客戶端要發起多個並行請求來提升效能，必須使用多個TCP連線，這樣就要承受更大延時和建鏈拆鏈成本，不能有效利用TCP連結。

由於2.0版本中使用新的二進位制分幀協議突破了1.0的諸多限制，從根本上實現了真正的請求和響應多路複用。

客戶端和伺服器將互動資料分解為相互獨立的幀，互不影響地交錯傳輸，最後再在對端根據幀頭中的流識別符號把它們重新組裝起來，從而實現了TCP連結的多路複用。

如圖展示了2.0版本的基於幀的訊息通訊過程(圖片來自參考4)：

3.4 首部壓縮

A.Header冗餘傳輸

我們都知道http請求都有header部分，每個包都有並且相對於一條連結而言大部分的包的header部分都是相同的，這樣的話每次傳輸相同的部分確實非常浪費。

現代網路中每個網頁平均包含100多個http請求，每個請求頭平均有300-500位元組，總資料量達到幾十KB以上，這樣可能造成資料延時，尤其複雜的WiFi環境或者蜂窩網路，這樣只能看到手機在轉圈，但是這些請求頭之間通常幾乎沒有變化，在本已經擁擠的鏈路中多次傳輸相同的資料部分確實不是高效做法。
基於TCP設計的擁塞控制具有線增積減AIMD特性，如果發生丟包那麼傳輸速率將大幅度下降，這樣在擁擠的網路環境中大的包頭意味著只能加劇擁塞控制造成的低速率傳輸。

B.Http壓縮和犯罪攻擊

在2.0版本的HPACK演算法之前，http壓縮使用gzip去壓縮，後來提出的SPDY演算法對Headers進行特殊設計，但是它依舊使用的是DEFLATE演算法。

在後面的一些實際應用中發現DEFLATE和SPDY都有被攻擊的危險，因為DEFLATE演算法使用後向字串匹配和動態Huffman編碼，攻擊者可以控制部分請求頭部通過修改請求部分然後看壓縮之後大小改變多少，如果變小了攻擊者就知道注入的文字和請求中的某些內容有重複。

這個過程有點像俄羅斯方塊的消除過程，這樣經過一段時間的嘗試資料內容就可能被全部搞清楚，由於這種風險的存在才研發出更安全的壓縮演算法。

C.HPACK演算法

2.0版本中HPACK演算法在C/S中使用首部表來儲存之前傳送的鍵值對，對於相同的資料通訊期間幾乎不會改變的通用鍵值對只需傳送一次即可。

極端情況如果請求頭每次沒有變化，那麼傳輸中則不包含首部，也就是首部開銷就是零位元組。如果首部鍵值對發生變化了，也只需要傳送變化的資料，並且將新增或修改的首部幀會被追加到首部表，首部表在連結存活期始終存在, 並且由客戶端和伺服器共同更新和維護。

簡單說就是客戶端和服務端共同維護了一個key-value的結構，發生變化時則更新傳輸，否則就不傳輸，這樣相當於首次全量傳輸之後增量更新傳輸即可，這個思想在日常開發中也非常普遍，不用想的太複雜。

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

hpack演算法的相關文件：https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12

3.5 服務端推送

服務端推送是2.0版本新增的一個強大功能，和一般的一問一答式的C/S互動不同，推送式互動中伺服器可以對客戶端的一個請求傳送多個響應，除了對最初請求的響應外還向客戶端推送額外資源，無需客戶端明確地請求也可以推送。

舉個栗子：
想象一下你去餐廳吃飯，服務好的快餐廳在你點好一份牛肉麵之後，還會給你送上餐巾紙、筷子、勺子甚至調料等，這樣主動式的服務，節約了客人的時間並且提高了用餐體驗。

在實際的C/S互動中這種主動推送額外資源的方法很有效，因為幾乎每個網路應用都會包含多種資源，客戶端需要全部逐個獲取它們，此時如果讓伺服器提前推送這些資源，從而可以有效減少額外的延遲時間，因為伺服器可以知道客戶端下一步要請求什麼資源。

如圖為服務端推送的簡單過程(圖片來自參考4)：

4. 總結

本文通過介紹Http協議的歷史演進、各個版本的主要特徵和優缺點、重點介紹了Http2.0協議的一些特性，包括：SPDY協議、二進位制分幀協議、多路複用、首部壓縮、服務端推送等重要功能，篇幅有限不能展開太多。

雖然http2.0版本協議有很多非常優秀的功能並且在2015年正式釋出，現在國內外一些大廠基本都有使用http2.0承擔部分請求，但是目前仍然未廣泛普及。

目前http3.0版本在2018年也推出來了，至於http2.0和http3.0的推廣和普及是需要時間的，但是堅信我們的網路可以更安全、更快捷、更節約。

本次的旅程就此結束啦，期待下一次的航行！

5.巨人的肩膀

1. 解密HTTP/2與HTTP/3 的新特性
2. 計算機網路面試（12）HTTP 各版本差異 | 海樹
3. https://www.ibm.com/developerworks/cn/web/wa-http2-under-the-hood/index.html
4. https://developers.google.com/web/fundamentals/performance/http2?hl=zh-cn
5. https://hpbn.co/primer-on-web-performance/#latency-as-a-performance-bottleneck
6. https://httpwg.org/specs/rfc7540.html
7. [譯] HPACK：http2中沉默的殺手
8. 乾貨HTTP/2.0，騙你是小狗 - 掘金

6.關於我

相關推薦