【開發筆記 #1】Http/2.0瞭解

一 Http/2.0 特色

1.安全

基於HTTPS協議

2.高效

使用二進制分幀進行數據傳輸，低延遲，高吞吐量

3.兼容

2.0協議是在1.x的基礎上升級而不是重寫，1.x協議的語義、HTTP 方法、狀態碼、URI 及首部字段在2.0裏是同樣的

二 Http/2.0優化

0.概念

1）、幀（Frame）

幀是數據通訊的最小單位，以二進制壓縮格式存放內容。
包含：類型Type, 長度Length, 標記Flags, 流標識和Frame payload有效載荷。
來自不一樣數據流的幀能夠交錯發送，而後再根據每一個幀頭的數據流標識符從新組裝。
詳細介紹：HTTP/2 中的幀定義

2）、消息（Message）

消息：指 HTTP/2 中邏輯上的 HTTP 消息。
例如請求和響應等，消息由一個或多個幀組成。

3）、流（Stream）

流是鏈接中的一個虛擬信道，能夠承載雙向消息傳輸，包含1條或者多條Message。每一個流有惟一整數標識符。爲了防止兩端流ID衝突，客戶端發起的流具備奇數ID，服務器端發起的流具備偶數ID。

特色：

• 1.雙向性：同一個流內，可同時發送和接受數據。
• 2.有序性：流中被傳輸的數據就是二進制幀 。幀在流上的被髮送與被接收都是按照順序進行的。
• 3.並行性：流中的 二進制幀 都是被並行傳輸的，無需按順序等待。但卻不會引發數據混亂，由於每一個幀都有順序標號。它們最終會被按照順序標號來合併。
• 4.流的建立：流能夠被客戶端或服務器單方面創建, 使用或共享。
• 5.流的關閉：流也能夠被任意一方關閉。

4）、流標識

流標識是描述二進制Frame的格式，使得每一個Frame可以基於HTTP/2發送，與流標識聯繫的是一個流，每一個流是一個邏輯聯繫，一個獨立的雙向的Frame存在於客戶端和服務器端之間的HTTP/2鏈接中。一個HTTP/2鏈接上可包含多個併發打開的流，這個併發流的數量可以由客戶端設置。
總結

• 幀是流中的數據單位；
• 消息由一個或多個幀組成；
• 消息的header幀能夠分紅多個header幀，data幀能夠分紅多個data幀。

5）、Connection鏈接

1個TCP 鏈接，包含1個或者多個Stream。全部通訊都在一個TCP鏈接上完成，此鏈接能夠承載任意數量的雙向數據流。

1.二進制分幀（Binary Format）

將傳輸信息分爲兩個幀，分別是Headers幀和Data幀。
在二進制分幀層上， HTTP/2.0 會將全部傳輸的信息分割爲更小的消息和幀,並對它們採用二進制格式的編碼 ，其中HTTP/1.x的首部信息會被封裝到Headers幀，而咱們的request body則封裝到Data幀裏面。

HTTP/2.0 通訊都在一個鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。相應地，每一個數據流以消息的形式發送，而消息由一或多個幀組成，這些幀能夠亂序發送，而後再根據每一個幀首部的流標識符從新組裝。

在二進制分幀層上，HTTP/2會將全部傳輸信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼將其封裝，新增的二進制分幀層同時也可以保證HTTP的各類動詞，方法，首部都不受影響，兼容上一代HTTP標準。其中，HTTP/1.X中的首部信息header封裝到Headers幀中，而request body將被封裝到Data幀中。

2.多路複用 (Multiplexing) / 鏈接共享

在 HTTP/1.x 中，一次連接成功後，只要該連接還沒斷開，那麼 client 端能夠在這麼一個連接中有序地發起多個請求，並以此得到每一個請求對應的響應數據。可是瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量的限制，超過限制數目的請求會被阻塞，一次請求與響應的交互必需要等待前面的請求交互完成，不然後面的只能等待，這個就是線頭阻塞。要想實現多流並行，就要開啓多個TCP鏈接。
HTTP/2.0新的分幀機制能夠不依賴多個TCP鏈接去實現多流並行，並且多路複用容許同時經過單一的HTTP/2 鏈接發起多重的請求-響應消息，不會形成阻塞。

總結

• 1.同域名下全部通訊都在單個鏈接上完成，同個域名只須要佔用一個 TCP 鏈接，消除了因多個 TCP 鏈接而帶來的延時和內存消耗；
• 2.單個鏈接能夠承載任意數量的雙向數據流，單個鏈接上能夠並行交錯的請求和響應，之間互不干擾；
• 3.數據流以消息的形式發送，而消息又由一個或多個幀組成，多個幀之間能夠亂序發送，由於根據幀首部的流標識能夠從新組裝。

3.頭部壓縮（Header Compression）

1）、爲何要壓縮

在 HTTP/1 中，HTTP 請求和響應都是由「狀態行、請求 / 響應頭部、消息主體」三部分組成。HTTP每一次通訊都會攜帶一組頭部，用於描述此次通訊的的資源、瀏覽器屬性、cookie等，HTTP/1.x每次請求都會攜帶大量冗餘頭信息，請求的大小變得愈來愈大，有時甚至會大於TCP窗口的初始大小，由於它們須要等待帶着ACK的響應回來之後才能繼續被髮送。通常而言，消息主體都會通過 gzip 壓縮，或者自己傳輸的就是壓縮事後的二進制文件（例如圖片、音頻），但狀態行和頭部卻沒有通過任何壓縮，直接以純文本傳輸。

2）、壓縮策略

• 1.HTTP/2在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵－值對，對於相同的數據，再也不經過每次請求和響應發送；
• 2.首部表在HTTP/2的鏈接存續期內始終存在，由客戶端和服務器共同漸進地更新;若是請求中不包含首部(例如對同一資源的輪詢請求)，那麼，首部開銷就是零字節，此時全部首部都自動使用以前請求發送的首部；
• 3.每一個新的首部鍵－值對要麼被追加到當前表的末尾，要麼替換表中以前的值。

HTTP/2關注的是首部壓縮（HPACK算法），而咱們經常使用的gzip等是報文內容（body）的壓縮

3）、壓縮原理

用Header字段表裏的索引代替實際的Header。

HTTP/2的HPACK算法使用一份索引表來定義經常使用的HTTP Header，把經常使用的 HTTP Header 存放在表裏，請求的時候便只須要發送在表裏的索引位置便可。

例如 :method=GET 使用索引值 2 表示，:path=/index.html 使用索引值 5 表示，以下圖：

詳細介紹HTTP/2 頭部壓縮技術介紹

4.請求優先級（Request Priorities）

把HTTP消息分爲不少獨立幀以後，就能夠經過優化這些幀的交錯和傳輸順序進一步優化性能。
每一個流均可以帶有一個31比特的優先值

• 0 表示最高優先級
• -1（2的31次方） 表示最低優先級。

服務器能夠根據流的優先級，控制資源分配（CPU、內存、帶寬），而在響應數據準備好以後，優先將最高優先級的幀發送給客戶端。高優先級的流都應該優先發送，但又不會絕對的，絕對地準守，可能又會引入首隊阻塞的問題：高優先級的請求慢致使阻塞其餘資源交付。

分配處理資源和客戶端與服務器間的帶寬，不一樣優先級的混合也是必須的。客戶端會指定哪一個流是最重要的，有一些依賴參數，這樣一個流能夠依賴另一個流。優先級別能夠在運行時動態改變，當用戶滾動頁面時，能夠告訴瀏覽器哪一個圖像是最重要的，你也能夠在一組流中進行優先篩選，可以忽然抓住重點流。

• 優先級最高：主要的html
• 優先級高：CSS文件
• 優先級中：js文件
• 優先級低：圖片

5.服務端推送（Server Push）

服務器能夠對一個客戶端請求發送多個響應，服務器向客戶端推送資源無需客戶端明確地請求，而且，服務端推送能把客戶端所須要的資源伴隨着index.html一塊兒發送到客戶端，省去了客戶端重複請求的步驟。

正由於沒有發起請求，創建鏈接等操做，因此靜態資源經過服務端推送的方式能夠極大地提高速度。Server Push 讓 HTTP/1.x 時代使用內嵌資源的優化手段變得沒有意義；若是一個請求是由你的主頁發起的，服務器極可能會響應主頁內容、logo 以及樣式表，由於它知道客戶端會用到這些東西，這至關於在一個 HTML 文檔內集合了全部的資源。

不過與之相比，服務器推送還有一個很大的優點：能夠緩存！也讓在遵循同源的狀況下，不一樣頁面之間能夠共享緩存資源成爲可能。

三 Http/2.0性能瓶頸

啓用HTTP/2.0後會給性能帶來很大的提高，但同時也會帶來新的性能瓶頸。由於如今全部的壓力集中在底層一個TCP鏈接之上，TCP極可能就是下一個性能瓶頸，好比TCP分組的隊首阻塞問題，單個TCP packet丟失致使整個鏈接阻塞，沒法逃避，此時全部消息都會受到影響。將來，服務器端針對HTTP/2.0下的TCP配置優化相當重要。