## **首部壓縮** 服務器推送，此推送非彼推送，一開始以為，是不是以后可以拋棄輪詢這種技術了？并不是，該輪詢還是要輪詢。那么，在開啟keep-alive的情況下，輪詢在HTTP/2中的性能沒什么提升嗎？也并不是。 在HTTP/1.x中首部是沒有壓縮的，gzip只會壓縮body，HTTP/2提供了首部壓縮方案。一般輪詢請求首部，特別是cookie占用很多大部份空間，首部壓縮使得整個HTTP數據包小了很多，傳輸也就會更快。 剛開始spdy提出的首部壓縮方案比較簡單粗暴，直接像壓縮body那樣壓縮首部，這看起來好像沒什么不妥，但是有安全隱患，會有受到CRIME式攻擊的可能性。這種攻擊方法簡單說，就是不斷地利用已知數據去探測密文，達到破解的目的。無損壓縮算法會有個特性，數據越冗余，壓縮效率越好。而首部中的很多字段是已知的，我們只要構造個請求，請求中帶有首部的某個字段，經壓縮再加密后的密文長度就會有所變化，然后不斷構造猜測該字段的值，同時觀察密文的長度，慢慢地確定首部字段的值。 ~~~ GET /pwd=0 HTTP/1.1 Cookie: pwd=123 GET /pwd=1 HTTP/1.1 Cookie: pwd=123 ~~~ 我們會發現，前者的密文長度比后者長，這樣就確定了“d”，再慢慢的猜測，達到破解的目的。 HTTP/2中拋棄了這種方案，用專門設計的HPACK。它是在服務器和客戶端各維護一個“首部表”，表中用索引代表首部名，或者首部鍵-值對，上一次發送兩端都會記住已發送過哪些首部，下一次發送只需要傳輸差異的數據，相同的數據直接用索引表示即可，另外還可以選擇地對首部值壓縮后再傳輸。按照這樣的設計，兩次輪詢請求的首部基本是一樣的，那之后的請求基本只需要發送幾個索引就可以了。  “首部表”有兩種，一種是靜態表，即HTTP/2協議內置了常用的一些首部名和首部鍵值對。另一種是動態表，保存自定義的首部或五花八門的鍵值對等，動態表可以通過`SETTINGS`幀的SETTINGS_HEADER_TABLE_SIZE規定大小。