HTTP/3 都來了，你卻還在用 HTTP/1.1？

Tip：

1. 平臺會對圖片進行壓縮，可在微信公眾號 FEPulse（ID：FEPulse）後臺回覆 HTTP3 獲取高清大圖；
2. 騰訊暑期實習招聘全面啟動，可公眾號後臺聯絡我幫助內推，有意向團隊比如 AlloyTeam 等亦可推薦。

2015 年 HTTP/2 標準發表後，大多數主流瀏覽器也於當年年底支援該標準。此後，憑藉著多路複用、頭部壓縮、伺服器推送等優勢，HTTP/2 得到了越來越多知名網際網路公司的青睞。就在大家剛剛為了解了 HTTP/2 新特性而舒口氣兒的時候，HTTP/3 卻又緊鑼密鼓地準備著了。今天就跟大家聊一聊這第三代 HTTP 技術。

1. HTTP 歷史

在介紹 HTTP 之前，我們先簡單看下 HTTP 的歷史，瞭解下 HTTP/3 出現的背景。

隨著網路技術的發展，1999 年設計的 HTTP/1.1 已經不能滿足需求，所以 Google 在 2009 年設計了基於 TCP 的 SPDY，後來 SPDY 的開發組推動 SPDY 成為正式標準，不過最終沒能通過。不過 SPDY 的開發組全程參與了 HTTP/2 的制定過程，參考了 SPDY 的很多設計，所以我們一般認為 SPDY 就是 HTTP/2 的前身。無論 SPDY 還是 HTTP/2，都是基於 TCP 的，TCP 與 UDP 相比效率上存在天然的劣勢，所以 2013 年 Google 開發了基於 UDP 的名為 QUIC 的傳輸層協議，QUIC 全稱 Quick UDP Internet Connections，希望它能替代 TCP，使得網頁傳輸更加高效。後經提議，網際網路工程任務組正式將基於 QUIC 協議的 HTTP （HTTP over QUIC）重新命名為 HTTP/3。

2. QUIC

2.1 QUIC 協議概覽

TCP 一直是傳輸層中舉足輕重的協議，而 UDP 則默默無聞，在面試中問到 TCP 和 UDP 的區別時，有關 UDP 的回答常常寥寥幾語，長期以來 UDP 給人的印象就是一個很快但不可靠的傳輸層協議。但有時候從另一個角度看，缺點可能也是優點。QUIC（Quick UDP Internet Connections，快速 UDP 網路連線） 基於 UDP，正是看中了 UDP 的速度與效率。同時 QUIC 也整合了 TCP、TLS 和 HTTP/2 的優點，並加以優化。用一張圖可以清晰地表示他們之間的關係。

那 QUIC 和 HTTP/3 什麼關係呢？QUIC 是用來替代 TCP、SSL/TLS 的傳輸層協議，在傳輸層之上還有應用層，我們熟知的應用層協議有 HTTP、FTP、IMAP 等，這些協議理論上都可以執行在 QUIC 之上，其中執行在 QUIC 之上的 HTTP 協議被稱為 HTTP/3，這就是”HTTP over QUIC 即 HTTP/3“的含義。

那麼想了解 HTTP/3，QUIC 是繞不過去的，下面主要通過幾個重要的特性讓大家對 QUIC 有更深的理解。

2.2 零 RTT 建立連線

用一張圖可以形象地看出 HTTP/2 和 HTTP/3 建立連線的差別，如圖2-2 和圖2-3 所示。

HTTP/2 的連線需要 3 RTT，如果考慮會話複用，即把第一次握手算出來的對稱金鑰快取起來，那麼也需要 2 RTT，更進一步的，如果 TLS 升級到 1.3，那麼 HTTP/2 連線需要 2 RTT，考慮會話複用則需要 1 RTT。有人會說 HTTP/2 不一定需要 HTTPS，握手過程還可以簡化。這沒毛病，HTTP/2 的標準的確不需要基於 HTTPS，但實際上所有瀏覽器的實現都要求 HTTP/2 必須基於 HTTPS，所以 HTTP/2 的加密連線必不可少。而 HTTP/3 首次連線只需要 1 RTT，後面的連線更是隻需 0 RTT，意味著客戶端發給服務端的第一個包就帶有請求資料，這一點 HTTP/2 難以望其項背。那這背後是什麼原理呢？結合圖2-3，我們具體看下 QUIC 的連線過程。

Step1：首次連線時，客戶端傳送 Inchoate Client Hello 給服務端，用於請求連線；

Step2：服務端生成 g、p、a，根據 g、p 和 a 算出 A，然後將 g、p、A 放到 Server Config 中再傳送 Rejection 訊息給客戶端；

Step3：客戶端接收到 g、p、A 後，自己再生成 b，根據 g、p、b 算出 B，根據 A、p、b 算出初始金鑰 K。B 和 K 算好後，客戶端會用 K 加密 HTTP 資料，連同 B 一起傳送給服務端；

Step4：服務端接收到 B 後，根據 a、p、B 生成與客戶端同樣的金鑰，再用這金鑰解密收到的 HTTP 資料。為了進一步的安全（前向安全性），服務端會更新自己的隨機數 a 和公鑰，再生成新的金鑰 S，然後把公鑰通過 Server Hello 傳送給客戶端。連同 Server Hello 訊息，還有 HTTP 返回資料；

Step5：客戶端收到 Server Hello 後，生成與服務端一致的新金鑰 S，後面的傳輸都使用 S 加密。

這樣，QUIC 從請求連線到正式接發 HTTP 資料一共花了 1 RTT，這 1 個 RTT 主要是為了獲取 Server Config，後面的連線如果客戶端快取了 Server Config，那麼就可以直接傳送 HTTP 資料，實現 0 RTT 建立連線。

QUIC 實現 0 RTT 的一個技術細節是使用了 DH金鑰交換演算法。結合圖2-4 可以更好地理解上面的過程。

DH 演算法的核心就是服務端生成 a、g、p 3 個隨機數，a 自己持有，g 和 p 要傳輸給客戶端，而客戶端會生成 b 這 1 個隨機數，通過 DH 演算法客戶端和服務端可以算出同樣的金鑰。在這過程中 a 和 b 並不參與網路傳輸，安全性大大提高。因為 p 和 g 是大數，所以即使在網路中傳輸的 p、g、A、B 都被劫持，那麼靠現在的計算機算力也沒法破解金鑰。

2.3 連線遷移

TCP 連線基於四元組（源 IP、源埠、目的 IP、目的埠），切換網路時至少會有一個因素髮生變化，導致連線發生變化。當連線發生變化時，如果還使用原來的 TCP 連線，則會導致連線失敗，就得等原來的連線超時後重新建立連線，所以我們有時候發現切換到一個新網路時，即使新網路狀況良好，但內容還是需要載入很久。如果實現得好，當檢測到網路變化時立刻建立新的 TCP 連線，即使這樣，建立新的連線還是需要幾百毫秒的時間。

QUIC 的連線不受四元組的影響，當這四個元素髮生變化時，原連線依然維持。那這是怎麼做到的呢？道理很簡單，QUIC 連線不以四元組作為標識，而是使用一個 64 位的隨機數，這個隨機數被稱為 Connection ID，即使 IP 或者埠發生變化，只要 Connection ID 沒有變化，那麼連線依然可以維持。

2.4 隊頭阻塞/多路複用

HTTP/1.1 和 HTTP/2 都存在隊頭阻塞問題（Head of line blocking），那什麼是隊頭阻塞呢？

TCP 是個面向連線的協議，即傳送請求後需要收到 ACK 訊息，以確認對方已接收到資料。如果每次請求都要在收到上次請求的 ACK 訊息後再請求，那麼效率無疑很低，如圖2-5 所示。後 HTTP/1.1 提出了 Pipelining 技術，允許一個 TCP 連線同時傳送多個請求，這樣就大大提升了傳輸效率，如圖2-6 所示。

在這個背景下，下面就來談 HTTP/1.1 的隊頭阻塞。圖2-7 中的一個 TCP 連線同時傳輸 10 個請求，其中第 1、2、3 個請求已被客戶端接收，但第 4 個請求丟失，那麼後面第 5 - 10 個請求都被阻塞，需要等第 4 個請求處理完畢才能被處理，這樣就浪費了頻寬資源。

因此，HTTP 一般又允許每個主機建立 6 個 TCP 連線，這樣可以更加充分地利用頻寬資源，但每個連線中隊頭阻塞的問題還是存在。

HTTP/2 的多路複用解決了上述的隊頭阻塞問題。不像 HTTP/1.1 中只有上一個請求的所有資料包被傳輸完畢下一個請求的資料包才可以被傳輸，HTTP/2 中每個請求都被拆分成多個 Frame 通過一條 TCP 連線同時被傳輸，這樣即使一個請求被阻塞，也不會影響其他的請求。如圖2-8 所示，不同顏色代表不同的請求，相同顏色的色塊代表請求被切分的 Frame。

事情還沒完，HTTP/2 雖然可以解決“請求”這個粒度的阻塞，但 HTTP/2 的基礎 TCP 協議本身卻也存在著隊頭阻塞的問題。HTTP/2 的每個請求都會被拆分成多個 Frame，不同請求的 Frame 組合成 Stream，Stream 是 TCP 上的邏輯傳輸單元，這樣 HTTP/2 就達到了一條連線同時傳送多條請求的目標，這就是多路複用的原理。如圖2-9 所示，我們看一個例子，在一條 TCP 連線上同時傳送 4 個 Stream，其中 Stream1 已正確送達，Stream2 中的第 3 個 Frame 丟失，TCP 處理資料時有嚴格的前後順序，先傳送的 Frame 要先被處理，這樣就會要求傳送方重新傳送第 3 個 Frame，Stream3 和 Stream4 雖然已到達但卻不能被處理，那麼這時整條連線都被阻塞。

不僅如此，由於 HTTP/2 必須使用 HTTPS，而 HTTPS 使用的 TLS 協議也存在隊頭阻塞問題。TLS 基於 Record 組織資料，將一堆資料放在一起（即一個 Record）加密，加密完後又拆分成多個 TCP 包傳輸。一般每個 Record 16K，包含 12 個 TCP 包，這樣如果 12 個 TCP 包中有任何一個包丟失，那麼整個 Record 都無法解密，如圖2-10 所示。

隊頭阻塞會導致 HTTP/2 在更容易丟包的弱網路環境下比 HTTP/1.1 更慢！

那 QUIC 是如何解決隊頭阻塞問題的呢？主要有兩點。

• QUIC 的傳輸單元是 Packet，加密單元也是 Packet，整個加密、傳輸、解密都基於 Packet，這樣就能避免 TLS 的隊頭阻塞問題；
• QUIC 基於 UDP，UDP 的資料包在接收端沒有處理順序，即使中間丟失一個包，也不會阻塞整條連線，其他的資源會被正常處理。

2.5 擁塞控制

擁塞控制的目的是避免過多的資料一下子湧入網路，導致網路超出最大負荷。QUIC 的擁塞控制與 TCP 類似，並在此基礎上做了改進。所以我們先簡單介紹下 TCP 的擁塞控制。

TCP 擁塞控制由 4 個核心演算法組成：慢啟動、擁塞避免、快速重傳和快速恢復，理解了這 4 個演算法，對 TCP 的擁塞控制也就有了大概瞭解。

• 慢啟動：傳送方向接收方傳送 1 個單位的資料，收到對方確認後會傳送 2 個單位的資料，然後依次是 4 個、8 個……呈指數級增長，這個過程就是在不斷試探網路的擁塞程度，超出閾值則會導致網路擁塞；
• 擁塞避免：指數增長不可能是無限的，到達某個限制（慢啟動閾值）之後，指數增長變為線性增長；
• 快速重傳：傳送方每一次傳送時都會設定一個超時計時器，超時後即認為丟失，需要重發；
• 快速恢復：在上面快速重傳的基礎上，傳送方重新傳送資料時，也會啟動一個超時定時器，如果收到確認訊息則進入擁塞避免階段，如果仍然超時，則回到慢啟動階段。

QUIC 重新實現了 TCP 協議的 Cubic 演算法進行擁塞控制，並在此基礎上做了不少改進。下面介紹一些 QUIC 改進的擁塞控制的特性。

熱插拔

TCP 中如果要修改擁塞控制策略，需要在系統層面進行操作。QUIC 修改擁塞控制策略只需要在應用層操作，並且 QUIC 會根據不同的網路環境、使用者來動態選擇擁塞控制演算法。

單調遞增的 Packet Number

TCP 為了保證可靠性，使用 Sequence Number 和 ACK 來確認訊息是否有序到達，但這樣的設計存在缺陷。

超時發生後客戶端發起重傳，後來接收到了 ACK 確認訊息，但因為原始請求和重傳請求接收到的 ACK 訊息一樣，所以客戶端就鬱悶了，不知道這個 ACK 對應的是原始請求還是重傳請求。如果客戶端認為是原始請求的 ACK，但實際上是圖2-11 的情形，則計算的取樣 RTT 偏大；如果客戶端認為是重傳請求的 ACK，但實際上是圖2-12 的情形，又會導致取樣 RTT 偏小。圖中有幾個術語，RTO 是指超時重傳時間（Retransmission TimeOut），跟我們熟悉的 RTT（Round Trip Time，往返時間）很長得很像。取樣 RTT 會影響 RTO 計算，超時時間的準確把握很重要，長了短了都不合適。

QUIC 解決了上面的歧義問題。與 Sequence Number 不同的是，Packet Number 嚴格單調遞增，如果 Packet N 丟失了，那麼重傳時 Packet 的標識不會是 N，而是比 N 大的數字，比如 N + M，這樣傳送方接收到確認訊息時就能方便地知道 ACK 對應的是原始請求還是重傳請求。如圖2-13 所示，客戶端接收到的是 ACK N + M，毫無疑問對應重傳請求，圖2-14 客戶端收到的是 ACK N，所以對應的是原始請求。

ACK Delay

TCP 計算 RTT 時沒有考慮接收方接收到資料到傳送確認訊息之間的延遲，如圖2-15 所示，這段延遲即 ACK Delay。QUIC 考慮了這段延遲，使得 RTT 的計算更加準確。

更多的 ACK 塊

一般來說，接收方收到傳送方的訊息後都應該傳送一個 ACK 回覆，表示收到了資料。但每收到一個資料就返回一個 ACK 回覆太麻煩，所以一般不會立即回覆，而是接收到多個資料後再回復，TCP SACK 最多提供 3 個 ACK block。但有些場景下，比如下載，只需要伺服器返回資料就好，但按照 TCP 的設計，每收到 3 個資料包就要“禮貌性”地返回一個 ACK。而 QUIC 最多可以捎帶 256 個 ACK block。在丟包率比較嚴重的網路下，更多的 ACK block 可以減少重傳量，提升網路效率。

2.6 流量控制

TCP 會對每個 TCP 連線進行流量控制，流量控制的意思是讓傳送方不要傳送太快，要讓接收方來得及接收，不然會導致資料溢位而丟失，TCP 的流量控制主要通過滑動視窗來實現的。可以看出，擁塞控制主要是控制傳送方的傳送策略，但沒有考慮到接收方的接收能力，流量控制是對這部分能力的補齊。

QUIC 只需要建立一條連線，在這條連線上同時傳輸多條 Stream，好比有一條道路，兩頭分別有一個倉庫，道路中有很多車輛運送物資。QUIC 的流量控制有兩個級別：連線級別（Connection Level）和 Stream 級別（Stream Level），好比既要控制這條路的總流量，不要一下子很多車輛湧進來，貨物來不及處理，也不能一個車輛一下子運送很多貨物，這樣貨物也來不及處理。

那 QUIC 是怎麼實現流量控制的呢？我們先看單條 Stream 的流量控制。Stream 還沒傳輸資料時，接收視窗（flow control receive window）就是最大接收視窗（flow control receive window），隨著接收方接收到資料後，接收視窗不斷縮小。在接收到的資料中，有的資料已被處理，而有的資料還沒來得及被處理。如圖2-16 所示，藍色塊表示已處理資料，黃色塊表示未處理資料，這部分資料的到來，使得 Stream 的接收視窗縮小。

隨著資料不斷被處理，接收方就有能力處理更多資料。當滿足 (flow control receive offset - consumed bytes) < (max receive window / 2) 時，接收方會傳送 WINDOW_UPDATE frame 告訴傳送方你可以再多傳送些資料過來。這時 flow control receive offset 就會偏移，接收視窗增大，傳送方可以傳送更多資料到接收方。

Stream 級別對防止接收端接收過多資料作用有限，更需要藉助 Connection 級別的流量控制。理解了 Stream 流量那麼也很好理解 Connection 流控。Stream 中，接收視窗(flow control receive window) = 最大接收視窗(max receive window) - 已接收資料(highest received byte offset)，而對 Connection 來說：接收視窗 = Stream1接收視窗 + Stream2接收視窗 + ... + StreamN接收視窗。

3. QUIC 應用

3.1 協商升級

因為不確認伺服器是否支援 QUIC，所以需要經歷協商升級過程才能決定能夠使用 QUIC。

首次請求時，客戶端會使用 HTTP/1.1 或者 HTTP/2，如果伺服器支援 QUIC，則在響應的資料中返回 alt-svc 頭部，主要包含以下資訊：

• quic：監聽的埠；
• ma：有效時間，單位是秒，承諾在這段時間內都支援 QUIC；
• 版本號：QUIC 的迭代很快，這裡列出所有支援的版本號。

確認伺服器支援 QUIC 之後，客戶端向服務端同時發起 QUIC 連線和 TCP 連線，比較兩個連線的速度，然後選擇較快的協議，這個過程叫“競速”，一般都是 QUIC 獲勝。

3.2 應用情況

目前 Google、Gmail、QQ 會員等業務已經陸續使用 QUIC。本文主要側重介紹 QUIC 本身，也限於筆者這方面實踐經驗有限，QUIC 應用部分不再詳述，大家可以找相關實踐文章，比如這篇《讓網際網路更快的協議，QUIC在騰訊的實踐及效能優化》。

4. 總結

QUIC 丟掉了 TCP、TLS 的包袱，基於 UDP，並對 TCP、TLS、HTTP/2 的經驗加以借鑑、改進，實現了一個安全高效可靠的 HTTP 通訊協議。憑藉著零 RTT 建立連線、平滑的連線遷移、基本消除了隊頭阻塞、改進的擁塞控制和流量控制等優秀的特性，QUIC 在絕大多數場景下獲得了比 HTTP/2 更好的效果，HTTP/3 未來可期。