# 6. http2協議
背景介紹就到此為止了，歷史的腳步將我們推到了今天這一步。現在讓我們深入看看該協議的規范，看看那些細節和概念。
## 6.1. 二進制
http2是一個二進制協議。
仔細想想，如果你是一個曾經跟互聯網協議打過交道，那你很可能本能反對二進制協議，你甚至準備好了一大堆理由來證明基于文本/ascii的協議是多么的有用，正如你曾無數次地通過手工輸入HTTP請求來通過telnet遠程登陸。
二進制的http2可以使成幀更便捷。在HTTP1.1和其他基于文本的協議中，識別幀的起始和結束相當復雜。而在移除掉可選的空白符和其他冗余后，實現這些會變得更容易。
另一方面，從幀結構中分離出協議本身的部分也變得更容易。而在HTTP1中，各個部分相互交織，一團亂麻。
協議的壓縮特點和其經常運行在TLS之上的事實讓純文本的屬性值變得毫無作用，畢竟也無法從數據流上看到文本。我們需要習慣于使用類似Wireshark的工具來從協議層面對http2一探究竟。
調試這樣的協議將需要curl這樣的工具，要進一步地分析網絡數據流需要類似Wireshark的http2解析器。
## 6.2. 二進制格式
http2發送二進制幀。幀的類型有很多種，但他們都有如下的公共字段：
Type, Length, Flags, Steam Identifier和frame payload
http2的規范一共定義了10種不同的幀，其中最基礎的兩種分別對應于HTTP 1.1的DATA和HEADERS。之后我會更詳細的介紹其中一些幀。
## 6.3. 多路復用的流
上一節提到的Stream Identifier定義了二進制幀的格式，http2連接上傳輸的每個幀都關聯到一個“流”。流是一個邏輯上的聯合，一個獨立的，雙向的幀序列。這一系列幀在客戶端和服務器中通過http2連接進行交換。
每個單獨的http2連接都可以包含多個并發的流，這些流中交錯的包含著來自兩端的幀。流既可以被客戶端/服務器端單方面的建立和使用，也可以被雙方共享，或者被任意一邊關閉。在流里面，每一幀發送的順序非常關鍵。接收方會按照收到幀的順序來進行處理。
流的多路復用意味著在同一連接中來自各個流的數據包被混合在一起。兩個（或者更多）獨立的“數據列車”被拼湊到了一輛列車上，最終在終點站被分開。下圖就是兩列“數據火車”的示例
它們就是這樣通過多路復用的方式被組裝到了同一列火車上。
在http2里面，我們很容易可以看到10個甚至100個同時并存的流。創建一個新的流的代價也非常低。
## 6.4. 優先級和依賴性
每個流都包含一個優先級，優先級被用來告訴對端哪個流更重要。
優先級的工作機制在協議中被改變多次，至今仍在討論。重點在于要讓客戶端能指定哪個流更重要，并且提供一個依賴參數來指定流的依賴關系。
優先級能動態的被改變。這樣當用戶滾動一個全是圖片的頁面的時候，瀏覽器能夠指定哪個圖片有更高的優先級。或者是在你切換標簽頁的時候，瀏覽器可以提升新切換到頁面所包含流的優先級。
## 6.5. 頭壓縮
HTTP是無狀態協議。簡而言之，這意味著每個請求必須要攜帶服務器需要的所有細節，而不是讓服務器保存住之前請求的元數據。因為http2沒有改變這個范式，所以它也需要這樣（攜帶所有細節）。
這也保證了HTTP可重復性。當一個客戶端從同一服務器請求一些資源（例如頁面的圖片）的時候，這些請求看起來幾乎是一致的。而這些大量一致的東西正好值得被壓縮。
當每個頁面資源的個數上升的時候，cookies和請求的大小都會增加，而每個請求都會包含的cookie幾乎是一模一樣的。
HTTP 1.1請求的大小變得越來越大，有時甚至會大于TCP窗口的初始大小，這會嚴重拖累發送請求的速度。因為它們需要等待帶著ACK的響應回來以后，才能繼續被發送。這也是需要壓縮的理由。
**6.5.1. 壓縮是非常棘手的課題**
HTTPS和SPDY的壓縮機制被發現有受[BREACH](http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29)和[CRIME](http://en.wikipedia.org/wiki/CRIME)攻擊的隱患。通過向流中注入一些已知的文本來觀察輸出的變化，攻擊者可以推出原始發送的數據。
為協議的動態內容進行壓縮并使其免于被攻擊，需要仔細且全面的考慮。而這正是HTTPbis小組嘗試去做的。
[HPACK](http://www.rfc-editor.org/rfc/rfc7541.txt)，_HTTP/2頭部壓縮_，顧名思義它是一個專為http2頭部設計的壓縮格式。確切的講，它甚至被制定寫入在另外一個單獨的草案里。新的格式同時引入了一些其他對策讓破解壓縮變得困難，例如采用幀的可選填充和用一個bit作為標記，來讓中間人不壓縮指定的頭部。
用Roberto Peon（HPACK的設計者之一）的話說，“HPACK旨在提供一個一致性的實現使信息量的損失盡可能少，使編解碼快速而方便，使接收方能控制壓縮文本的大小，允許代理重新建立索引（如，通過代理在前后端共享狀態），以及對哈夫曼編碼串的更快速比較”。
## 6.6. 重置 - 后悔藥
HTTP 1.1的有一個缺點是：當一個含有確切值的Content-Length的HTTP消息被送出之后，你就很難中斷它了。當然，通常你可以斷開整個TCP鏈接（但也不總是可以這樣），但這樣導致的代價就是需要重新通過三次握手建立一個新的TCP連接。
一個更好的方案是只終止當前傳輸的消息并重新發送一個新的。在http2里面，我們可以通過發送RST_STREAM幀來實現這種需求，從而避免浪費帶寬和中斷已有的連接。
## 6.7. 服務器推送
這個功能通常被稱作“緩存推送”。主要的思想是：當一個客戶端請求資源X，而服務器知道它很可能也需要資源Z的情況下，服務器可以在客戶端發送請求前，主動將資源Z推送給客戶端。這個功能幫助客戶端將Z放進緩存以備將來之需。
服務器推送需要客戶端顯式的允許服務器提供該功能。但即使如此，客戶端依然能自主選擇是否需要中斷該推送的流。如果不需要的話，客戶端可以通過發送一個RST_STREAM幀來中止。
## 6.8. 流量控制
http2上面每個流都擁有自己的公示的流量窗口，它可以限制另一端發送數據。如果你正好知道SSH的工作原理的話，這兩者非常相似。
對于每個流來說，兩端都必須告訴對方自己還有更多的空間來接受新的數據，而在該窗口被擴大前，另一端只被允許發送這么多數據。只有數據幀受流量控制。
