Tip：
- 平臺會對圖片進行壓縮，可在微信公眾號 FEPulse（ID：FEPulse）後臺回覆 HTTP3 獲取高清大圖；
- 騰訊暑期實習招聘全面啟動，可公眾號後臺聯絡我幫助內推，有意向團隊比如 AlloyTeam 等亦可推薦。
2015 年 HTTP/2 標準發表後，大多數主流瀏覽器也於當年年底支援該標準。此後，憑藉著多路複用、頭部壓縮、伺服器推送等優勢，HTTP/2 得到了越來越多知名網際網路公司的青睞。就在大家剛剛為了解了 HTTP/2 新特性而舒口氣兒的時候，HTTP/3 卻又緊鑼密鼓地準備著了。今天就跟大家聊一聊這第三代 HTTP 技術。
1. HTTP 歷史
在介紹 HTTP 之前，我們先簡單看下 HTTP 的歷史，瞭解下 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 的優點，並加以優化。用一張圖可以清晰地表示他們之間的關係。
那麼想了解 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 可以更好地理解上面的過程。
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/2 的多路複用解決了上述的隊頭阻塞問題。不像 HTTP/1.1 中只有上一個請求的所有資料包被傳輸完畢下一個請求的資料包才可以被傳輸，HTTP/2 中每個請求都被拆分成多個 Frame 通過一條 TCP 連線同時被傳輸，這樣即使一個請求被阻塞，也不會影響其他的請求。如圖2-8 所示，不同顏色代表不同的請求，相同顏色的色塊代表請求被切分的 Frame。
那 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 計算，超時時間的準確把握很重要，長了短了都不合適。
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 就會偏移，接收視窗增大，傳送方可以傳送更多資料到接收方。
接收視窗(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 未來可期。