HTTP/3又迎來一個里程碑：近日Cloudflare官方宣其邊緣網絡上已全面提供QUIC和HTTP/3支持。那么HTTP/3可以帶來哪些變化和優勢呢? 對Internet的用戶，并且通過瀏覽器和其他客戶端與站點進行高效交互。

?

HTTP/3又迎來一個里程碑：近日Cloudflare官方宣其邊緣網絡上已全面提供QUIC和HTTP/3支持。那么HTTP/3可以帶來哪些變化和優勢呢? 對Internet的用戶，并且通過瀏覽器和其他客戶端與站點進行高效交互。可通過使用最新Chrome Canary瀏覽器以HTTP/3 UDB協議和服務器交互，對于使用命令行客戶端的人，最新版本的curl也提供了對HTTP/3的支持。本文蟲蟲將介紹HTTP/3的發展歷程，以及用戶如何啟用HTTP 3，如何通過瀏覽器Chrome及命令行客戶端curl使用HTTP 3。

HTTP發展歷程

首先，我們先來介紹下HTTP多年來的發展，以便更好地理解HTTP/3。

HTTP/1.0

HTTP協議源于1996年，在這一年發布了HTTP/1.0規范(0.x版本忽略)，該規范定義了我們今天常見的基本HTTP文本規格定義。在HTTP/1.0中定義了客戶端和服務器之間的每個請求/響應交換都要創建一個新的TCP連接，所以在進行每個請求均需大家熟知的"三次握手，四次揮手"的歷程，因此請求難免會產生延遲。比如一個典型的HTTP/TLS過程，圖解如下：

而且，為了避免將無法處理的數據包泛洪到網絡中，TCP協議對建立的連接使用使用了一種稱為"慢啟動"的預熱暫緩期用來給TCP堵塞控制算法確定可以傳輸的數據量，而不是在建立連接后盡快發送所有未完成的數據。由于每一個新連接都必須經過這個緩慢的啟動過程，這也成了網絡性能的一個瓶頸。

HTTP/1.1 keep-alive

隨之而來的的HTTP/1.1版本中引入"keep-alive(保活)"連接的方法來解決這些問題。通過保活技術，可以讓客戶端重用TCP連接，而不需要每次都重新建立TCP連接，從而解決初始連接建立和緩慢連接的問題。但這并不能從實質上解決問題，盡管多個請求可以共享同一個連接，但是仍然必須一個接一個地序列化它們，因此客戶端和服務器只能在任何給定時間為每個連接執行一次請求/響應交換。

隨著網絡和Web技術的發展，每個網站所需的資源(CSS，JS腳本，圖片，視頻等)的增加，瀏覽器在獲取和渲染呈現網頁時對并發性的需要越來越迫切。但是，由于HTTP/1.1只允許客戶端每次只能進行一個HTTP請求/響應交換，因此在網絡層上獲得并發性的唯一方法是并行使用多個TCP連接，這樣一來就無法享受保活技術帶來的好處。

HTTP/2 SPDY

又過了十多年后，出現了SPDY，然后是HTTP/2規范。它首先引入了HTTP流的概念。通抽象HTTP實現將不同的HTTP交換并發地復用到同一個TCP連接上，瀏覽器可以更有效地重用TCP連接。

HTTP/2解決了單個TCP連接的使用效率低的問題，可以通過同一連接同時傳輸多個請求/響應。但是如果傳輸中發生數據丟包，即使丟失的數據僅涉及單個請求，所有請求和響應也同樣會受到數據包丟失的影響而需要重傳。因為盡管HTTP/2可以在不同的流上隔離不同的HTTP交換，但是底層的TCP并無法對他們進行區別，TCP能看到的只是沒有任何標志的字節流。

TCP的作用是以正確的順序從一個端點到另一端點傳遞整個字節流。當承載某些字節的TCP數據包在網絡路徑上丟失時，它將在流中造成間隙，并且TCP需要在檢測到丟失時通過重新發送受影響的數據包來填充它。這樣即使丟失此后沒有丟失并且屬于完全獨立的HTTP請求，也不能將數據包后的已成功傳輸的數據包傳遞給應用層。因此，最終會導致他們也會產生不必要的延遲。這個問題被稱為TCP head-of-line blocking (TCP隊頭阻塞)。

為了解決隊頭阻塞問題，HTTP/2中也引入了多路復用(Multiplexing)技術，將TCP流可以傳輸的數據分為若干消息，每個消息再劃分為最小的二進制幀組成，這樣即使一個請求被阻塞了，也不會影響其他請求，如上圖中第四種情況所示。

HTTP/3 QUIC

當然這些改良TCP的方案都只能部分解決問題，為了徹底從根解決問題。那就需要徹底更換底層的TCP協議，這就是谷歌多年探索的基于UDP的QUIC協議，這也是HTTP/3的基礎。QUIC協議中在傳輸層將數據流作為基本，QUIC流共享相同的QUIC連接，需要額外的握手和慢啟動來創建新的QUIC流，通過底層使用UDP協議以及將QUIC數據包封裝在UDP數據報的頂部，實現QUIC流的獨立交付。因此在大多數情況下，影響一個流的丟包不會影響其他流。

與TCP相比，使用UDP可以提供更大的靈活性，并且可以使QUIC實現完全存在于用戶空間中。協議實現的更新不再依賴于操作系統更新。借助QUIC，可以將HTTP級別的流簡單地映射為QUIC流的頭，從而繼承HTTP/2的所有好處，而不會產生隊頭阻塞問題。

QUIC還結合了典型的3次TCP握手和TLS 1.3的握手。這樣默認情況就可以提供加密和身份驗證，并且加速連接的建立。就算HTTP會話中的初始請求需要新的QUIC連接，在數據開始流動之前所引起的等待時間也較低。

HTTP/3的使用

HTTP/3和QUIC給我們帶來開天辟地的變化，可以從根本上解決HTTP標準許久以來的許多問題和缺陷。那么我們如何立刻使用它帶來的福利呢?

quiche框架

為了支持推廣HTTP/3 Cloudflare使用Rust開發并開源一個HTTP/3和QUI的應用框架，而且還給該應用使用一個非常可餐的名字quiche(乳蛋餅)和logo，估計以借此吸引人們盡快品嘗HTTP/3制成的美食。

quiche的源碼托管在github上(github:/cloudflare/quiche)，在clone源碼后，可以通過cargo編譯(注意需要rust 1.38及更新的版本，BoringSSL及其windows版本NASM)：

cargo?build?-examples?

quiche也提供了以docker為基礎的實驗環境包括http3-client, http3-server, 客戶端和服務器端，使用方法如下：

docker編譯：

docker?build?-t?cloudflare-quiche?.?

進行HTTP/3請求

docker?run?-it?cloudflare-quiche?http3-client?Url?

網站啟用

目前Cloudflare的選擇性開部分放客戶如已經可以通過簡單手動設置啟用HTTP/3功能，方法是在Cloudflare儀表板，手動在"網絡"選項卡開啟開關：

客戶端使用

目前知名瀏覽器谷歌Chrome和Firefox都已經實驗性提供對HTTP/3的支持。Chrome在Canary，Firefox將在Nightly正式正式提供支持。

Chrome瀏覽器：首先需要下載并安裝最新的Canary版本。然后，通過設置以下命令行參數啟動Chrome Canary：

"--enable-quic"和"?--quic-version?=?h3-23"?

然后就可以支持HTTP/3，可以通過Chrome開發人員工具中的"網絡"標簽頁來檢查使用的協議版本：

注意到協議類型為"http2+quic/99"，這就是表示Http3。

使用curl

curl最新版7.66，也添加了對HTTP/3的實驗性支持。我們可以下載編譯試用，在此章中對此介紹過。

要使用HTTP/3需要使用新添加的 "--http3"標志來進行請求：

curl?-I?URL?--http3?

閱讀目錄（置頂)(長期更新計算機領域知識）https://blog.csdn.net/weixin_43392489/article/details/102380691

閱讀目錄（置頂)(長期更新計算機領域知識）https://blog.csdn.net/weixin_43392489/article/details/102380882

?

總結

以上是生活随笔為你收集整理的第二十六期:HTTP 3的前世今生及尝鲜的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。