碼小辮專注更多程式設計視訊和電子書作者：billpchen，騰訊看點前端開發工程師
2015 年 HTTP/2 标準發表後，大多數主流浏覽器也于當年年底支援該标準。此後，憑借着多路複用、頭部壓縮、伺服器推送等優勢，HTTP/2 得到了越來越多開發者的青睐，不知不覺的 HTTP 已經發展到了第三代。本文基于興趣部落接入 HTTP/3 的實踐，聊一聊 HTTP/3 的原理以及業務接入的方式。
1. HTTP/3 原理
1.1 HTTP 曆史
在介紹 HTTP/3 之前，我們先簡單看下 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。
1.2 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 有更深的了解。
1.3 零 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 都被劫持，那麼靠現在的計算機算力也沒法破解密鑰。
1.4 連接配接遷移
TCP 連接配接基于四元組（源 IP、源端口、目的 IP、目的端口），切換網絡時至少會有一個因素發生變化，導緻連接配接發生變化。當連接配接發生變化時，如果還使用原來的 TCP 連接配接，則會導緻連接配接失敗，就得等原來的連接配接逾時後重建立立連接配接，是以我們有時候發現切換到一個新網絡時，即使新網絡狀況良好，但内容還是需要加載很久。如果實作得好，當檢測到網絡變化時立刻建立新的 TCP 連接配接，即使這樣，建立新的連接配接還是需要幾百毫秒的時間。
QUIC 的連接配接不受四元組的影響，當這四個元素發生變化時，原連接配接依然維持。那這是怎麼做到的呢？道理很簡單，QUIC 連接配接不以四元組作為辨別，而是使用一個 64 位的随機數，這個随機數被稱為 Connection ID，即使 IP 或者端口發生變化，隻要 Connection ID 沒有變化，那麼連接配接依然可以維持。
1.5 隊頭阻塞/多路複用
HTTP/1.1 和 HTTP/2 都存在隊頭阻塞問題（Head of line blocking），那什麼是隊頭阻塞呢？
TCP 是個面向連接配接的協定，即發送請求後需要收到 ACK 消息，以确認對方已接收到資料。如果每次請求都要在收到上次請求的 ACK 消息後再請求，那麼效率無疑很低。後來 HTTP/1.1 提出了 Pipelining 技術，允許一個 TCP 連接配接同時發送多個請求，這樣就大大提升了傳輸效率。
在這個背景下，下面就來談 HTTP/1.1 的隊頭阻塞。下圖中，一個 TCP 連接配接同時傳輸 10 個請求，其中第 1、2、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 的資料包在接收端沒有處理順序，即使中間丢失一個包，也不會阻塞整條連接配接，其他的資源會被正常處理。
1.6 擁塞控制
擁塞控制的目的是避免過多的資料一下子湧入網絡，導緻網絡超出最大負荷。QUIC 的擁塞控制與 TCP 類似，并在此基礎上做了改進。是以我們先簡單介紹下 TCP 的擁塞控制。
TCP 擁塞控制由 4 個核心算法組成：慢啟動、擁塞避免、快速重傳和快速恢複，了解了這 4 個算法，對 TCP 的擁塞控制也就有了大概了解。
- 慢啟動：發送方向接收方發送 1 個機關的資料，收到對方确認後會發送 2 個機關的資料，然後依次是 4 個、8 個……呈指數級增長，這個過程就是在不斷試探網絡的擁塞程度，超出門檻值則會導緻網絡擁塞；
- 擁塞避免：指數增長不可能是無限的，到達某個限制（慢啟動門檻值）之後，指數增長變為線性增長；
- 快速重傳：發送方每一次發送時都會設定一個逾時計時器，逾時後即認為丢失，需要重發；
- 快速恢複：在上面快速重傳的基礎上，發送方重新發送資料時，也會啟動一個逾時定時器，如果收到确認消息則進入擁塞避免階段，如果仍然逾時，則回到慢啟動階段。
QUIC 重新實作了 TCP 協定的 Cubic 算法進行擁塞控制，并在此基礎上做了不少改進。下面介紹一些 QUIC 改進的擁塞控制的特性。
1.6.1 熱插拔
TCP 中如果要修改擁塞控制政策，需要在系統層面進行操作。QUIC 修改擁塞控制政策隻需要在應用層操作，并且 QUIC 會根據不同的網絡環境、使用者來動态選擇擁塞控制算法。
1.6.2 前向糾錯 FEC
QUIC 使用前向糾錯(FEC，Forward Error Correction)技術增加協定的容錯性。一段資料被切分為 10 個包後，依次對每個包進行異或運算，運算結果會作為 FEC 包與資料包一起被傳輸，如果不幸在傳輸過程中有一個資料包丢失，那麼就可以根據剩餘 9 個包以及 FEC 包推算出丢失的那個包的資料，這樣就大大增加了協定的容錯性。
這是符合現階段網絡技術的一種方案，現階段帶寬已經不是網絡傳輸的瓶頸，往返時間才是，是以新的網絡傳輸協定可以适當增加資料備援，減少重傳操作。
1.6.3 單調遞增的 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 對應的是原始請求還是重傳請求。
1.6.4 ACK Delay
TCP 計算 RTT 時沒有考慮接收方接收到資料到發送确認消息之間的延遲，如下圖所示，這段延遲即 ACK Delay。QUIC 考慮了這段延遲，使得 RTT 的計算更加準确。
1.6.5 更多的 ACK 塊
一般來說，接收方收到發送方的消息後都應該發送一個 ACK 回複，表示收到了資料。但每收到一個資料就傳回一個 ACK 回複太麻煩，是以一般不會立即回複，而是接收到多個資料後再回複，TCP SACK 最多提供 3 個 ACK block。但有些場景下，比如下載下傳，隻需要伺服器傳回資料就好，但按照 TCP 的設計，每收到 3 個資料包就要“禮貌性”地傳回一個 ACK。而 QUIC 最多可以捎帶 256 個 ACK block。在丢包率比較嚴重的網絡下，更多的 ACK block 可以減少重傳量，提升網絡效率。
1.7 流量控制
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 接收視窗 。
2. 總結
QUIC 丢掉了 TCP、TLS 的包袱，基于 UDP，并對 TCP、TLS、HTTP/2 的經驗加以借鑒、改進，實作了一個安全高效可靠的 HTTP 通信協定。憑借着 0 RTT 建立連接配接、平滑的連接配接遷移、基本消除了隊頭阻塞、改進的擁塞控制和流量控制等優秀的特性，QUIC 在絕大多數場景下獲得了比 HTTP/2 更好的效果。
一周前，微軟宣布開源自己的内部 QUIC 庫 -- MsQuic，将全面推薦 QUIC 協定替換 TCP/IP 協定。
HTTP/3 未來可期。
*版權聲明：轉載文章和圖檔均來自公開網絡，版權歸作者本人所有，推送文章除非無法确認，我們都會注明作者和來源。如果出處有誤或侵犯到原作者權益，請與我們聯系删除或授權事宜。