一文串聯(lián) HTTP / [ 0.9 | 1.0 | 1.1 | 2 | 3 ]
本文轉(zhuǎn)載自微信公眾號「前端日志」，作者 孟思行 。轉(zhuǎn)載本文請聯(lián)系前端日志公眾號。 孟思行
1989 年，萬維網(wǎng)誕生之后，HTTP 迅速成為主導世界的應(yīng)用層協(xié)議。在今天，幾乎任何場景都或多或少用到了 HTTP 協(xié)議。
在 30 多年的歷史中，HTTP 協(xié)議本身有比較大的發(fā)展，同時，還有一些重大的變動也在醞釀之中。這些演化使得這個協(xié)議的表現(xiàn)力更強，性能更好，更能滿足日新月異的應(yīng)用需求。本文就來回顧和展望一下 HTTP 的歷史和未來。
- HTTP/0.9
- HTTP/1.0
- HTTP/1.1
- HTTP/2
- HTTP/3
HTTP/0.9
HTTP/0.9 誕生于 1991 年，是 HTTP 協(xié)議的最初版，構(gòu)造十分簡單：
- 請求端只支持 GET 請求
- 響應(yīng)端只能返回 HTML 文本數(shù)據(jù)
- GET /index.html
- <html>
- <body>
- Hello World
- </body>
- </html>
請求示意圖如下：
HTTP/0.9
可以看到，HTTP/0.9 只能發(fā)送 GET 請求，且每一個請求都單獨創(chuàng)建一個 TCP 連接，響應(yīng)端只能返回 HTML 格式的數(shù)據(jù)，響應(yīng)完成之后 TCP 請求斷開。
這樣的請求方式雖然能夠滿足當時的使用需求，但也還是暴露出了一些問題。
HTTP/0.9 痛點：
- 請求方式唯一，返回格式唯一
- TCP 連接無法復(fù)用
HTTP/1.0
HTTP/1.0 誕生于 1996 年，它在 HTTP/0.9 的基礎(chǔ)上，增加了 HTTP 頭部字段，極大擴展了 HTTP 的使用場景。這個版本的 HTTP 不僅可以傳輸文字，還能傳輸圖像、視頻、二進制文件，為互聯(lián)網(wǎng)的迅速發(fā)展奠定了堅實的基礎(chǔ)。
核心特點如下：
- 請求端增加 HTTP 協(xié)議版本，響應(yīng)端增加狀態(tài)碼。
- 請求方法增加 POST、HEAD。
- 請求端和響應(yīng)端增加頭部字段。
- Content-Type 讓響應(yīng)數(shù)據(jù)不只限于超文本。
- Expires、Last-Modified 緩存頭。
- Authorization 身份認證。
- Connection: keep-alive 支持長連接，但非標準。
- GET /mypage.html HTTP/1.0
- User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
- 200 OK
- Date: Tue, 15 Nov 1994 08:12:31 GMT
- Server: CERN/3.0 libwww/2.17
- Content-Type: text/html
- <html>
- <body>
- Hello World
- </body>
- </html>
請求示意圖如下：
HTTP/1.0
可以看到，HTTP/1.0 擴展了請求方法和響應(yīng)狀態(tài)碼，并且支持定義 HTTP 頭部字段，通過 Content-Type 頭，我們就能傳輸任何格式的數(shù)據(jù)了。同時可以看出，HTTP/1.0 仍然是一個請求對應(yīng)一個 TCP 連接，不能形成復(fù)用。
HTTP/1.0 痛點：
- TCP 連接無法復(fù)用。
- HTTP 隊頭阻塞，一個 HTTP 請求響應(yīng)結(jié)束之后，才能發(fā)起下一個 HTTP 請求。
- 一臺服務(wù)器只能提供一個 HTTP 服務(wù)。
HTTP/1.1
HTTP/1.1 誕生于 1999 年，它進一步完善了 HTTP 協(xié)議，一直用到了 20 多年后的今天，仍然是使用最廣的 HTTP 版本。
核心特點如下：
- 持久連接。
- HTTP/1.1 默認開啟持久連接，在 TCP 連接建立后不立即關(guān)閉，讓多個 HTTP 請求得以復(fù)用。
- 管線化技術(shù)。
- HTTP/1.1 中，多個 HTTP 請求不用排隊發(fā)送，可以批量發(fā)送，這就解決了 HTTP 隊頭阻塞問題。但批量發(fā)送的 HTTP 請求，必須按照發(fā)送的順序返回響應(yīng)，相當于問題解決了一半，仍然不是最佳體驗。
- 支持響應(yīng)分塊。
- HTTP/1.1 實現(xiàn)了流式渲染，響應(yīng)端可以不用一次返回所有數(shù)據(jù)，可以將數(shù)據(jù)拆分成多個模塊，產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊數(shù)據(jù)，這樣客戶端就可以同步對數(shù)據(jù)進行處理，減少響應(yīng)延遲，降低白屏時間。
- Bigpipe 的實現(xiàn)就是基于這個特性，具體是通過定義 Transfer-Encoding 頭來實現(xiàn)的。
- 增加 Host 頭。
- HTTP/1.1 實現(xiàn)了虛擬主機技術(shù)，將一臺服務(wù)器分成若干個主機，這樣就可以在一臺服務(wù)器上部署多個網(wǎng)站了。
- 通過配置 Host 的域名和端口號，即可支持多個 HTTP 服務(wù)：Host:
:
- 其他擴展。
- 增加 Cache-Control、E-Tag 緩存頭。
- 增加 PUT、PATCH、HEAD、 OPTIONS、DELETE 請求方法。
- GET /en-US/docs/Glossary/Simple_header HTTP/1.1
- Host: developer.mozilla.org
- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
- Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
- Accept-Language: en-US,en;q=0.5
- Accept-Encoding: gzip, deflate, br
- Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
- 200 OK
- Connection: Keep-Alive
- Content-Encoding: gzip
- Content-Type: text/html; charset=utf-8
- Date: Wed, 20 Jul 2016 10:55:30 GMT
- Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
- Keep-Alive: timeout=5, max=1000
- Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
- Server: Apache
- Transfer-Encoding: chunked
- Vary: Cookie, Accept-Encoding
- <html>
- <body>
- Hello World
- </body>
- </html>
請求示意圖如下：
HTTP/1.1
可以看到，HTTP/1.1 可以并行發(fā)起多個請求，并且也能復(fù)用同一個 TCP 連接，傳輸效率得到了提升。但響應(yīng)端只能按照發(fā)送的順序進行返回，為此很多瀏覽器會為每個域名至多打開 6 個連接，用增加隊列的方式減少 HTTP 隊頭阻塞。
HTTP/1.1 痛點：
- HTTP 隊頭阻塞沒有徹底解決，響應(yīng)端必須按照 HTTP 的發(fā)送順序進行返回，如果排序靠前的響應(yīng)特別耗時，則會阻塞排序靠后的所有響應(yīng)。
HTTP/2
HTTP/2 誕生于 2015 年，它的最大的特點是 All in 二進制，基于二進制的特性，對 HTTP 傳輸效率進行了深度優(yōu)化。
HTTP/2 將一個 HTTP 請求劃分為 3 個部分：
- 幀：一段二進制數(shù)據(jù)，是 HTTP/2 傳輸?shù)淖钚挝弧?/li>
- 消息：一個請求或響應(yīng)對應(yīng)的一個或多個幀。
- 數(shù)據(jù)流：已建立的連接內(nèi)的雙向字節(jié)流，可以承載一條或多條消息。
HTTP/2 數(shù)據(jù)流、消息和幀
圖中可以看到，一個 TCP 連接上有多個數(shù)據(jù)流，一個數(shù)據(jù)流承載著雙向消息，一條消息包含了多個幀，每個幀都有唯一的標識，指向所在的數(shù)據(jù)流，來自不同數(shù)據(jù)流的幀可以交錯發(fā)送，然后再根據(jù)每個幀頭的數(shù)據(jù)流標識符重新組裝，這樣就實現(xiàn)了數(shù)據(jù)傳輸。
HTTP/2 核心特點如下：
- 請求優(yōu)先級
- 多個 HTTP 請求同時發(fā)送時，會產(chǎn)生多個數(shù)據(jù)流，數(shù)據(jù)流中有一個優(yōu)先級的標識，服務(wù)器端可以根據(jù)這個標識來決定響應(yīng)的優(yōu)先順序。
- 多路復(fù)用
- TCP 傳輸時，不用按照 HTTP 的發(fā)送順序進行響應(yīng)，可以交錯發(fā)送，接收端根據(jù)幀首部的標識符，就能找到對應(yīng)的流，進而重新組合得到最終數(shù)據(jù)。
- 服務(wù)器端推送
- HTTP/2 允許服務(wù)器未經(jīng)請求，主動向客戶端發(fā)送資源，并緩存到客戶端中，以避免二次請求。
- HTTP/1.1 中請求一個頁面時，瀏覽器會先發(fā)送一個 HTTP 請求，然后得到響應(yīng)的 HTML 內(nèi)容并開始解析，如果發(fā)現(xiàn)有 <script src="xxxx.js"> 標簽，則會再次發(fā)起 HTTP 請求獲取對應(yīng)的 JS 內(nèi)容。而 HTTP/2 可以在返回 HTML 的同時，將需要用到的 JS、CSS 等內(nèi)容一并返回給客戶端，當瀏覽器解析到對應(yīng)標簽時，也就不需要再次發(fā)起請求了。
- 頭部壓縮
- HTTP/1.1 的頭部字段包含大量信息，而且每次請求都得帶上，占用了大量的字節(jié)。
- HTTP/2.0 中通信雙方各自緩存一份頭部字段表，如：把 Content-Type:text/html 存入索引表中，后續(xù)如果要用到這個頭，只需要發(fā)送對應(yīng)的索引號就可以了。
除此之外，雖然 HTTP/2 沒有規(guī)定必須使用 TLS 安全協(xié)議，但所有實現(xiàn) HTTP/2 的 Web 瀏覽器都只支持配置過 TLS 的網(wǎng)站，這是為了鼓勵大家使用更加安全的 HTTPS。
請求示意圖如下：
HTTP/2
可以看到，在 HTTP/2 中發(fā)送請求時，既不需要排隊發(fā)送，也不需要排隊返回，徹底解決了 HTTP 隊頭阻塞問題。對于頭部信息，資源緩存等痛點也進行了優(yōu)化，似乎已經(jīng)是一種很完美的方案了。
HTTP/2 在 HTTP + TCP 的架構(gòu)上已經(jīng)優(yōu)化到了極致，如果要想繼續(xù)優(yōu)化，那就只能從這個架構(gòu)入手了。
首先需要優(yōu)化的是 TCP，因為 TCP 核心是保證傳輸層的可靠性，傳輸效率其實并不好。
- TCP 也存在隊頭阻塞，TCP 在傳輸時使用序列號標識數(shù)據(jù)的順序，一旦某個數(shù)據(jù)丟失，后面的數(shù)據(jù)需要等待這個數(shù)據(jù)重傳后才能進行下一步處理。
- TCP 每一次建立都需要三次握手，釋放連接需要四次揮手，無形中增加了傳輸時長。
- TCP 存在擁塞控制，內(nèi)置了慢啟動，擁塞避免等算法，傳輸效率并不穩(wěn)定。
如果要解決這些問題，就需要替換掉 TCP，而這也是 HTTP/3 的解決思路，我們接著往下看。
HTTP/3
HTTP/3 目前還在草案階段，它的主要特點是對傳輸層進行了優(yōu)化，使用 QUIC 替換 TCP，徹底規(guī)避了 TCP 傳輸?shù)男蕟栴}。
QUIC 由 Google 提出的基于 UDP 進行多路復(fù)用的傳輸協(xié)議。QUIC 沒有連接的概念，不需要三次握手，在應(yīng)用程序?qū)用妫瑢崿F(xiàn)了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并發(fā)性。在設(shè)備支持層面，只需要客戶端和服務(wù)端的應(yīng)用程序支持 QUIC 協(xié)議即可，無操作系統(tǒng)和中間設(shè)備的限制。
HTTP/3 核心特點如下：
- 傳輸層連接更快。
- HTTP/3 基于 QUIC 協(xié)議，可以實現(xiàn) 0-RTT 建立連接，而 TCP 需要 3-RTT 才能建立連接。
- HTTP/3 基于 QUIC 協(xié)議，可以實現(xiàn) 0-RTT 建立連接，而 TCP 需要 3-RTT 才能建立連接。
HTTPS 及 QUIC 建連過程
- 傳輸層多路復(fù)用。
QUIC 多路復(fù)用
上圖中的 Stream 之間相互獨立，如果 Stream2 丟了一個 Pakcet，不會影響 Stream3 和 Stream4 正常讀取。
- HTTP/3 傳輸層使用 QUIC 協(xié)議，數(shù)據(jù)在傳輸時會被拆分成了多個 packet 包，每一個 packet 包都可以獨立、交錯發(fā)送，不用按順序發(fā)送，也就避免了 TCP 隊頭阻塞。
改進的擁塞控制。
Ack Delay
- 單調(diào)遞增的 Packet Number。在 TCP 中，每一個數(shù)據(jù)包都有一個序列號標識(seq)，如果接收端超時沒有收到，就會要求重發(fā)標識為 seq 的包，如果這時超時的包也接收到了，則無法區(qū)分哪個是超時的包，哪個是重傳的包。QUIC 中的每一個包的標識(Packet Number)都是單調(diào)遞增的，重傳的 Packet Number 一定大于超時的 Packet Number，這樣就能區(qū)分開了。
- 不允許 Reneging。在 TCP 中，如果接收方內(nèi)存不夠或 Buffer 溢出，則可能會把已接收的包丟棄(Reneging)，這種行為對數(shù)據(jù)重傳產(chǎn)生了很大的干擾，在 QUIC 中是明確禁止的。在 QUIC 中，一個包只要被確認，就一定是被正確接收了。
- 更多的 ACK 塊。一般來說，接收方收到發(fā)送方的消息后都會發(fā)送一個 ACK 標識，表示收到了數(shù)據(jù)。但每收到一個數(shù)據(jù)就發(fā)送一個 ACK 效率太低了，通常是收到多個數(shù)據(jù)后再統(tǒng)一回復(fù) ACK。TCP 中每收到 3 個數(shù)據(jù)包就要返回一個 ACK，而 QUIC 最多可以收到 256 個包之后，才返回 ACK。在丟包率比較嚴重的網(wǎng)絡(luò)下，更多的 ACK 塊可以減少重傳量，提升網(wǎng)絡(luò)效率。
- Ack Delay。TCP 計算 RTT 時沒有考慮接收方處理數(shù)據(jù)的延遲，如下圖所示，這段延遲即 ACK Delay。QUIC 考慮了這段延遲，使得 RTT 的計算更加準確。
優(yōu)化的流量控制。
- Stream 級別的流量控制中，接收窗口 = 最大接收窗口- 已接收數(shù)據(jù)。
- Connection 級別的流量控制中，接收窗口 = Stream1接收窗口 + Stream2接收窗口 + ... + StreamN接收窗口。
- TCP 通過滑動窗口來控制流量，如果某一個包丟失了，滑動窗口并不能跨過丟失的包繼續(xù)滑動，而是會卡在丟失的位置，等待數(shù)據(jù)重傳后，才能繼續(xù)滑動。
- QUIC 流量控制的核心是：不能建立太多的連接，以免響應(yīng)端處理不過來;不能讓某一個連接占用大量的資源，讓其他連接沒有資源可用。為此 QUIC 流量控制分為 2 個級別：連接級別(Connection Level)和 Stream 級別(Stream Level)。
加密認證的報文
- TCP 頭部沒有經(jīng)過任何加密和認證，在傳輸過程中很容易被中間網(wǎng)絡(luò)設(shè)備篡改，注入和竊聽。
- QUIC 中報文都是經(jīng)過加密和認證的，在傳輸過程中保證了數(shù)據(jù)的安全。
連接遷移
- TCP 連接是由(源 IP，源端口，目的 IP，目的端口)組成，這四者中一旦有一項發(fā)生改變，這個連接也就不能用了。如果我們從 5G 網(wǎng)絡(luò)切換到 WiFi 網(wǎng)絡(luò)，IP 地址就會改變，這個時候 TCP 連接也自然斷掉了。
- QUIC 使用客戶端生成的 64 位 ID 來表示一條連接，只要 ID 不變，這條連接也就一直維持著，不會中斷。
前向糾錯機制
- 發(fā)送端需要發(fā)送三個包，QUIC 在傳輸時會計算出這三個包的異或值，并單獨發(fā)出一個校驗包，也就是總共發(fā)出了四個包。
- 如果某一個包(非校驗包)傳輸時丟失了，則可以通過另外三個包計算出丟失數(shù)據(jù)包的內(nèi)容。
- 當然這種技術(shù)只能用在丟失一個包的情況下，如果丟失了多個包，就只能進行重傳了。
- QUIC 中發(fā)送數(shù)據(jù)時，除了發(fā)送本身的數(shù)據(jù)包，還會發(fā)送驗證包，以減少數(shù)據(jù)丟失導致的重傳。
- 例如：
可以看出，QUIC 丟掉了 TCP 的包袱，基于 UDP，實現(xiàn)了一個安全高效可靠的 HTTP 通信協(xié)議。憑借著 0-RTT 建立連接、傳輸層多路復(fù)用、連接遷移、改進的擁塞控制、流量控制等特性，QUIC 在絕大多數(shù)場景下獲得了比 HTTP/2 更好的效果，HTTP/3 真是未來可期。
思考與總結(jié)
本文通過互聯(lián)網(wǎng)發(fā)展歷史，從 HTTP/0.9 到 HTTP/3，逐步介紹了每個版本的核心特點，最后再分別一句話總結(jié)一下。
- HTTP/0.9 實現(xiàn)基本請求響應(yīng)。
- HTTP/1.0 增加 HTTP 頭，豐富傳輸資源類型，奠定互聯(lián)網(wǎng)發(fā)展基礎(chǔ)。
- HTTP/1.1 增加持久連接、管線化、響應(yīng)分塊，提升了 HTTP 傳輸效率。
- HTTP/2 采用二進制傳輸格式，通過 HTTP 多路復(fù)用、頭部壓縮、服務(wù)器端推送，將傳輸效率在 HTTP + TCP 架構(gòu)上發(fā)揮到了極致。
- HTTP/3 將傳輸層替換為 QUIC，通過改進的擁塞控制、流量控制、0-RTT 建連、傳輸層多路復(fù)用、連接遷移等特性，進一步提升了 HTTP 傳輸效率。
可以看到，從 HTTP/1.1 開始，HTTP 的發(fā)展方向就是：不斷地提升傳輸效率。期待未來的 HTTP 能夠給我們帶來更加快速的傳輸體驗。
