Can you summarize the following document?
        
  協議制定伊始,工作組章程關注了下列目標和受關心的問題:  Facebook對各方案進行了評價並最終推薦了SPDY協議。HTTP 2.0的首個草稿於2012年11月釋出,其內容基本和SPDY協議相同。

  

  HTTP/2 相比 HTTP/1.1 的修改並不會破壞現有程式的工作,但是新的程式可以藉由新特性得到更好的速度。  HTTP/2 保留了 HTTP/1.1 的大部分語義,例如請求方法、狀態碼乃至URI和絕大多數HTTP頭部欄位一致。而 HTTP/2 採用了新的方法來編碼、傳輸 客戶端<——>伺服器 間的資料。

  SPDY (發音為"speedy") 是一個由 Google 主導的研究專案發明的HTTP替代協議。SPDY一開始主要關注降低延遲,採用了TCP通道,但是使用了不同的協議來達到此目的。其與HTTP/1.1相比,主要的改變有:

  HTTP/2的開發基於SPDY進行躍進式改進。在諸多修改中,最顯著的改進在於,HTTP/2使用了一份經過定製的壓縮演算法,基於霍夫曼編碼,以此替代了SPDY的動態流壓縮演算法,以避免對協議的Oracle攻擊——這一類攻擊以CRIME為代表。此外,HTTP/2禁用了諸多加密套件,以保證基於TLS的連線的前向安全。

  在 HTTP/2 的第一版草案(對 SPDY 協議的復刻)中,新增的效能改進不僅包括HTTP/1.1中已有的多路複用,修復隊頭阻塞問題,允許設定設定請求優先順序,還包含了一個頭部壓縮演算法(HPACK)。此外, HTTP/2 採用了二進位制而非明文來打包、傳輸 客戶端<——>伺服器 間的資料。

  有別於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演算法是新引入HTTP/2的一個演算法,用於對HTTP頭部做壓縮。其原理在於:

  網站為了使請求數減少,通常採用對頁面上的圖片、指令碼進行極簡化處理。但是,這一舉措十分不方便,也不高效,依然需要諸多HTTP連結來載入頁面和頁面資源。  HTTP/2引入了伺服器推送,即服務端向客戶端傳送比客戶端請求更多的資料。這允許伺服器直接提供瀏覽器渲染頁面所需資源,而無須瀏覽器在收到、解析頁面後再提起一輪請求,節約了載入時間。

  截至2015年末,主要的瀏覽器的最新版本已經支援HTTP/2這一協議。其中:

  HTTP/2 的設計本身允許非加密的 HTTP 協議,也允許使用 TLS 1.2 或更新版本協議進行加密。協議本身未要求必須使用加密,<ref name="HTTP/2 Frequently Asked Questions"></ref> 惟多數客戶端 (例如 Firefox, Chrome, Safari, Opera, IE, Edge) 的開發者宣告,他們只會實現通過TLS加密的HTTP/2協議,這使得經TLS加密的HTTP/2(即h2)成為了"事實上的"強制標準,而h2c事實上被主流瀏覽器廢棄。

  2015年9月,Google 宣佈了計劃,移除對SPDY的支援,擁抱 HTTP/2,並將在Chrome 51中生效。

  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,使之成為事實標準。  HTTP/2也被批評未能支援機會性加密,即類似SMTP中存在已久的STARTTLS一樣能抵禦被動監控的措施。 批評者指出,HTTP/2的提議違背了IETF自身制定的《最佳實踐 188》(BCP 188) 即 RFC 7258。這份檔案指出,被動監控應被當作一種攻擊,IETF指定的標準應當設定抵禦這種攻擊的措施(例如機會性加密)。目前,已經有一系列機會性加密規範被提出,工作組也制定了 draft-ietf-httpbis-http2-encryption-01 這一官方版方案。
HTTP/2(超文字傳輸協議第2版,最初命名為HTTP 2.0),簡稱為h2(基於TLS/1.2或以上版本的加密連線)或h2c(非加密連線),是HTTP協議的的第二個主要版本,使用於全球資訊網。