http/2.0時代已經來臨了！

知識分享  文章轉自：https://blog.csdn.net/g6U8W7p06dCO99fQ3/article/details/78906348

 

    如今是資源共享的時代，一樣也是知識分享的時代，若是你以爲本文能學到知識，請把知識與別人分享！

開篇HTTP發展的心路歷程

 

上圖：鏈接沒法複用

上圖：設置Connection:Keep-Alive，保持鏈接在一段時間內不斷開。

上圖：HTTPpipelining：創建多個鏈接

上圖：多路複用

先對HTTP協議進行簡單介紹

    1. HTTP協議 ：Hyper Text Transfer Protocol（超文本傳輸協議）,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準。

 

    2. HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。

 

    3. HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。

 

    4. HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。

 

 

HTTP 協議的版本

1. HTTP 0.9做爲HTTP協議的第一個版本。是很是弱的。請求(Request)只有一行,好比: GET www.leautolink.com

 

    2. HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上。

 

    3. HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。

 

 

HTTP 1.1 作了哪些升級：

 

• 緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

 

• 帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

 

• 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。

 

• Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。

 

• 長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

 

如何創建鏈接（三次握手）

    HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的創建鏈接，可是這些鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大。

 

• 第一次握手：創建鏈接時，客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。

• 第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

• 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP鏈接成功）狀態，完成三次握手。

 

完成三次握手，客戶端與服務器開始傳送數據。

 

 

如何關閉鏈接（四次揮手）：

 

    因爲TCP鏈接是全雙工的，所以每一個方向都必須單獨進行關閉。這個原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP鏈接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另外一方執行被動關閉。

 

     TCP的鏈接的拆除須要發送四個包，所以稱爲四次揮手(four-way handshake)。客戶端或服務器都可主動發起揮手動做，在socket編程中，任何一方執行close()操做便可產生揮手操做。

 

1. 客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送。 

2. 服務器B收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1。和SYN同樣，一個FIN將佔用一個序號。 

3. 服務器B關閉與客戶端A的鏈接，發送一個FIN給客戶端A。 

4. 客戶端A發回ACK報文確認，並將確認序號設置爲收到序號加1。 

 

 

瀏覽器阻塞（HOL blocking）：

    瀏覽器對於同一個域名，通常PC端瀏覽器會針對單個域名的server同時創建6～8個鏈接，手機端的鏈接數則通常控制在4～6個（這個根據瀏覽器內核不一樣可能會有所差別），超過瀏覽器最大鏈接數限制，後續請求就會被阻塞。

 

在講HTTP/2以前咱們先來講說SPDY

    SPDY協議是Google提出的基於傳輸控制協議(TCP)的應用層協議，經過壓縮、多路複用和優先級來縮短加載時間。該協議是一種更加快速的內容傳輸協議，於2009 年年中發佈。

 

    GoogleChrome、MozillaFirefox以及Opera已默認開啓SPDY。Google曾經稱它的測試顯示，頁面載入提升了一倍。該協議是一種更加快速的內容傳輸協議。

 

SPDY協議設定的目標

    1. 頁面加載時間（PLT，Page • Load Time）下降 50%；

    2. 無需網站做者修改任何內容；

    3. 最小化配置複雜度，無需變動網絡基礎設施；

 

注：爲了達到下降50% 頁面加載時間的目標，SPDY 引入了一個新的二進制分幀數據層，以實現多向請求和響應、優先次序、最小化及消除沒必要要的網絡延遲，目的是更有效地利用底層TCP 鏈接；

 

 

HTTP/2：SPDY的升級版

• HTTP-WG（HTTP Working Group）在2012 年初把HTTP 2.0提到了議事日程，吸收SPDY 的經驗教訓，並在此基礎上制定官方標準。

 

• HTTP/2 的主要目標是改進傳輸性能，更有效地利用網絡資源，實現低延遲和高吞吐量。從另外一方面看，HTTP 的高層協議語義並不會由於此次版本升級而受影響。全部HTTP 首部、值，以及它們的使用場景都不會變。

 

• HTTP/2 致力於突破上一代標準衆所周知的性能限制，但它也是對以前1.x 標準的擴展，而非替代。之因此要遞增一個大版本到2.0，主要是由於它改變了客戶端與服務器之間交換數據的方式

 

HTTP/2 是如何提升效率呢？

 

二進制分幀：HTTP 2.0 的全部幀都採用二進制編碼

• 幀：客戶端與服務器經過交換幀來通訊，幀是基於這個新協議通訊的最小單位。

• 消息：是指邏輯上的 HTTP 消息，好比請求、響應等，由一或多個幀組成。

• 流：流是鏈接中的一個虛擬信道，能夠承載雙向的消息；每一個流都有一個惟一的整數標識符（一、2…N）；

 

 

多路複用 (Multiplexing)

    多路複用容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息。有了新的分幀機制後，HTTP/2 再也不依賴多個TCP 鏈接去實現多流並行了。每一個數據流都拆分紅不少互不依賴的幀，而這些幀能夠交錯（亂序發送），還能夠分優先級。最後再在另外一端把它們從新組合起來。HTTP 2.0 鏈接都是持久化的，並且客戶端與服務器之間也只須要一個鏈接（每一個域名一個鏈接）便可。 

 

請求優先級

• 把HTTP 消息分解爲不少獨立的幀以後，就能夠經過優化這些幀的交錯和傳輸順序，每一個流均可以帶有一個31 比特的優先值：0 表示最高優先級；2的31次方-1 表示最低優先級。

• 服務器能夠根據流的優先級，控制資源分配（CPU、內存、帶寬），而在響應數據準備好以後，優先將最高優先級的幀發送給客戶端。

• HTTP 2.0 一舉解決了全部這些低效的問題：瀏覽器能夠在發現資源時當即分派請求，指定每一個流的優先級，讓服務器決定最優的響應次序。這樣請求就沒必要排隊了，既節省了時間，也最大限度地利用了每一個鏈接。

 

header壓縮

    HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP/2使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。

 

服務端推送

• 服務器能夠對一個客戶端請求發送多個響應。服務器向客戶端推送資源無需客戶端明確地請求。

• HTTP 2.0 鏈接後，客戶端與服務器交換SETTINGS 幀，藉此能夠限定雙向併發的流的最大數量。

• 全部推送的資源都遵照同源策略。換句話說，服務器不能隨便將第三方資源推送給客戶端，而必須是通過雙方確認才行。

• 服務器必須遵循請求- 響應的循環，只能藉着對請求的響應推送資源

 

服務器推送究竟是什麼？

    服務端推送能把客戶端所須要的資源伴隨着index.html一塊兒發送到客戶端，省去了客戶端重複請求的步驟。正由於沒有發起請求，創建鏈接等操做，因此靜態資源經過服務端推送的方式能夠極大地提高速度。

 

普通的客戶端請求過程：

 

服務端推送的過程：

 

HTTP/2的多路複用和HTTP1.1中的長鏈接複用有什麼區別？

• HTTP/1.0 一次請求-響應，創建一個鏈接，用完關閉；每個請求都要創建一個鏈接；

 

• HTTP/1.1 Pipeling解決方式爲，若干個請求排隊串行化單線程處理，後面的請求等待前面請求的返回才能得到執行機會，一旦有某請求超時等，後續請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；

 

• HTTP/2多個請求可同時在一個鏈接上並行執行。某個請求任務耗時嚴重，不會影響到其它鏈接的正常執行；

 

  

 

如何應用到本身的項目裏

    現有的任何網站和應用，無需作任何修改均可以在HTTP 2.0 上跑起來。不用爲了利用HTTP 2.0 的好處而修改標記。HTTP 服務器必須運行HTTP 2.0 協議，但大部分用戶都不會所以而受到影響。

 

    若是你使用NGINX，只要在配置文件中啓動相應的協議就能夠了，能夠參考NGINX白皮書，NGINX配置HTTP2.0官方指南。

 

    使用了HTTP2.0那麼，本來的HTTP1.x怎麼辦，這個問題其實不用擔憂，HTTP2.0徹底兼容HTTP1.x的語義，對於不支持HTTP2.0的瀏覽器，NGINX會自動向下兼容的。