http協議不一樣版本之間的對比(1.0 1.1 2.0)

http 1.0

• 短鏈接
  每個請求創建一個TCP鏈接，請求完成後立馬斷開鏈接。這將會致使2個問題：鏈接沒法複用，head of line blocking
  鏈接沒法複用會致使每次請求都經歷三次握手和慢啓動。三次握手在高延遲的場景下影響較明顯，慢啓動則對文件類大請求影響較大。head of line blocking會致使帶寬沒法被充分利用，以及後續健康請求被阻塞。
  </br>
  http 1.1
  爲解決HTTP 1.0 的痛點而產生。
• 長鏈接
  經過http pipelining實現。多個http 請求能夠複用一個TCP鏈接，服務器端按照FIFO原則來處理不一樣的Request
• 增長connection header
  該header用來講明客戶端與服務器端TCP的鏈接方式，若connection爲close則使用短鏈接，若connection爲keep-alive則使用長鏈接
• 身份認證
• 狀態管理
• Cache緩存等機制相關的請求頭和響應頭
• 增長Host header

http 2.0

• 多路複用 (Multiplexing)
  多路複用容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息。在 HTTP/1.1 協議中瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量限制。超過限制數目的請求會被阻塞。這也是爲什麼一些站點會有多個靜態資源 CDN 域名的緣由之一，拿 Twitter 爲例，http://twimg.com，目的就是變相的解決瀏覽器針對同一域名的請求限制阻塞問題。而 HTTP/2 的多路複用(Multiplexing) 則容許同時經過單一的 HTTP/2 鏈接發起多重的請求-響應消息。所以 HTTP/2 能夠很容易的去實現多流並行而不用依賴創建多個 TCP 鏈接，HTTP/2 把 HTTP 協議通訊的基本單位縮小爲一個一個的幀，這些幀對應着邏輯流中的消息。並行地在同一個 TCP 鏈接上雙向交換消息。
• 二進制分幀
  HTTP/2在 應用層(HTTP/2)和傳輸層(TCP or UDP)之間增長一個二進制分幀層。在不改動 HTTP/1.x 的語義、方法、狀態碼、URI 以及首部字段的狀況下, 解決了HTTP1.1 的性能限制，改進傳輸性能，實現低延遲和高吞吐量。在二進制分幀層中， HTTP/2 會將全部傳輸的信息分割爲更小的消息和幀（frame）,並對它們採用二進制格式的編碼 ，其中 HTTP1.x 的首部信息會被封裝到 HEADER frame，而相應的 Request Body 則封裝到 DATA frame 裏面。

HTTP/2 通訊都在一個鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。在過去， HTTP 性能優化的關鍵並不在於高帶寬，而是低延遲。TCP 鏈接會隨着時間進行自我調諧，起初會限制鏈接的最大速度，若是數據成功傳輸，會隨着時間的推移提升傳輸的速度。這種調諧則被稱爲 TCP 慢啓動。因爲這種緣由，讓本來就具備突發性和短時性的 HTTP 鏈接變的十分低效。HTTP/2 經過讓全部數據流共用同一個鏈接，能夠更有效地使用 TCP 鏈接，讓高帶寬也能真正的服務於 HTTP 的性能提高。

這種單鏈接多資源的方式，減小服務端的連接壓力,內存佔用更少,鏈接吞吐量更大；並且因爲 TCP 鏈接的減小而使網絡擁塞情況得以改善，同時慢啓動時間的減小,使擁塞和丟包恢復速度更快。

• 首部壓縮（Header Compression）

HTTP/1.1並不支持 HTTP 首部壓縮，爲此 SPDY 和 HTTP/2 應運而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 則使用了專門爲首部壓縮而設計的 HPACK 算法。
* 服務端推送（Server Push）

服務端推送是一種在客戶端請求以前發送數據的機制。在 HTTP/2 中，服務器能夠對客戶端的一個請求發送多個響應。Server Push 讓 HTTP1.x 時代使用內嵌資源的優化手段變得沒有意義；若是一個請求是由你的主頁發起的，服務器極可能會響應主頁內容、logo 以及樣式表，由於它知道客戶端會用到這些東西。這至關於在一個 HTML 文檔內集合了全部的資源，不過與之相比，服務器推送還有一個很大的優點：能夠緩存！也讓在遵循同源的狀況下，不一樣頁面之間能夠共享緩存資源成爲可能。