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