基本介紹
- 中文名：HTTP/2
- 外文名：HTTP/2
簡介,協定的制定,協定之間的的比較,HTTP/2與HTTP/1.1比較,HTTP/1.1與SPDY的區別,HTTP/2與SPDY的比較,新特性,幀、訊息、流和TCP連線,HPACK 算法,伺服器推送,瀏覽器支持,h2c的支持度,SPDY 退出歷史舞台,HTTP/2 的實現,批評與爭議,針對協定開發本身,針對加密的爭議,
簡介
HTTP/2是HTTP協定自1999年HTTP 1.1發布後的首個更新，主要基於SPDY協定。它由網際網路工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組進行開發。該組織於2014年12月將HTTP/2標準提議遞交至IESG進行討論，於2015年2月17日被批准。
HTTP/2標準於2015年5月以RFC 7540正式發表。HTTP/2的標準化工作由Chrome、Opera、Firefox、Internet Explorer 11、Safari、Amazon Silk及Edge等瀏覽器提供支持。
多數主流瀏覽器已經在2015年底支持了該協定。此外，根據W3Techs的數據，在2017年5月，在排名前一千萬的網站中，有13.7%支持了HTTP/2。
協定的制定
協定制定伊始，工作組章程關注了下列目標和受關心的問題：
- 創建一個協商協定標準，即套用層協定協商(ALPN)，以便客戶端能夠從HTTP/1.0、HTTP/1.1、HTTP/2乃至其他非HTTP協定中做出選擇。
- 與HTTP/1.1在請求方法、狀態碼乃至URI和絕大多數HTTP頭部欄位等方面保持高度兼容性。
- 通過以下舉措，減少網路延遲，提高瀏覽器的頁面載入速度：
- 對HTTP頭欄位進行數據壓縮(即HPACK算法)；
- HTTP/2 服務端推送(Server Push)；
- 請求管線化；
- 修復HTTP/1.0版本以來未修復的隊頭阻塞問題；
Facebook對各方案進行了評價並最終推薦了SPDY協定。HTTP 2.0的首個草稿於2012年11月發布，其內容基本和SPDY協定相同。
協定之間的的比較
HTTP/2與HTTP/1.1比較
HTTP/2 相比 HTTP/1.1 的修改並不會破壞現有程式的工作，但是新的程式可以藉由新特性得到更好的速度。
HTTP/2 保留了 HTTP/1.1 的大部分語義，例如請求方法、狀態碼乃至URI和絕大多數HTTP頭部欄位一致。而 HTTP/2 採用了新的方法來編碼、傳輸客戶端——伺服器間的數據。
HTTP/1.1與SPDY的區別
主條目：SPDY
- 實現無需先入先出的多路復用
- 為簡化客戶端和伺服器開發的訊息—幀機制
- 強制性壓縮（包括HTTP頭部）
- 優先權排序
- 雙向通訊
HTTP/2與SPDY的比較
HTTP/2的開發基於SPDY進行躍進式改進。在諸多修改中，最顯著的改進在於，HTTP/2使用了一份經過定製的壓縮算法，基於霍夫曼編碼，以此替代了SPDY的動態流壓縮算法，以避免對協定的Oracle攻擊——這一類攻擊以CRIME為代表。此外，HTTP/2禁用了諸多加密包，以保證基於TLS的連線的前向安全。
新特性
在 HTTP/2 的第一版草案（對 SPDY 協定的復刻）中，新增的性能改進不僅包括HTTP/1.1中已有的多路復用，修復隊頭阻塞問題，允許設定設定請求優先權，還包含了一個頭部壓縮算法(HPACK)。此外， HTTP/2 採用了二進制而非明文來打包、傳輸客戶端—伺服器間的數據。
幀、訊息、流和TCP連線
有別於HTTP/1.1在連線中的明文請求，HTTP/2與SPDY一樣，將一個TCP連線分為若干個流（Stream），每個流中可以傳輸若干訊息（Message），每個訊息由若干最小的二進制幀（Frame）組成。這也是HTTP/1.1與HTTP/2最大的區別所在。 HTTP/2中，每個用戶的操作行為被分配了一個流編號(stream ID)，這意味著用戶與服務端之間創建了一個TCP通道；協定將每個請求分割為二進制的控制幀與數據幀部分，以便解析。這個舉措在SPDY中的實踐表明，相比HTTP/1.1，新頁面載入可以加快11.81% 到 47.7%
HPACK 算法
HPACK算法是新引入HTTP/2的一個算法，用於對HTTP頭部做壓縮。其原理在於：
- 客戶端與服務端根據RFC 7541的附錄A，維護一份共同的靜態字典（Static Table），其中包含了常見頭部名及常見頭部名稱與值的組合的代碼；
- 客戶端和服務端根據先入先出的原則，維護一份可動態添加內容的共同動態字典（Dynamic Table）；
- 客戶端和服務端根據RFC 7541的附錄B，支持基於該靜態哈夫曼碼錶的哈夫曼編碼（Huffman Coding）。
伺服器推送
網站為了使請求數減少，通常採用對頁面上的圖片、腳本進行極簡化處理。但是，這一舉措十分不方便，也不高效，依然需要諸多HTTP連結來載入頁面和頁面資源。
HTTP/2引入了伺服器推送，即服務端向客戶端傳送比客戶端請求更多的數據。這允許伺服器直接提供瀏覽器渲染頁面所需資源，而無須瀏覽器在收到、解析頁面後再提起一輪請求，節約了載入時間。
瀏覽器支持
截至2015年末，主要的瀏覽器的最新版本已經支持HTTP/2這一協定。其中：
- Internet Explorer自IE 11開始支持HTTP/2，並預設激活。
h2c的支持度
HTTP/2 的設計本身允許非加密的 HTTP 協定，也允許使用TLS 1.2或更新版本協定進行加密。協定本身未要求必須使用加密，惟多數客戶端 (例如 Firefox,Chrome, Safari, Opera, IE, Edge) 的開發者聲明，他們只會實現通過TLS加密的HTTP/2協定，這使得經TLS加密的HTTP/2(即h2)成為了事實上的強制標準，而h2c事實上被主流瀏覽器廢棄。
SPDY 退出歷史舞台
2015年9月，Google 宣布了計畫，移除對SPDY的支持，擁抱 HTTP/2，並將在Chrome 51中生效。
HTTP/2 的實現
HTTP/2 工作組在其官方 Github 上羅列了諸多已經支持該協定的代碼實現。
批評與爭議
HTTP/2的開發過程乃至協定本身都曾受到批評。
針對協定開發本身
FreeBSD和Varnish cache的開發者保羅-恆寧·坎瀑批評稱，這個標準檔案的準備過程短得不切實際，而且未基於除了SPDY之外的任何協定，以至於其他協定失去了對草案進行改進的機會。Kampala批評說，這個協定本身與HTTP不一致，而且還毫無必要地變得極為複雜。他還認為，這個協定違背了網際網路協定的分層原則，例如說，將本屬於TCP傳輸層的流控制(flow control)功能放入了協定中。
針對加密的爭議
一開始，以HTTP工作組某位主席為首的成員在郵件列表建議引入強制使用TLS協定實現的HTTP/2.0（Mandatory TLS in HTTP/2.0），這招致了爭議。批評者認為，加密增加了十分不必要的開銷，而且很多HTTP服務實際上無需加密，提供者也無意為此花費更多的資源。而支持者認為，實踐中TLS加密的開銷微不足道。
Poul-Henning Kamp 批評IETF在制定HTTP/2時，遵循了一個特定的“政治議程”（political agenda），壓縮了討論的空間。
強制加密議程的批評者認為，其基於現有的證書框架，對於開源社區並非新創造，亦不是獨特的。2013年，一位思科員工表示，現有證書模型與路由器一類的小型化設備並不兼容，因為現有的證書框架需要為每張證書付出不可避免的成本，還需要進行每年更新的流程。工作組最終未能在強制加密這一點上達成一致，但是大部分客戶端只實現了基於TLS的HTTP/2，使之成為事實標準。
