去年年底，據國際互聯網工程任務組（ IETF ）消息，HTTP－over－QUIC 實驗性協議將被重命名為 HTTP／3，即有望成為 HTTP 協議的第三個正式版本，也就是說HTTP／3可能要來了。 該消息是如此的惹人注目，是因為HTTP是我們身邊的協議，Web應用都離不開它。

溫故知新，梳理一下過往，或許更能夠理解未來。

HTTP1．x的過往

HTTP協議大約誕生在我上大一的時候，好像是HTTP0．9，客戶端請求和服務器響應都是ascii碼，客戶端以回車符結尾，服務器返回HTML。后來的HTTP1．0，服務器響應增加了很多狀態，請求和響應也多了很多的header，響應的內容也不再局限于純文本了。

HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型，是一個無狀態的協議。HTTP是建立在TCP之上的，每個請求都要經歷三次握手和慢啟動。客戶端是依據域名來向服務器建立連接，一般PC端的瀏覽器支持同域6～8個連接，手機端的連接數則一般控制在4～6個。連接數不是越多越好，資源開銷和整體延遲都會隨之增大。

HTTP 1．1 導致了2000年的互聯網熱潮。HTTP1．1 支持只發送header信息（不帶任何body信息），如果服務器認為客戶端有權限請求服務器，則返回100，否則返回401。客戶端如果接受到100，才開始把請求body發送到服務器。這樣當服務器返回401的時候，客戶端就可以不用發送請求body了，節約了帶寬。

另外HTTP還支持傳送內容的一部分。這樣當客戶端已經有一部分的資源后，只需要跟服務器請求另外的部分資源即可。RANGE：bytes是HTTP／1．1新增內容，HTTP／1．0每次傳送文件都是從文件頭開始，即0字節處開始。RANGE：bytes＝XXX表示要求服務器從文件XXX字節處開始傳送，這大概就是平時所說的斷點續傳。

相關的部分協議標準如下：

協議編號 協議名稱簡要描述RFC7230 HTTP／1．1： Message Syntax and Routing底層消息解析和連接管理等RFC7231HTTP／1．1： Semantics and Content方法、狀態碼和header等RFC7232HTTP／1．1： Conditional Requests例如If－Modified－SinceRFC7233HTTP／1．1： Range Requests獲取部分內容等RFC7234HTTP／1．1： Caching瀏覽器和中介緩存等RFC7235HTTP／1．1： AuthenticationHTTP 的一個authentication框架等

現如今，Web應用不再單純是web 網頁，還有支持多設備和多媒體。 一個SPA的應用可能有上百的連接，模塊拆分導致了更多的請求，大部分時間都消耗在網絡上。HTTP 1．x header 往往較大，且無法壓縮。TCP協議利用過低，不可復用連接，連接數限制且協議過于龐大。

[page][/page]

HTTP1．x遇到的問題和解決方案

HTTP1．x主要存在連接無法復用和head of line blocking這兩個問題。在第一個請求沒有收到回復之前，后續從應用層發出的請求只能排隊。網絡通暢的時候性能影響不大，一旦第一個請求沒有抵達服務器，或者response因為網絡阻塞沒有及時返回，就會影響所有后續請求。

HTTP1．0協議頭里可以設置Connection：Keep－Alive。在header里設置Keep－Alive可以在一定時間內復用連接，具體復用時間的長短可以由服務器控制，一般在15秒左右，這與運營商蜂窩網絡的linger time相關。HTTP1．1之后Connection的默認值就是Keep－Alive，如果要關閉連接復用需要顯式的設置Connection：Close。這對PC端瀏覽器的體驗幫助很大，因為大部分的請求在集中在一小段時間以內。但移動app的請求比較分散且時間跨度相對較大，一般會從應用層尋求其它解決方案，長連接方案或者偽長連接方案。

為了解決HTTP連接復用，可以采用長輪詢，HTTP streaming和websocket等方式。

和傳統的HTTP短鏈接相比，長連接輪詢會在用戶增長的時候極大的增加服務器壓力。移動端網絡環境復雜，像wifi和4g的網絡切換等，這些場景都需要考慮重建連接。長輪詢方式穩定性并不好，需要做好數據可靠性的保證，比如重發和ack機制。而且，response有可能會被中間代理cache住，要處理好業務數據的過期機制。

HTTP streaming是通過在server response的頭部里增加＂Transfer Encoding： chunked＂來告訴客戶端后續還會有新的數據。如果永遠不會結束，客戶端就會一直處于等待response的過程中。代理服務器會等待服務器的response結束之后才會將結果推送到請求客戶端。對于streaming這種業務數據無法按照請求來做分割，所以客戶端每收到一塊數據都需要自己做協議解析。顯然這個數據通道也是單向的，還有個缺陷就是不會產生重復的header數據。

websocket提供雙向的數據通道，優勢在于提供了message的概念，比基于字節流的tcp socket使用更簡單，同時又提供了傳統的HTTP所缺少的長連接功能。但代價相對較高，基于tcp的socket編程技術難度相對復雜很多，而且需要自己制定協議。

HTTP／2 要點

HTTP2．0是以SPDY為原型進行討論和標準化的，采用二進制格式傳輸數據，而非 HTTP／1．x 的文本格式。請求和響應都統一為流，對消息頭采用 HPACK 進行壓縮傳輸，能夠節省消息頭占用的網絡的流量。多路復用，就是所有的請求都是通過一個 TCP 連接并發完成，并支持Server Push和基于優先級的流量控制。

HTTP／2 中的幀

幀（frame）是HTTP2中最小的通信單位，每個幀都會有幀header，每個幀用來承載HTTP header 或負荷數據，或其他特定類型的幀。幀是遵循二進制編碼的。幀格式如下：

length定義了整個幀的長度，type定義幀主要有10種的類型：

幀類型
codeDATA0x0HEADERS0x1PRIORITY0x2
RSTSTREAM0x3PUSHPROMISE0x4S
ETTINGS0x5PING0x6GOAWAY0x7WIN
DOW＿UPDATE0x8CONTINUATION0x9

flags用位定義了一些重要的參數，stream id用作流控制，而payload才是請求的正文。

雖然協議的格式和HTTP1．x完全不同了，但并沒有改變HTTP1．x的語義，只是把原來HTTP1．x的header和body部分用frame重新封裝了一層而已。調試的時候瀏覽器甚至會把HTTP2．0的frame自動還原成HTTP1．x的格式。HTTP2．0與HTTP1．0的對比如下：

[page][/page]

HTTP／2 中的header 壓縮

HTTP1．x的header由于cookie和user agent很容易變得較大，而且每次都要重復發送。HTTP／2使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。高效的壓縮算法可以很大的壓縮header，減少發送包的數量從而降低延遲。

HTTP／2中的HPACK使用一份索引表來定義常用的 HTTP Header，保留原有的header list的順序，通過索引鍵值壓縮。 靜態表中包含了一些預定義的header字段，動態表默認是空的，會在頭部解壓縮的時候確定是否添加entry。客戶端和服務器端使用header表來跟蹤和存儲之前發送的每一個鍵值對。在tcp連接期間，二者共同維護和更新。對于無法用索引替代的字符，有的會采用哈夫曼編碼壓縮。

HTTP／2 中的多路復用

把HTTP 消息分解為獨立的幀，交錯發送，然后在另一端根據Stream ID 重新組裝是HTTP 2．0 最重要的一項增強。每個 Frame Header 都有一個 Stream ID。每次請求／響應使用不同的 Stream ID。通過 Stream ID 標識，所有的請求和響應都可以同時跑在一個TCP 連接上了。 下圖是 HTTP 和 spdy的并發模型對比：

和一般TCP連接釋放一樣，如果客戶端沒有數據要請求，或服務端數據發送完畢后，會主動發送關閉連接的報文。或者是服務端連續發送探測報文，客戶端無響應，服務端就關閉了這個連接。

當流并發時，就會涉及到流的優先級和依賴。優先級高的流會被優先發送。每個HTTP／2流里面可以帶有優先級（31位，0為優先級最高）的值，這個值確定著客戶端和服務器處理不同的流采取不同的優先級策略，高優先級的流都應該優先發送。圖片請求的優先級要低于CSS和SCRIPT腳本，這可以確保重要的東西可以被優先加載。，但又不會絕對的，絕對地遵守可能又會引入隊列阻塞的問題：高優先級的請求慢導致阻塞其他資源交付。

從tcp連接和網絡來看，優先級使得網絡擁塞得到改善，慢啟動時間減少，擁塞和丟包恢復速度變快。

HTTP／2 中的Push

Server Push 就是服務器向客戶端推送資源而無需客戶端明確地請求，或者服務器可以對一個客戶端請求發送多個響應。

當服務端需要主動推送某個資源時，便會發送一個 Frame Type 為 PUSH＿PROMISE 的 幀，里面帶了 PUSH 需要新建的 Stream ID。客戶端解析 幀時，發現它是一個 PUSH＿PROMISE 類型，便會準備接收服務端要推送的流。

HTTP／2連接建立后，客戶端與服務器交換SETTINGS 幀，以此來限定雙向并發流的最大數量。因此，客戶端可以限定推送流的數量，或者通過把這個值設置為0，完全禁用服務器推送，而且，所有推送的資源都遵守同源策略。服務器不能隨便將第三方資源推送給客戶端，而必須是經過雙方確認才行。

所有服務器推送流都由PUSH＿PROMISE 發起，PUSH＿PROMISE 幀必須在返回響應之前發送，以免客戶端出現競態條件。客戶端接收到PUSH＿PROMISE 幀之后，可以視自身需求選擇拒絕這個流。

[page][/page]

基于HTTP／2的開發

HTTP／2 已經得到了較為廣泛的支持，服務器的支持包括：

Apache HTTP Server 2．4．17＋

Apache Tomcat 8．5＋

NGINX 1．9．5＋

面向PHP的Swoole

面向Python 的Twisted

．．．

支持HTTP／2的客戶端包括：

Chromium

Mozilla Firefox

curl and libcurl

OkHTTP （java ，Android）

面向Obj－C／swift 的 WKWebView

．．．

客戶端與服務器同時支持HTTP／2的包括：

Jetty／Netty

lua－HTTP

Node．js 8．4．0＋

面向perl 的 Protocol：：HTTP2

面向Go 的HTTP2

．．．

支持HTTP／2的代理中介包括：

HAProxy

ngHTTP2

GFE

．．．

詳情可以參考HTTPs：／／github．com／HTTP2／HTTP2－spec／wiki／Implementations。

調試工具可以使用chrome的瀏覽器以及Wireshark等等。

在開發中使用了HTTP／2 并不是萬事大吉了，在HTTP1．X 中的一些優化還需要繼續使用，例如減少DNS查詢和重定向，CDN的使用，對代碼、圖片等資源的壓縮，對文本開啟GZip，以及使用HTTP的緩存機制（Expires／Cache－Control和Last－Modified ／ ETag）等等。對于那些可以感知緩存的資源內聯或者Push 消息，可以利用cookie 協助用戶標記。

由于HTTP／2基于單個TCP連接，容易受到 Head of Line Blocking 的影響，從而導致傳輸速度受限，還會受到TCP丟包的影響，所以HTTP／2在資源數量較少的網站可能效果不明顯。TCP協議的升級依賴于操作系統內核的升級，尤其是網絡操作系統的升級往往不可控，因此業界開始重新審視UDP， HTTP／3 所使用的QUIC 就是基于UDP協議的。

HTTP／3 何時才能實施呢？整個互聯網支持HTTP／3 可能還需要一段不短的時間吧！

參考資料：

《HTTP 權威指南》

RFC 7540 － Hypertext Transfer Protocol Version 2 （HTTP／2）

RFC 7541 － HPACK： Header Compression for HTTP／2