去年年底，據(jù)國際互聯(lián)網(wǎng)工程任務(wù)組（ IETF ）消息，HTTP－over－QUIC 實(shí)驗(yàn)性協(xié)議將被重命名為 HTTP／3，即有望成為 HTTP 協(xié)議的第三個(gè)正式版本，也就是說HTTP／3可能要來了。 該消息是如此的惹人注目，是因?yàn)镠TTP是我們身邊的協(xié)議，Web應(yīng)用都離不開它。

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

HTTP1．x的過往

HTTP協(xié)議大約誕生在我上大一的時(shí)候，好像是HTTP0．9，客戶端請求和服務(wù)器響應(yīng)都是ascii碼，客戶端以回車符結(jié)尾，服務(wù)器返回HTML。后來的HTTP1．0，服務(wù)器響應(yīng)增加了很多狀態(tài)，請求和響應(yīng)也多了很多的header，響應(yīng)的內(nèi)容也不再局限于純文本了。

HTTP是一個(gè)應(yīng)用層協(xié)議，由請求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型，是一個(gè)無狀態(tài)的協(xié)議。HTTP是建立在TCP之上的，每個(gè)請求都要經(jīng)歷三次握手和慢啟動(dòng)?？蛻舳耸且罁?jù)域名來向服務(wù)器建立連接，一般PC端的瀏覽器支持同域6～8個(gè)連接，手機(jī)端的連接數(shù)則一般控制在4～6個(gè)。連接數(shù)不是越多越好，資源開銷和整體延遲都會(huì)隨之增大。

HTTP 1．1 導(dǎo)致了2000年的互聯(lián)網(wǎng)熱潮。HTTP1．1 支持只發(fā)送header信息（不帶任何body信息），如果服務(wù)器認(rèn)為客戶端有權(quán)限請求服務(wù)器，則返回100，否則返回401。客戶端如果接受到100，才開始把請求body發(fā)送到服務(wù)器。這樣當(dāng)服務(wù)器返回401的時(shí)候，客戶端就可以不用發(fā)送請求body了，節(jié)約了帶寬。

另外HTTP還支持傳送內(nèi)容的一部分。這樣當(dāng)客戶端已經(jīng)有一部分的資源后，只需要跟服務(wù)器請求另外的部分資源即可。RANGE：bytes是HTTP／1．1新增內(nèi)容，HTTP／1．0每次傳送文件都是從文件頭開始，即0字節(jié)處開始。RANGE：bytes＝XXX表示要求服務(wù)器從文件XXX字節(jié)處開始傳送，這大概就是平時(shí)所說的斷點(diǎn)續(xù)傳。

相關(guān)的部分協(xié)議標(biāo)準(zhǔn)如下：

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

現(xiàn)如今，Web應(yīng)用不再單純是web 網(wǎng)頁，還有支持多設(shè)備和多媒體。 一個(gè)SPA的應(yīng)用可能有上百的連接，模塊拆分導(dǎo)致了更多的請求，大部分時(shí)間都消耗在網(wǎng)絡(luò)上。HTTP 1．x header 往往較大，且無法壓縮。TCP協(xié)議利用過低，不可復(fù)用連接，連接數(shù)限制且協(xié)議過于龐大。

[page][/page]

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

HTTP1．x主要存在連接無法復(fù)用和head of line blocking這兩個(gè)問題。在第一個(gè)請求沒有收到回復(fù)之前，后續(xù)從應(yīng)用層發(fā)出的請求只能排隊(duì)。網(wǎng)絡(luò)通暢的時(shí)候性能影響不大，一旦第一個(gè)請求沒有抵達(dá)服務(wù)器，或者response因?yàn)榫W(wǎng)絡(luò)阻塞沒有及時(shí)返回，就會(huì)影響所有后續(xù)請求。

HTTP1．0協(xié)議頭里可以設(shè)置Connection：Keep－Alive。在header里設(shè)置Keep－Alive可以在一定時(shí)間內(nèi)復(fù)用連接，具體復(fù)用時(shí)間的長短可以由服務(wù)器控制，一般在15秒左右，這與運(yùn)營商蜂窩網(wǎng)絡(luò)的linger time相關(guān)。HTTP1．1之后Connection的默認(rèn)值就是Keep－Alive，如果要關(guān)閉連接復(fù)用需要顯式的設(shè)置Connection：Close。這對(duì)PC端瀏覽器的體驗(yàn)幫助很大，因?yàn)榇蟛糠值恼埱笤诩性谝恍《螘r(shí)間以內(nèi)。但移動(dòng)app的請求比較分散且時(shí)間跨度相對(duì)較大，一般會(huì)從應(yīng)用層尋求其它解決方案，長連接方案或者偽長連接方案。

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

和傳統(tǒng)的HTTP短鏈接相比，長連接輪詢會(huì)在用戶增長的時(shí)候極大的增加服務(wù)器壓力。移動(dòng)端網(wǎng)絡(luò)環(huán)境復(fù)雜，像wifi和4g的網(wǎng)絡(luò)切換等，這些場景都需要考慮重建連接。長輪詢方式穩(wěn)定性并不好，需要做好數(shù)據(jù)可靠性的保證，比如重發(fā)和ack機(jī)制。而且，response有可能會(huì)被中間代理cache住，要處理好業(yè)務(wù)數(shù)據(jù)的過期機(jī)制。

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

websocket提供雙向的數(shù)據(jù)通道，優(yōu)勢在于提供了message的概念，比基于字節(jié)流的tcp socket使用更簡單，同時(shí)又提供了傳統(tǒng)的HTTP所缺少的長連接功能。但代價(jià)相對(duì)較高，基于tcp的socket編程技術(shù)難度相對(duì)復(fù)雜很多，而且需要自己制定協(xié)議。

HTTP／2 要點(diǎn)

HTTP2．0是以SPDY為原型進(jìn)行討論和標(biāo)準(zhǔn)化的，采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP／1．x 的文本格式。請求和響應(yīng)都統(tǒng)一為流，對(duì)消息頭采用 HPACK 進(jìn)行壓縮傳輸，能夠節(jié)省消息頭占用的網(wǎng)絡(luò)的流量。多路復(fù)用，就是所有的請求都是通過一個(gè) TCP 連接并發(fā)完成，并支持Server Push和基于優(yōu)先級(jí)的流量控制。

HTTP／2 中的幀

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

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

幀類型
codeDATA0x0HEADERS0x1PRIORITY0x2
RSTSTREAM0x3PUSHPROMISE0x4S
ETTINGS0x5PING0x6GOAWAY0x7WIN
DOW＿UPDATE0x8CONTINUATION0x9

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

雖然協(xié)議的格式和HTTP1．x完全不同了，但并沒有改變HTTP1．x的語義，只是把原來HTTP1．x的header和body部分用frame重新封裝了一層而已。調(diào)試的時(shí)候?yàn)g覽器甚至?xí)袶TTP2．0的frame自動(dòng)還原成HTTP1．x的格式。HTTP2．0與HTTP1．0的對(duì)比如下：

[page][/page]

HTTP／2 中的header 壓縮

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

HTTP／2中的HPACK使用一份索引表來定義常用的 HTTP Header，保留原有的header list的順序，通過索引鍵值壓縮。 靜態(tài)表中包含了一些預(yù)定義的header字段，動(dòng)態(tài)表默認(rèn)是空的，會(huì)在頭部解壓縮的時(shí)候確定是否添加entry?？蛻舳撕头?wù)器端使用header表來跟蹤和存儲(chǔ)之前發(fā)送的每一個(gè)鍵值對(duì)。在tcp連接期間，二者共同維護(hù)和更新。對(duì)于無法用索引替代的字符，有的會(huì)采用哈夫曼編碼壓縮。

HTTP／2 中的多路復(fù)用

把HTTP 消息分解為獨(dú)立的幀，交錯(cuò)發(fā)送，然后在另一端根據(jù)Stream ID 重新組裝是HTTP 2．0 最重要的一項(xiàng)增強(qiáng)。每個(gè) Frame Header 都有一個(gè) Stream ID。每次請求／響應(yīng)使用不同的 Stream ID。通過 Stream ID 標(biāo)識(shí)，所有的請求和響應(yīng)都可以同時(shí)跑在一個(gè)TCP 連接上了。 下圖是 HTTP 和 spdy的并發(fā)模型對(duì)比：

和一般TCP連接釋放一樣，如果客戶端沒有數(shù)據(jù)要請求，或服務(wù)端數(shù)據(jù)發(fā)送完畢后，會(huì)主動(dòng)發(fā)送關(guān)閉連接的報(bào)文?；蛘呤欠?wù)端連續(xù)發(fā)送探測報(bào)文，客戶端無響應(yīng)，服務(wù)端就關(guān)閉了這個(gè)連接。

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

從tcp連接和網(wǎng)絡(luò)來看，優(yōu)先級(jí)使得網(wǎng)絡(luò)擁塞得到改善，慢啟動(dòng)時(shí)間減少，擁塞和丟包恢復(fù)速度變快。

HTTP／2 中的Push

Server Push 就是服務(wù)器向客戶端推送資源而無需客戶端明確地請求，或者服務(wù)器可以對(duì)一個(gè)客戶端請求發(fā)送多個(gè)響應(yīng)。

當(dāng)服務(wù)端需要主動(dòng)推送某個(gè)資源時(shí)，便會(huì)發(fā)送一個(gè) Frame Type 為 PUSH＿PROMISE 的 幀，里面帶了 PUSH 需要新建的 Stream ID?？蛻舳私馕?幀時(shí)，發(fā)現(xiàn)它是一個(gè) PUSH＿PROMISE 類型，便會(huì)準(zhǔn)備接收服務(wù)端要推送的流。

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

所有服務(wù)器推送流都由PUSH＿PROMISE 發(fā)起，PUSH＿PROMISE 幀必須在返回響應(yīng)之前發(fā)送，以免客戶端出現(xiàn)競態(tài)條件。客戶端接收到PUSH＿PROMISE 幀之后，可以視自身需求選擇拒絕這個(gè)流。

[page][/page]

基于HTTP／2的開發(fā)

HTTP／2 已經(jīng)得到了較為廣泛的支持，服務(wù)器的支持包括：

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

．．．

客戶端與服務(wù)器同時(shí)支持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。

調(diào)試工具可以使用chrome的瀏覽器以及Wireshark等等。

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

由于HTTP／2基于單個(gè)TCP連接，容易受到 Head of Line Blocking 的影響，從而導(dǎo)致傳輸速度受限，還會(huì)受到TCP丟包的影響，所以HTTP／2在資源數(shù)量較少的網(wǎng)站可能效果不明顯。TCP協(xié)議的升級(jí)依賴于操作系統(tǒng)內(nèi)核的升級(jí)，尤其是網(wǎng)絡(luò)操作系統(tǒng)的升級(jí)往往不可控，因此業(yè)界開始重新審視UDP， HTTP／3 所使用的QUIC 就是基于UDP協(xié)議的。

HTTP／3 何時(shí)才能實(shí)施呢？整個(gè)互聯(lián)網(wǎng)支持HTTP／3 可能還需要一段不短的時(shí)間吧！

參考資料：

《HTTP 權(quán)威指南》

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

RFC 7541 － HPACK： Header Compression for HTTP／2