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 個請求，其中第 一、二、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 將來可期。