乾貨HTTP/2.0，騙你是小狗

http/2 大致可以分為兩部分:分幀層，即 h2 多路複用能力的核心部分;資料或 http 層,其中包含傳統上被認為是 HTTP 及其關聯資料的部分。 

二進位制協議：

 h2 的分幀層是基於幀的二進位制協議。這方便了機器解析，但是肉眼識別起來比較困難。

首部壓縮：

僅僅使用二進位制協議似乎還不夠，h2 的首部還會被深度壓縮。這將顯著減少傳輸中的冗餘位元組 

 多路複用 ：

連線是所有 HTTP/2 會話的基礎元素，其定義是客戶端初始化的一個 TCP/IP socket，客戶端 是指傳送 HTTP 請求的實體。這和 h1 是一樣的，不過與完全無狀態的 h1 不同的是，h2 把它所承載的幀(frame)和流(stream)共同依賴的連線層元素捆綁在一起，其中既包含連線層設定也包含首部表。 

解析這種資料用不著什麼高科技，但往往速度慢且容易出錯。你需要不斷讀入位元組，直到 遇到分隔符為止(這裡是指 <crlf>)，同時還要考慮一些不太守規矩的客戶端，它們會只 傳送 <lf>。

從另一方面來說，有了幀，處理協議的程式就能預先知道會收到什麼。基於幀的協議，特別是 h2，開始有固定長度的位元組，其中包含表示整幀長度的欄位。

來，我們看一下幀結構?

• Type： 1 位元組  當前幀型別

loop
   Read 9 bytes off the wire                          //讀前9個位元組
   Length = the first three bytes                     //長度值為前3位元組
   Read the payload based on the length.              //基於長度讀負載
   Take the appropriate action based on the frame type. // 根據幀型別採取對應操作
end loop 			複製程式碼

HTTP/2 規範對流(stream)的定義是:“HTTP/2 連線上獨立的、雙向的幀序列交換。”你可以將流看作在連線上的一系列幀，它們構成了單獨的 HTTP 請求和響應。如果客戶端想 要發出請求，它會開啟一個新的流。然後，伺服器將在這個流上回復。這與 h1 的請求 / 響應流程類似，重要的區別在於，因為有分幀，所以多個請求和響應可以交錯，而不會互相阻塞。 

h1 的請求和響應都分成訊息首部和訊息體兩部分;與之類似，h2 的請求和響應分成HEADERS 幀和 DATA 幀。

h1 把訊息分成兩部分:請求 / 狀態行;首部。h2 取消了這種區分，並把這些行變成了 魔法偽首部。舉個例子，HTTP/1.1 的請求和響應可能是這樣的:

     GET / HTTP/1.1
     Host: www.example.com
     User-agent: Next-Great-h2-browser-1.0.0
     Accept-Encoding: compress, gzip
     HTTP/1.1 200 OK
     Content-type: text/plain
     Content-length: 2     ...複製程式碼

在 HTTP/2 中，它等價於:

 :scheme: https:method: GET
 :path: /
 :authority: www.example.com
 User-agent: Next-Great-h2-browser-1.0.0
 Accept-Encoding: compress, gzip 
 :status: 200 
 content-type: text/plain複製程式碼

流的最後一個重要特性是依賴關係。現代瀏覽器都經過了精心設計，首先請求網頁上最重要的元素，以最優的順序獲取資源，由此來優化頁面效能。拿到了 HTML 之後，在渲染頁面之前，瀏覽器通常還需要 CSS 和關鍵 JavaScript 這樣的東西。在沒有多路複用的時候，在它可以發出對新物件的請求之前，需要等待前一個響應完成。有了 h2，客戶端就可以 一次發出所有資源的請求，服務端也可以立即著手處理這些請求。由此帶來的問題是，瀏覽器失去了在 h1 時代預設的資源請求優先順序策略。假設伺服器同時接收到了 100 個請求， 也沒有標識哪個更重要，那麼它將幾乎同時傳送每個資源，次要元素就會影響到關鍵元素 的傳輸。 

h2 通過流的依賴關係來解決這個問題。通過 HEADERS 幀和 PRIORITY 幀，客戶端可以明確地和服務端溝通它需要什麼，以及它需要這些資源的順序。這是通過宣告依賴關係樹 和樹裡的相對權重實現的。 

• 依賴關係為客戶端提供了一種能力，通過指明某些物件對另一些物件有依賴，告知伺服器這些物件應該優先傳輸。

• 權重讓客戶端告訴伺服器如何確定具有共同依賴關係的物件的優先順序。 

index.html
– header.jpg
– critical.js
– less_critical.js
– style.css
– ad.js
– photo.jpg 	複製程式碼

在收到主體 HTML 檔案之後，客戶端會解析它，並生成依賴樹，然後給樹裡的元素分配權重。這時這棵樹可能是這樣的:

  index.html
  – style.css
    – critical.js
      –  less_critical.js (weight 20)
      –  photo.jpg (weight 8)
      –  header.jpg (weight 8)
      –  ad.js (weight 4) 			複製程式碼

在這個依賴樹裡，客戶端表明它最需要的是 style.css，其次是 critical.js。沒有這兩個檔案， 它就不能接著渲染頁面。等它收到了 critical.js，就可以給出其餘物件的相對權重。權重表示服務一個物件時所需要花費的對應“努力”程度。 

提升單個物件效能的最佳方式，就是在它被用到之前就放到瀏覽器的快取裡面。這正是 HTTP/2 的服務端推送的目的。推送使伺服器能夠主動將物件發給客戶端，這可能是因為 它知道客戶端不久將用到該物件。 

如果伺服器決定要推送一個物件(RFC 中稱為“推送響應”)，會構造一個 PUSH_PROMISE 幀。這個幀有很多重要屬性，列舉如下 ：

• ?PUSH_PROMISE 幀首部中的流 ID 用來響應相關聯的請求。推送的響應一定會對應到 客戶端已傳送的某個請求。如果瀏覽器請求一個主體 HTML 頁面，如果要推送此頁面 使用的某個 JavaScript 物件，伺服器將使用請求對應的流 ID 構造 PUSH_PROMISE 幀。

• ?PUSH_PROMISE 幀的首部塊與客戶端請求推送物件時傳送的首部塊是相似的。所以客戶端有辦法放心檢查將要傳送的請求。

• ?被髮送的物件必須確保是可快取的。

• ?:method 首部的值必須確保安全。安全的方法就是冪等的那些方法，這是一種不改變

  任何狀態的好辦法。例如，GET 請求被認為是冪等的，因為它通常只是獲取物件，而POST 請求被認為是非冪等的，因為它可能會改變伺服器端的狀態。

• ?理想情況下，PUSH_PROMISE 幀應該更早傳送，應當早於客戶端接收到可能承載著推

  送物件的 DATA 幀。假設伺服器要在傳送 PUSH_PROMISE 之前傳送完整的 HTML， 那客戶端可能在接收到 PUSH_PROMISE 之前已經發出了對這個資源的請求。h2 足夠健壯，可以優雅地解決這類問題，但還是會有些浪費。

• ?PUSH_PROMISE 幀會指示將要傳送的響應所使用的流 ID。 

客戶端會從 1 開始設定流 ID，之後每新開啟一個流，就會增加 2，之後一直 使用奇數。伺服器開啟在 PUSH_PROMISE 中標明的流時，設定的流 ID 從 2 開始，之後一直使用偶數。這種設計避免了客戶端和伺服器之間的流 ID 衝 突，也可以輕鬆地判斷哪些物件是由服務端推送的。0 是保留數字，用於連 接級控制訊息，不能用於建立新的流。 

如果客戶端對 PUSH_PROMISE 的任何元素不滿意，就可以按照拒收原因選擇重置這個流 (使用 RST_STREAM)，或者傳送 PROTOCOL_ERROR(在 GOAWAY 幀中)。常見的情況是快取中已經有了這個物件。而 PROTOCOL_ERROR 是專門留給 PUSH_PROMISE 涉及的協議層面問題的，比如方法不安全，或者當客戶端已經在 SETTINGS 幀中表明自己不接受推送時，仍然進行了推送。值得注意的是，伺服器可以在 PUSH_PROMISE 傳送後立即啟動推送流，因此拒收正在進行的推送可能仍然無法避免推送大量資源。推送正確的資源是不夠的，還需要保證只推送正確的資源，這是重要的效能優化手段。 

 • 資源已經在瀏覽器快取中的概率

• 從客戶端看來，這些資源的優先順序

“臃腫的訊息首部”提到過，現代網頁平均包含 140 個請求，每個 HTTP 請求 平均有 460 位元組，總資料量達到 63KB。即使在最好的環境下，這也會造成相當長的延時， 如果考慮到擁擠的 WiFi 或連線不暢的蜂窩網路，那可是非常痛苦的。這些請求之間通常幾乎沒有新的或不同的內容，這才是真正的浪費。所以，大家迫切渴望某種型別的壓縮。 經過多次創新性的思考和討論，人們提出了 HPACK。HPACK 是種表查詢壓縮方案，它利用霍夫曼編碼獲得接近 GZIP 的壓縮率。 

CRIME 攻擊告訴我們，GZIP 也有洩漏加密資訊的風 險。CRIME 的原理是這樣的，攻擊者在請求中新增資料，觀察壓縮加密後的資料量是否會小於預期。如果變小了，攻擊者就知道注入的文字和請求中的其他內容(比如私有的會話 cookie)有重複。在很短的時間內，經過加密 的資料內容就可以全部搞清楚。因此，大家放棄了已有的壓縮方案，研發出 HPACK。 

第一個請求:

     :authority: www.akamai.com
     :method: GET
     :path: /
     :scheme: https
     accept: text/html,application/xhtml+xml
     accept-language: en-US,en;q=0.8
     cookie: last_page=286A7F3DE
     upgrade-insecure-requests: 1
     user-agent: Awesome H2/1.0複製程式碼

第二個請求:

     :authority: www.akamai.com
     :method: GET     :path: /style.css     :scheme: https     accept: text/html,application/xhtml+xml accept-language: en-US,en;q=0.8     cookie: last_page=*398AB8E8F upgrade-insecure-requests: 1 user-agent: Awesome H2/1.0 
複製程式碼

h1 下的一些效能調優辦法在 h2 下會起到反作用。 

域名拆分是為了利用瀏覽器對每個域名開啟多個連線的能力，以便實現資源的並行下載， 繞過 h1 的序列化下載的限制。對於包含大量小型資源的網站，普遍的做法是拆分域名， 以利用現代瀏覽器針能對每個域名開啟 6 個連線的特性。這樣實際上做到了讓瀏覽器並行 傳送多個請求，以及充分利用可用頻寬的效果。因為 HTTP/2 採取多路複用，所以域名拆 分就不是必要的了，並且反而會讓協議力圖實現的目標落空。 

資源內聯包括把 JavaScript、樣式，甚至圖片插入到 HTML 頁面中，目的是省掉載入外部資源所需的新連線以及請求響應的時間。然而，有些 Web 效能的最佳實踐不推薦使用內聯，因為這樣會損失更有價值的特性，比如快取。如果有同一個頁面上的重複訪問，快取通常可以減少請求數(而且能夠加速頁面渲染)。儘管如此，總體來說，對那些渲染滾動 條以上區域所需的微小資源進行內聯處理仍是值得的。

事實上有證據表明，在效能較弱的 裝置上，快取物件的好處不夠多，把內聯資源拆分出來並不划算。使用 h2 時的一般原則是避免內聯，但是內聯也並不一定毫無價值。 

資源合併意味著把幾個小檔案合併成一個大檔案。它與內聯很相似，旨在省掉那些載入外部資源的請求響應時間，以及解碼 / 執行那些資源所消耗的 CPU 資源。之前針對資源內聯 的規則同樣適用於資源合併，我們可以使用它來合併非常小的檔案(1KB 或更小)，以及 對初始渲染很關鍵的最簡化 JavaScript/CSS 資源。 

通過禁用 cookie 的域名來提供靜態資源是一項標準的效能優化最佳實踐。尤其是使用 h1 時，你無法壓縮首部，而且有些網站使用的 cookie 大小常常超過單個 TCP 資料包的限度。 不過，在 h2 下請求首部使用 HPACK 演算法被壓縮，會顯著減少巨型 cookie(尤其是當它 們在先後請求之間保持不變)的位元組數。與此同時，禁用 cookie 的域名需要額外的主機名 稱，這意味著將開啟更多的連線。

如果你正在使用禁用 cookie 的域名，以後有機會你可能得考慮消滅它。如果你確實不需要那些域名，最好刪掉它們。省一個位元組就是一個位元組。 

目前，生成精靈圖仍是一種避免小資源請求過多的技術(你能看到人們樂意做什麼來優化 h1)。為了生成精靈圖，開發者把較小的圖片拼合成較大的圖片，然後用 CSS 選擇圖片中 某個部分展示出來。依據裝置及其硬體圖形處理能力的不同，精靈圖要麼非常高效，要麼 非常低效。如果用 h2，最佳實踐就是避免生成精靈圖;主要原因在於，多路複用和首部壓縮去掉了大量的請求開銷。即便如此，還是有些場景適合使用精靈圖。