快速讀懂 HTTP/3 協議

在 深刻淺出：HTTP/2 一文中詳細介紹了 HTTP/2 新的特性，好比頭部壓縮、二進制分幀、虛擬的「流」與多路複用，性能方面比 HTTP/1 有了很大的提高。與全部性能優化過程同樣，去掉一個性能瓶頸，又會帶來新的瓶頸。對HTTP 2.0而言，TCP 極可能就是下一個性能瓶頸。這也是爲何服務器端TCP配置對HTTP 2.0相當重要的一個緣由。」

TCP 的限制

HTTP/3功能的核心是圍繞着底層的QUIC協議來實現的。在討論QUIC和UDP以前，咱們有必要先列出TCP的某些限制，這也是致使QUIC發展的緣由。

TCP可能會間歇性地掛起數據傳輸

若是一個序列號較低的數據段尚未接收到，即便其餘序列號較高的段已經接收到，TCP的接收機滑動窗口也不會繼續處理。這將致使TCP流瞬間掛起，在更糟糕的狀況下，即便全部的段中有一個沒有收到，也會致使關閉鏈接。這個問題被稱爲TCP流的行頭阻塞（HoL）。

 

TCP不支持流級複用

雖然TCP確實容許在應用層之間創建多個邏輯鏈接，但它不容許在一個TCP流中複用數據包。使用HTTP/2時，瀏覽器只能與服務器打開一個TCP鏈接，並使用同一個鏈接來請求多個對象，如CSS、JavaScript等文件。在接收這些對象的同時，TCP會將全部對象序列化在同一個流中。所以，它不知道TCP段的對象級分區。

TCP會產生冗餘通訊

TCP鏈接握手會有冗餘的消息交換序列，即便是與已知主機創建的鏈接也是如此。

QUIC 協議

這裏先貼一下 HTTP/3 的協議棧圖，讓你對它有個大概的瞭解。

QUIC協議在如下設計選擇的基礎上，經過引入一些底層傳輸機制的改變，解決了這些問題。

• 1）選擇UDP做爲底層傳輸層協議：在TCP之上創建新的傳輸機制，將繼承TCP的上述全部缺點。所以，UDP是一個明智的選擇。此外，QUIC是在用戶層構建的，因此不須要每次協議升級時進行內核修改。

• 2）流複用和流控：QUIC引入了鏈接上的多路流複用的概念。QUIC經過設計實現了單獨的、針對每一個流的流控，解決了整個鏈接的行頭阻塞問題。

 

• 3）靈活的擁塞控制機制：TCP的擁塞控制機制是剛性的。該協議每次檢測到擁塞時，都會將擁塞窗口大小減小一半。相比之下，QUIC的擁塞控制設計得更加靈活，能夠更有效地利用可用的網絡帶寬，從而得到更好的吞吐量。

• 4）更好的錯誤處理能力：QUIC使用加強的丟失恢復機制和轉發糾錯功能，以更好地處理錯誤數據包。該功能對於那些只能經過緩慢的無線網絡訪問互聯網的用戶來講是一個福音，由於這些網絡用戶在傳輸過程當中常常出現高錯誤率。

• 5）更快的握手：QUIC使用相同的TLS模塊進行安全鏈接。然而，與TCP不一樣的是，QUIC的握手機制通過優化，避免了每次兩個已知的對等者之間創建通訊時的冗餘協議交換。

經過在QUIC之上構建基於HTTP/3的應用層，您能夠得到加強型傳輸機制的全部優點，同時保留HTTP/2的語法和語義。可是，你也必須注意到，HTTP/2不能直接與QUIC集成，由於從應用到傳輸的底層幀映射是不兼容的。所以，IETF的HTTP工做組建議將HTTP/3做爲新的HTTP版本，並根據QUIC協議的幀格式要求修改了幀映射。

除此以外，HTTP/3還使用了一種新的HTTP頭壓縮機制，稱爲QPACK，是對HTTP/2中使用的HPACK的加強。在QPACK下，HTTP頭能夠在不一樣的QUIC流中不按順序到達。與HTTP/2中的TCP確保數據包的按順序傳遞不一樣，QUIC流是不按順序傳遞的，在不一樣的流中可能包含不一樣的HTTP頭。所以，QPACK使用查找表機制對報頭進行編碼和解碼。

所以想要了解 HTTP/3，QUIC 是繞不過去的，下面主要經過幾個重要的特性讓你們對 QUIC 有更深的理解。

QUIC 的特色

零 RTT 創建鏈接

用一張圖能夠形象地看出 HTTP/2 和 HTTP/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 難以望其項背。那這背後是什麼原理呢？咱們具體看下 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 創建鏈接。

這裏使用的是 DH 密鑰交換算法，DH 算法的核心就是服務端生成 a、g、p 3 個隨機數，a 本身持有，g 和 p 要傳輸給客戶端，而客戶端會生成 b 這 1 個隨機數，經過 DH 算法客戶端和服務端能夠算出一樣的密鑰。在這過程當中 a 和 b 並不參與網絡傳輸，安全性大大提升。由於 p 和 g 是大數，因此即便在網絡中傳輸的 p、g、A、B 都被劫持，那麼靠如今的計算機算力也無法破解密鑰。

鏈接遷移

TCP 鏈接基於四元組（源 IP、源端口、目的 IP、目的端口），切換網絡時至少會有一個因素髮生變化，致使鏈接發生變化。當鏈接發生變化時，若是還使用原來的 TCP 鏈接，則會致使鏈接失敗，就得等原來的鏈接超時後從新創建鏈接，因此咱們有時候發現切換到一個新網絡時，即便新網絡情況良好，但內容仍是須要加載好久。若是實現得好，當檢測到網絡變化時馬上創建新的 TCP 鏈接，即便這樣，創建新的鏈接仍是須要幾百毫秒的時間。

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

隊頭阻塞/多路複用

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

TCP 是個面向鏈接的協議，即發送請求後須要收到 ACK 消息，以確認對方已接收到數據。若是每次請求都要在收到上次請求的 ACK 消息後再請求，那麼效率無疑很低。後來 HTTP/1.1 提出了 Pipelining 技術，容許一個 TCP 鏈接同時發送多個請求，這樣就大大提高了傳輸效率。

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

所以，HTTP 通常又容許每一個主機創建 6 個 TCP 鏈接，這樣能夠更加充分地利用帶寬資源，但每一個鏈接中隊頭阻塞的問題仍是存在。

HTTP/2 的多路複用解決了上述的隊頭阻塞問題。不像 HTTP/1.1 中只有上一個請求的全部數據包被傳輸完畢下一個請求的數據包才能夠被傳輸，HTTP/2 中每一個請求都被拆分紅多個 Frame 經過一條 TCP 鏈接同時被傳輸，這樣即便一個請求被阻塞，也不會影響其餘的請求。以下圖所示，不一樣顏色表明不一樣的請求，相同顏色的色塊表明請求被切分的 Frame。

事情還沒完，HTTP/2 雖然能夠解決「請求」這個粒度的阻塞，但 HTTP/2 的基礎 TCP 協議自己卻也存在着隊頭阻塞的問題。HTTP/2 的每一個請求都會被拆分紅多個 Frame，不一樣請求的 Frame 組合成 Stream，Stream 是 TCP 上的邏輯傳輸單元，這樣 HTTP/2 就達到了一條鏈接同時發送多條請求的目標，這就是多路複用的原理。咱們看一個例子，在一條 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 都沒法解密。

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

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

• QUIC 的傳輸單元是 Packet，加密單元也是 Packet，整個加密、傳輸、解密都基於 Packet，這樣就能避免 TLS 的隊頭阻塞問題；

• QUIC 基於 UDP，UDP 的數據包在接收端沒有處理順序，即便中間丟失一個包，也不會阻塞整條鏈接，其餘的資源會被正常處理。

擁塞控制

擁塞控制的目的是避免過多的數據一會兒涌入網絡，致使網絡超出最大負荷。QUIC 的擁塞控制與 TCP 相似，並在此基礎上作了改進。因此咱們先簡單介紹下 TCP 的擁塞控制。

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

• 慢啓動：發送方向接收方發送 1 個單位的數據，收到對方確認後會發送 2 個單位的數據，而後依次是 4 個、8 個……呈指數級增加，這個過程就是在不斷試探網絡的擁塞程度，超出閾值則會致使網絡擁塞；

• 擁塞避免：指數增加不多是無限的，到達某個限制（慢啓動閾值）以後，指數增加變爲線性增加；

• 快速重傳：發送方每一次發送時都會設置一個超時計時器，超時後即認爲丟失，須要重發；

• 快速恢復：在上面快速重傳的基礎上，發送方從新發送數據時，也會啓動一個超時定時器，若是收到確認消息則進入擁塞避免階段，若是仍然超時，則回到慢啓動階段。

QUIC 從新實現了 TCP 協議的 Cubic 算法進行擁塞控制，並在此基礎上作了很多改進。下面介紹一些 QUIC 改進的擁塞控制的特性。

熱插拔

TCP 中若是要修改擁塞控制策略，須要在系統層面進行操做。QUIC 修改擁塞控制策略只須要在應用層操做，而且 QUIC 會根據不一樣的網絡環境、用戶來動態選擇擁塞控制算法

 

前向糾錯 FEC

QUIC 使用前向糾錯(FEC，Forward Error Correction)技術增長協議的容錯性。一段數據被切分爲 10 個包後，依次對每一個包進行異或運算，運算結果會做爲 FEC 包與數據包一塊兒被傳輸，若是不幸在傳輸過程當中有一個數據包丟失，那麼就能夠根據剩餘 9 個包以及 FEC 包推算出丟失的那個包的數據，這樣就大大增長了協議的容錯性。

這是符合現階段網絡技術的一種方案，現階段帶寬已經不是網絡傳輸的瓶頸，往返時間纔是，因此新的網絡傳輸協議能夠適當增長數據冗餘，減小重傳操做。

單調遞增的 Packet Number

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

超時發生後客戶端發起重傳，後來接收到了 ACK 確認消息，但由於原始請求和重傳請求接收到的 ACK 消息同樣，因此客戶端就鬱悶了，不知道這個 ACK 對應的是原始請求仍是重傳請求。若是客戶端認爲是原始請求的 ACK，但其實是左圖的情形，則計算的採樣 RTT 偏大；若是客戶端認爲是重傳請求的 ACK，但其實是右圖的情形，又會致使採樣 RTT 偏小。圖中有幾個術語，RTO 是指超時重傳時間（Retransmission TimeOut），跟咱們熟悉的 RTT（Round Trip Time，往返時間）很長得很像。採樣 RTT 會影響 RTO 計算，超時時間的準確把握很重要，長了短了都不合適。

QUIC 解決了上面的歧義問題。與 Sequence Number 不一樣的是，Packet Number 嚴格單調遞增，若是 Packet N 丟失了，那麼重傳時 Packet 的標識不會是 N，而是比 N 大的數字，好比 N + M，這樣發送方接收到確認消息時就能方便地知道 ACK 對應的是原始請求仍是重傳請求。

ACK Delay

TCP 計算 RTT 時沒有考慮接收方接收到數據到發送確認消息之間的延遲，以下圖所示，這段延遲即 ACK Delay。QUIC 考慮了這段延遲，使得 RTT 的計算更加準確。

更多的 ACK 塊

通常來講，接收方收到發送方的消息後都應該發送一個 ACK 回覆，表示收到了數據。但每收到一個數據就返回一個 ACK 回覆太麻煩，因此通常不會當即回覆，而是接收到多個數據後再回復，TCP SACK 最多提供 3 個 ACK block。但有些場景下，好比下載，只須要服務器返回數據就好，但按照 TCP 的設計，每收到 3 個數據包就要「禮貌性」地返回一個 ACK。而 QUIC 最多能夠捎帶 256 個 ACK block。在丟包率比較嚴重的網絡下，更多的 ACK block 能夠減小重傳量，提高網絡效率。

流量控制

TCP 會對每一個 TCP 鏈接進行流量控制，流量控制的意思是讓發送方不要發送太快，要讓接收方來得及接收，否則會致使數據溢出而丟失，TCP 的流量控制主要經過滑動窗口來實現的。能夠看出，擁塞控制主要是控制發送方的發送策略，但沒有考慮到接收方的接收能力，流量控制是對這部分能力的補齊。

QUIC 只須要創建一條鏈接，在這條鏈接上同時傳輸多條 Stream，比如有一條道路，兩頭分別有一個倉庫，道路中有不少車輛運送物資。QUIC 的流量控制有兩個級別：鏈接級別（Connection Level）和 Stream 級別（Stream Level），比如既要控制這條路的總流量，不要一會兒不少車輛涌進來，貨物來不及處理，也不能一個車輛一會兒運送不少貨物，這樣貨物也來不及處理。

那 QUIC 是怎麼實現流量控制的呢？咱們先看單條 Stream 的流量控制。Stream 還沒傳輸數據時，接收窗口（flow control receive window）就是最大接收窗口（flow control receive window），隨着接收方接收到數據後，接收窗口不斷縮小。在接收到的數據中，有的數據已被處理，而有的數據還沒來得及被處理。以下圖所示，藍色塊表示已處理數據，黃色塊表示未處理數據，這部分數據的到來，使得 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 接收窗口 。

爲何HTTP/3很重要？

TCP已經有40多年的歷史了。它在1981年經過RFC 793從而標準化。多年來，它經歷了屢次更新，是一個很是強大的傳輸協議，能夠支持互聯網流量的增加。然而，因爲設計上的緣由，TCP歷來就不適合處理有損無線環境中的數據傳輸。在互聯網的早期，有線網絡將網絡中的每一臺計算機鏈接起來。

如今，隨着智能手機和便攜式設備的數量超過臺式機和筆記本電腦的數量，超過50%的互聯網流量已經經過無線傳輸。這種趨勢給總體的網絡瀏覽體驗帶來了問題，其中最重要的是在無線覆蓋率不足的狀況下，TCP中的行頭阻塞（關於TCP在移動網絡下的不足，請閱讀《5G時代已經到來，TCP/IP老矣，尚能飯否？》）。

Google的一些初步實驗證實，QUIC做爲Google部分熱門服務的底層傳輸協議，極大地提升了速度和用戶體驗。部署QUIC做爲YouTube視頻的底層傳輸協議，致使YouTube視頻流的緩衝率降低了30%，這直接影響了用戶的視頻觀看體驗。在顯示谷歌搜索結果時，也有相似的改善。

網絡條件較差的狀況下提高很是明顯，這促使谷歌更加積極地完善該協議，並最終向IETF提出標準化。

因爲這些早期的試驗所帶來的全部改進，QUIC已經成爲帶領萬維網走向將來的重要因素。在QUIC的支持下，HTTP從HTTP/2到HTTP/3的改頭換面，朝着這個方向合理地邁出了一步。

HTTP/3 的侷限性

過渡到HTTP/3不只涉及到應用層的變化，還涉及到底層傳輸層的變化。所以，與它的前身HTTP/2相比，HTTP/3的採用更具挑戰性，由於後者只須要改變應用層。傳輸層承受着網絡中的大量中間層審查。這些中間層，如防火牆、代理、NAT設備等會進行大量的深度數據包檢查，以知足其功能需求。所以，新的傳輸機制的引入對IT基礎設施和運維團隊來講有一些影響。

然而，HTTP/3被普遍採用的另外一個問題是，它是基於QUIC的，在UDP上運行。大多數的Web流量，以及IETF定義的知名服務都是在TCP之上運行的。這也是爲何長時間運行HTTP/3的UDP會話會被防火牆的默認數據包過濾策略所影響的緣由。

隨着IETF正在進行的標準化工做，這些問題最終都會獲得解決。此外，考慮到Google在早期QUIC實驗所顯示的積極結果，人們對HTTP/3的支持是壓倒性的，這將最終迫使中間層廠商標準化。

針對受限的IoT設備，HTTP/3因爲過於繁瑣從而沒法採用。許多IoT應用部署的設備的外形尺寸很是小。所以，它們的RAM和CPU功率都是有限的。爲了使設備在電池功率、低比特率和有損鏈接等限制條件下高效運行，必須執行此要求。HTTP/3在現有的UDP之上，以QUIC的形式在傳輸層處理，增長了HTTP/3在整個協議棧中的佔用空間。這使得HTTP/3較爲笨重，不適合那些IoT設備。但這種狀況不多出現，並且存在專門的協議，這就避免了直接在此類設備上支持HTTP的須要。此外，還有以物聯網爲核心的協議，如MQTT。 

 

關於 HTTP 系列文章：

• HTTP 概述

• TCP 三次握手和四次揮手圖解（有限狀態機）

• 從你輸入網址，到看到網頁——詳解中間發生的過程

• 深刻淺出 HTTPS (詳解版)

• 漫談 HTTP 鏈接

• 漫談 HTTP 性能優化

• HTTP 報文格式簡介

• 深刻淺出：HTTP/2

 

參考文章

網絡編程懶人入門(十二)：快速讀懂Http/3協議，一篇就夠！

透視HTTP協議

HTTP/3 原理實戰