http各個版本(1/1.1/2)對比

目錄:

• http1.1 長鏈接
• HTTP 1.1支持只發送header信息(不帶任何body信息)
• http1.1 host請求頭
• HTTP2.0使用多路複用技術(Multiplexing)
• HTTP/2新增首部壓縮（Header Compression）:採用HPACK算法
• HTTP/2新增服務端推送（Header Compression）

參考的文章:

• 從理論到實踐 全面理解HTTP/2
• HTTP協議以及HTTP2.0/1.1/1.0區別
• 綜合闡述http1.0/1.1/2和https

http1.1 長鏈接

HTTP1.1默認使用長鏈接，可有效減小TCP的三次握手開銷。
HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接
當一個網頁文件中包含了不少圖像的地址的時候，那就須要不少次的http請求和響應，每次請求和響應都須要一個單獨的鏈接，每次鏈接只是傳輸一個文檔和圖像，上一次和下一次請求徹底分離。即便圖像文件都很小，可是客戶端和服務器端每次創建和關閉鏈接倒是一個相對比較費時的過程，而且會嚴重影響客戶機和服務器的性能。當一個網頁文件中包含JavaScript文件，CSS文件等內容時，也會出現相似上述的狀況。
爲了克服HTTP 1.0的這個缺陷，HTTP 1.1支持持久鏈接（HTTP/1.1的默認模式使用帶流水線的持久鏈接），在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答能夠在一個鏈接中傳輸，但每一個單獨的網頁文件的請求和應答仍然須要使用各自的鏈接。

HTTP 1.1還容許客戶端不用等待上一次請求結果返回，就能夠發出下一次請求，但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果，以保證客戶端可以區分出每次請求的響應內容，這樣也顯著地減小了整個下載過程所須要的時間。

經過請求頭中connection字段在代表是否支持長連接
在http1.1中，client和server都是默認對方支持長連接的(即connection的值默認我Keep-Alive)， 若是client使用http1.1協議，但又不但願使用長連接，則須要在header中指明connection的值爲closer(connection默認爲Keep-Alive)；若是server方也不想支持長連接，則在response中也須要明確說明connection的值爲closer。不論request仍是response的header中包含了值爲closer的connection，都代表當前正在使用的tcp連接在當天請求處理完畢後會被斷掉。之後client再進行新的請求時就必須建立新的tcp連接了。

HTTP 1.1支持只發送header信息(不帶任何body信息)

若是服務器認爲客戶端有權限請求服務器，則返回100，不然返回401。客戶端若是接受到100，纔開始把請求body發送到服務器。這樣當服務器返回401的時候，客戶端就能夠不用發送請求body了，節約了帶寬。另外HTTP還支持傳送內容的一部分。這樣當客戶端已經有一部分的資源後，只須要跟服務器請求另外的部分資源便可。這是支持文件斷點續傳的基礎。

RANGE:bytes是HTTP/1.1新增內容，HTTP/1.0每次傳送文件都是從文件頭開始，即0字節處開始。RANGE:bytes=XXXX表示要求服務器從文件XXXX字節處開始傳送，這就是咱們平時所說的斷點續傳！

http1.1 host請求頭

HTTP1.0是沒有host域的，HTTP1.1才支持這個參數。
1.0中WEB瀏覽器沒法使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這樣就沒法使用WEB服務器在同一個IP地址和端口號上配置多個虛擬WEB站點。在HTTP 1.1中增長Host請求頭字段後，WEB瀏覽器可使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這才實現了在一臺WEB服務器上能夠在同一個IP地址和端口號上使用不一樣的主機名來建立多個虛擬WEB站點。

HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。

HTTP2.0使用多路複用技術(Multiplexing)

多路複用容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息。
"HTTP1.1在同一時間對於同一個域名的請求數量有限制，超過限制就會阻塞請求"。多路複用底層採用增長二進制分幀層的方法，使得不改變原來的語義、首部字段的狀況下提升傳輸性能，下降延遲。
二進制分幀將全部傳輸信息分割爲更小的幀，用二進制進行編碼，多個請求都在同一個TCP鏈接上完成，能夠承載任意數量的雙向數據流。HTTP/2更有效的使用TCP鏈接，獲得性能上的提高。

二進制分幀層把數據轉換爲二進制的同時，也把數據分紅了一個一個的幀。幀是HTTP/2中數據傳輸的最小單位；每一個幀都有stream_ID字段，表示這個幀屬於哪一個流，接收方把stream_ID相同的全部幀組合到一塊兒就是被傳輸的內容了。而流是HTTP/2中的一個邏輯上的概念，它表明着HTTP/1.1中的一個請求或者一個響應，協議規定client發給server的流的stream_ID爲奇數，server發給client的流ID是偶數。須要注意的是，流只是一個邏輯概念，便於理解和記憶的，實際並不存在。

在一個TCP連接中，能夠同時雙向地發送幀，並且不一樣流中的幀能夠交錯發送，不須要等某個流發送完，才發送下一個。也就是說在一個TCP鏈接中，能夠同時傳輸多個流，便可以同時傳輸多個HTTP請求和響應，這種同時傳輸不須要遵循先入先出等規定，所以也不會產生阻塞，效率極高。

HTTP/2新增首部壓縮（Server Push）:採用HPACK算法

在 HTTP/1 中，HTTP 請求和響應都是由「狀態行、請求 / 響應頭部、消息主體」三部分組成。通常而言，消息主體都會通過 gzip 壓縮，或者自己傳輸的就是壓縮事後的二進制文件（例如圖片、音頻），但狀態行和頭部卻沒有通過任何壓縮，直接以純文本傳輸。
隨着 Web 功能愈來愈複雜，每一個頁面產生的請求數也愈來愈多，根據 HTTP Archive 的統計，當前平均每一個頁面都會產生上百個請求。愈來愈多的請求致使消耗在頭部的流量愈來愈多，尤爲是每次都要傳輸 UserAgent、Cookie 這類不會頻繁變更的內容，徹底是一種浪費。
Hapck原理:
具體規則能夠描述爲：

• 通訊雙方共同維護了一份靜態表，包含了常見的頭部名稱與值的組合
• 根據先入先出的原則，維護一份可動態添加內容的動態表
• 用基於該靜態哈夫曼碼錶的哈夫曼編碼數據
  當要發送一個請求時，會先將其頭部和靜態表對照，對於徹底匹配的鍵值對，能夠直接使用一個數字表示，如method: GET，對於頭部名稱匹配的鍵值對，能夠將名稱使用一個數字傳輸，同時告訴服務端將它添加到動態表中，之後的相同鍵值對就用一個數字表示了。這樣，像cookie這些不常常變更的值，只用發送一次就行了。

HTTP/2新增服務端推送（Header Compression）

即服務器發送/user.html時，就能夠主動把/user.js和style.csspush給瀏覽器，使資源提早達到瀏覽器；除了靜態文件，還能夠推送比較耗時的API，只是須要提早將參數和cookie等信息經過某個方式告知服務端（如和路由關聯）。Apache、GO的net/http、node-spdy都實現了server push（但ngnix沒有=_=） Server push是HTTP/2協議裏面惟一一個須要開發者本身配置的功能。其餘功能都是服務器和瀏覽器自動實現，無需開發者介入。 在HTTP1.1時代，也有提早獲取資源的方法，如preload和prefetch，前者是在頁面解析初期就告訴瀏覽器，這個資源是瀏覽器立刻要用到的，能夠馬上發送對資源的請求，當須要用到該資源時就能夠直接用而不用等待請求和響應的返回了；後者是當前頁面用不到但下一頁面可能會用到的資源，優先級較低，只有當瀏覽器空閒時纔會請求prefetch標記的資源。從應用層面上看，preload和server push並無什麼區別，可是server push減小瀏覽器請求的時間，略優於preload，在一些場景中，能夠將二者結合使用。