文章目錄
一、QUIC 如何解決TCP的隊頭阻塞問題？
1.1 TCP 爲何會有隊頭阻塞問題
前篇博文：HTTP/2 是如何解決HTTP/1.1 性能瓶頸的？中介紹了HTTP/2 相比HTTP/1.1 設計出的一些優秀的改進方案，大幅提高了HTTP 的網絡利用效率。HTTP/2 在應用協議層通過多路複用同一個TCP連接解決了隊頭阻塞問題，但這是以下層協議比如TCP 協議不出現任何數據包阻塞爲前提的。TCP 在實際運行中，特別是遇到網絡環境不好時，數據包超時確認或丟失是常有的事，假如某個數據包丟失需要重傳時會發生什麼呢？
在博文：網絡傳輸管理之TCP協議中介紹了TCP 的工作原理與實現過程，TCP 採用正面確認和超時重傳機制來保證數據包的可靠交付。比如主機A 向 主機B 發送數據包，主機B 收到該數據包後會向主機A 返回確認應答報文，表示自己確實收到了該數據包，主機A 收到確認應答報文後才確定上一個數據包已經發送成功，開始發送下一個數據包。如果超過一定時間（根據每次測量的往返時間RTT估算出的動態閾值）未收到確認應答，則主機A 判斷上一個數據包丟失了，重新發送上一個數據包，這就相當於阻塞了下一個數據包的發送。
逐個發送數據包，等待確認應答到來後再發送下一個數據包，效率太低了，TCP 採用滑動窗口機制來提高數據傳輸效率。窗口大小就是指無需等待確認應答而可以繼續發送數據的最大值，這個機制實現了使用大量的緩衝區，通過對多個數據包同時進行確認應答的功能。當可發送數據的窗口消耗殆盡時，就需要等待收到連續的確認應答後，當前窗口才會向前滑動，爲發送下一批數據包騰出窗口。假設某個數據包超時未收到確認應答，當前窗口就會阻塞在原地，重新發送該數據包，在收到該重發數據包的確認應答前，就不會有新增的可發送數據包了。也就是說，因爲某個數據包丟失，當前窗口阻塞在原地，同樣阻塞了後續所有數據包的發送。
TCP 因爲超時確認或丟包引起的滑動窗口阻塞問題，是不是有點像HTTP/1.1 管道化機制中出現的隊頭阻塞問題？HTTP/2 在應用協議層通過多路複用解決了隊頭阻塞問題，但TCP 在傳輸層依然存在隊頭阻塞問題，這是TCP 協議的一個主要性能瓶頸。該怎麼解決TCP 的隊頭阻塞問題呢？
1.2 QUIC 如何解決隊頭阻塞問題
TCP 隊頭阻塞的主要原因是數據包超時確認或丟失阻塞了當前窗口向右滑動，我們最容易想到的解決隊頭阻塞的方案是不讓超時確認或丟失的數據包將當前窗口阻塞在原地。QUIC (Quick UDP Internet Connections)也正是採用上述方案來解決TCP 隊頭阻塞問題的。
TCP 爲了保證可靠性，使用了基於字節序號的 Sequence Number 及 Ack 來確認消息的有序到達。QUIC 同樣是一個可靠的協議，它使用 Packet Number 代替了 TCP 的 Sequence Number，並且每個 Packet Number 都嚴格遞增，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經不是 N，而是一個比 N 大的值，比如Packet N+M。
QUIC 使用的Packet Number 單調遞增的設計，可以讓數據包不再像TCP 那樣必須有序確認，QUIC 支持亂序確認，當數據包Packet N 丟失後，只要有新的已接收數據包確認，當前窗口就會繼續向右滑動。待發送端獲知數據包Packet N 丟失後，會將需要重傳的數據包放到待發送隊列，重新編號比如數據包Packet N+M 後重新發送給接收端，對重傳數據包的處理跟發送新的數據包類似，這樣就不會因爲丟包重傳將當前窗口阻塞在原地，從而解決了隊頭阻塞問題。那麼，既然重傳數據包的Packet N+M 與丟失數據包的Packet N 編號並不一致，我們怎麼確定這兩個數據包的內容一樣呢？
還記得前篇博文：HTTP/2 是如何解決HTTP/1.1 性能瓶頸的？使用Stream ID 來標識當前數據流屬於哪個資源請求，這同時也是數據包多路複用傳輸到接收端後能正常組裝的依據。重傳的數據包Packet N+M 和丟失的數據包Packet N 單靠Stream ID 的比對一致仍然不能判斷兩個數據包內容一致，還需要再新增一個字段Stream Offset，標識當前數據包在當前Stream ID 中的字節偏移量。
有了Stream Offset 字段信息，屬於同一個Stream ID 的數據包也可以亂序傳輸了（HTTP/2 中僅靠Stream ID 標識，要求同屬於一個Stream ID 的數據幀必須有序傳輸），通過兩個數據包的Stream ID 與 Stream Offset 都一致，就說明這兩個數據包的內容一致。
上圖中數據包Packet N 丟失了，後面重傳該數據包的編號爲Packet N+2，丟失的數據包和重傳的數據包Stream ID 與 Offset 都一致，說明這兩個數據包的內容一致。這些數據包傳輸到接收端後，接收端能根據Stream ID 與 Offset 字段信息正確組裝成完整的資源。
QUIC 通過單向遞增的Packet Number，配合Stream ID 與 Offset 字段信息，可以支持非連續確認應答Ack而不影響數據包的正確組裝，擺脫了TCP 必須按順序確認應答Ack 的限制（也即不能出現非連續的空位），解決了TCP 因某個數據包重傳而阻塞後續所有待發送數據包的問題（也即隊頭阻塞問題）。
QUIC 可以支持非連續的數據包確認應答Ack，自然也就要求每個數據包的確認應答Ack 都能返回給發送端（TCP 中間丟失幾個Ack 對數據包的確認應答影響不大），發送端收到該數據包的確認應答後纔會釋放該數據包所佔用的緩存資源，已發送但未收到確認應答的數據包會保存在緩存鏈表中等待可能的重傳。QUIC 對確認應答Ack 丟失的容忍度比較低，自然對Ack 的傳輸能力進行了增強，Quic Ack Frame 可以同時提供 256 個 Ack Block，在丟包率比較高的網絡下，更多的 Ack Block 可以提高Ack 送達的成功率，減少重傳量。
1.3 QUIC 沒有隊頭阻塞的多路複用
QUIC 解決了TCP 的隊頭阻塞問題，同時繼承了HTTP/2 的多路複用優點，因爲Stream Offset 字段的引入，QUIC 中同一Stream ID 的數據幀也支持亂序傳輸，不再像HTTP/2 要求的同一Stream ID 的數據幀必須有序傳輸那麼嚴格。
從上面QUIC 的數據包結構中可以看出，同一個Connection ID 可以同時傳輸多個Stream ID，由於QUIC 支持非連續的Packet Number 確認，某個Packet N 超時確認或丟失，不會影響其它未包含在該數據包中的Stream Frame 的正常傳輸。同一個Packet Number 可承載多個Stream Frame，若該數據包丟失，則其承載的Stream Frame 都需要重新傳輸。因爲同一Stream ID 的數據幀亂序傳輸後也能正確組裝，這些需要重傳的Stream Frame 並不會影響其它待發送Stream Frame 的正常傳輸。
值得一提的是，TLS 協議加解密前需要對數據進行完整性校驗，HTTP/2 中如果TCP 出現丟包，TLS 也會因接收到的數據不完整而無法對其進行處理，也即HTTP/2 中的TLS 協議層也存在隊頭阻塞問題，該問題如何解決呢？既然TLS 協議是因爲接收數據不完整引起的阻塞，我們只需要讓TLS 加密認證過程基於一個獨立的Packet，不對多個Packet 同時進行加密認證，就能解決TLS 協議層出現的隊頭阻塞問題，某一個Packet 丟失只會影響封裝該Packet 的Record，不會讓其它Record 陷入阻塞等待的情況。
二、QUIC 如何優化TCP 的連接管理機制？
2.1 TCP連接的本質是什麼
你可能熟悉TCP 建立連接的三次握手和四次揮手過程，但你知道TCP 建立的連接本質上是什麼嗎？這裏的連接跟我們熟悉的物理介質連接（比如電路連接）不同，主要是用來說明如何在物理介質上傳輸數據的。
爲了更直觀瞭解網絡連接概念，我們拿面向連接的TCP 與無連接的UDP 做對比，網絡傳輸層的兩個主流協議，他們的主要區別是什麼呢？UDP 每個分組的處理都獨立於所有其他分組，TCP 每個分組的傳輸都有確認應答過程和可能的丟包重傳過程，需要爲每個分組數據進行狀態信息記錄和管理（比如未發送、已發送、未確認、已確認等狀態）。
TCP 建立連接的三次握手過程都做了哪些工作呢？首先確認雙方是否能正常收發數據，通信雙方交換待發送數據的初始序列編號並作爲有序確認應答的基點，通信雙方根據預設的狀態轉換圖完成各自的狀態遷移過程，通信雙方爲分組數據的可靠傳輸和狀態信息的記錄管理分配控制塊緩存資源等。下面給出TCP 連接建立、數據傳輸、連接釋放三個階段的報文交互過程和狀態遷移圖示（詳見博文：TCP協議與Transmission Control Protocol）：
從上圖可以看出，TCP 連接主要是雙方記錄並同步維護的狀態組成的。一般來說，建立連接是爲了維護前後分組數據的承繼關係，維護前後承繼關係最常用的方法就是對其進行狀態記錄和管理，比如博文：圖解HTTP中爲彌補無狀態協議HTTP 不足設計的Cookie 字段可以實現狀態記錄和管理功能。
TCP 的狀態管理可以分爲連接狀態管理和分組數據狀態管理兩種，連接狀態管理用於雙方同步數據發送與接收狀態，分組數據狀態管理用於保證數據的可靠傳輸。涉及到狀態管理一般都有狀態轉換圖，TCP 連接管理的狀態轉換圖上面已經給出了，HTTP/2 的Stream 實際上也記錄並維護了每個Stream Frame 的狀態信息，Stream 的狀態轉換圖如下（詳見博文：HTTP/2 中的幀和流）：
2.2 QUIC 如何減少TCP 建立連接的開銷
TCP 建立連接需要三次握手過程，第三次握手報文發出後不需要等待應答回覆就可以發送數據報文了，所以TCP 建立連接的開銷爲 1-RTT。既然TCP 連接主要是由雙方記錄並同步維護的狀態組成的，我們能否借鑑TLS 快速恢復簡短握手相比完整握手的優化方案呢？
TLS 簡短握手過程是將之前完整握手過程協商的信息記錄下來，以Session Ticket 的形式傳輸給客戶端，如果想恢復之前的會話連接，可以將Session Ticket 發送給服務器，就能通過簡短的握手過程重建或者恢復之前的連接，通過複用之前的握手信息可以節省 1-RTT 的連接建立開銷。
TCP 也提供了快速建立連接的方案 TFO (TCP Fast Open)，原理跟TLS 類似，也是將首次建立連接的狀態信息記錄下來，以Cookie 的形式傳輸給客戶端，如果想複用之前的連接，可以將Cookie 發送給服務器，如果服務器通過驗證就能快速恢復之前的連接，TFO 技術可以通過複用之前的連接將連接建立開銷縮短爲 0-RTT。因爲TCP 協議內置於操作系統中，操作系統的升級普及過程較慢，因此TFO 技術至今仍未普及（TFO 在2014年發佈於RFC 7413）。
從上圖可知，TCP 首次建立連接的開銷爲 1-RTT，快速複用/打開連接的開銷爲 0-RTT，這與TLS 1.3 協議首次完整握手與快速恢復簡短握手的開銷一致。
客戶端發送的第一個SYN 握手包是可以攜帶數據的，但爲了防止TCP 泛洪攻擊，TCP 的實現者不允許將SYN 攜帶的數據包上傳給應用層。HTTP 協議中TCP 與TLS 常常配合使用，這裏TCP 的第一個SYN 握手包可以攜帶TLS 1.3 的握手包，這就可以將TCP + TLS 總的握手開銷進一步降低。
首次建立連接時，TCP 和TLS 1.3 都只需要 1-RTT 就可以完成握手過程，由於TCP 第一個SYN 握手包可以攜帶TLS 的握手包，因此TCP + TLS 1.3 總的首次建立連接開銷爲 1-RTT。當要快速恢復之前的連接時，TFO 和TLS 1.3 都只需要 0-RTT 就可以完成握手過程，因此TCP + TLS 1.3 總的連接恢復開銷爲 0-RTT。
QUIC 可以理解爲”TCP + TLS 1.3“（QUIC 是基於UDP的，可能使用的是DTLS 1.3），QUIC 自然也實現了首次建立連接的開銷爲 1-RTT，快速恢復先前連接的開銷爲 0-RTT 的效率。QUIC 作爲HTTP/2 的改進版，建立連接的開銷也有明顯降低，下面給出HTTP/2 和QUIC 首次連接和會話恢復過程中，HTTP 請求首個資源的RTT 開銷對比：
| HTTP/2 + TLS 1.2 首次連接 | HTTP/2 + TLS 1.2 會話恢復 | HTTP/2 + TLS 1.3 首次連接 | HTTP/2 + TLS 1.3 會話恢復 | HTTP/2 + TLS 1.3 會話恢復 + TFO | QUIC 首次連接 | QUIC 會話恢復 | |
|---|---|---|---|---|---|---|---|
| DNS 解析 | 1-RTT | 0-RTT | 1-RTT | 0-RTT | 0-RTT | 1-RTT | 0-RTT |
| TCP 握手 | 1-RTT | 1-RTT | 1-RTT | 1-RTT | 0-RTT (TCP Fast Open) |
- | - |
| TLS 握手 | 2-RTT | 1-RTT | 1-RTT | 0-RTT | 0-RTT | - | - |
| QUIC 握手 | - | - | - | - | - | 1-RTT | 0-RTT |
| HTTP 請求 | 1-RTT | 1-RTT | 1-RTT | 1-RTT | 1-RTT | 1-RTT | 1-RTT |
| 總計 | 5-RTT | 3-RTT | 4-RTT | 2-RTT | 1-RTT | 3-RTT | 1-RTT |
從上表可以看出，QUIC 首次建立連接的開銷比"HTTP/2 + TLS 1.3"減少了 1-RTT，會話/連接恢復的開銷降低到了 0-RTT（除去HTTP 自身請求資源的開銷），顯著降低了網頁請求延遲。
值得一提的是，TCP 因爲報文首部是透明傳輸的，在安全防護方便比較脆弱，容易受到網絡攻擊。QUIC 因爲有TLS 對數據包首部進行加密和驗證，增加了安全防護強度，更不容易受到網絡攻擊。
2.3 QUIC 如何實現連接的無感遷移
每個網絡連接都應該有一個唯一的標識，用來辨識並區分特定的連接。TCP 連接使用<Source IP, Source Port, Target IP, Target Port> 這四個信息共同標識，在早期PC 時代，這四個元素信息可以唯一標識通信雙方的主機及端口，報文中也不需要一個專門的字段來標識連接，減少了傳輸開銷。
到了移動互聯網時代，客戶端（比如手機）的位置可能一直在變，接入不同的基站可能就會被分配不同的Source IP 和Source Port。即便在家裏，客戶端可能也需要在LTE 和WIFI 之間切換，這兩個網絡分配給客戶端的Source IP 和Source Port 可能也是不同的。TCP 用來標識連接的四個信息中的任何一個改變，都相當於TCP 連接標識改變了，也就變成了不同的連接，TCP 需要先斷開舊的連接再建立新的連接，很顯然連接切換或遷移過程不夠順暢高效。
未來移動設備越來越多，在通話或者玩遊戲等對實時性要求較高的場景中，因爲網絡遷移或切換導致TCP 斷開連接會大大降低網絡服務體驗，怎麼解決TCP 因爲網絡遷移或切換導致斷線重連的問題呢？早期移動電話使用Mobile IP 技術來解決網絡遷移或切換過程引起的斷連問題，Mobile IP 主要是通過新建IP 隧道的方式（也即建立一個新連接來轉發數據包）保持原來的連接不斷開，但這種方式增加了數據包的傳輸路徑，也就增大了數據包的往返時間，降低了數據包的傳輸效率。Mobile IP 的工作原理如下（移動主機遷移到外部代理後，爲了保持原連接不斷開，新建了一條到歸屬代理的IP 隧道，讓歸屬代理以原主機IP 轉發數據包）：
TCP 爲保持前向兼容性，沒法重新設計連接標識，但爲了解決移動主機連接切換問題還是推出了一套解決方案MPTCP (Multipath TCP，在2013年發佈於RFC 6824) 。針對移動主機同時支持LTE 和WIFI 等多條連接鏈路的情況，設計的多路徑TCP 技術(MPTCP) 允許在一條TCP 鏈路中建立多個子通道，每個子通道都可以按照三次握手的方式建立連接，每個子通道的連接允許IP 不一致，這些子通道都會綁定到MPTCP Session（比如通過LTE 和WIFI 各建立一個子通道），發送端的數據可以選擇其中一條通道進行傳輸。MPTCP 可以讓移動主機在多個連接鏈路間順暢切換，切換過程不斷開連接。對於移動主機跨基站連接遷移的問題，也可以在原基站與目標遷移基站之間各建立一個連接鏈路/子通道，當移動主機從一個基站遷移到另一個基站時，只是從一個鏈路子通道切換到另一個鏈路子通道，同樣能讓連接鏈路順暢遷移而不斷開連接。MPTCP 跟TFO 技術類似，需要操作系統及網絡協議棧支持，更新和部署阻力較大，目前並不適用。
QUIC 擺脫了TCP 的諸多限制，可以重新設計連接標識，還記得前面給出的QUIC 數據包結構嗎？QUIC 數據包結構中有一個Connection ID 字段專門標識連接，Connection ID 是一個64位的通用唯一標識UUID (Universally Unique IDentifier)。藉助Connection ID，QUIC 的連接不再綁定IP 與 Port 信息，即便因爲網絡遷移或切換導致Source IP 和Source Port 發生變化，只要Connection ID 不變就仍是同一個連接，協議層只需要將控制塊中記錄的Source IP 和Source Port 信息更新即可，不需要像TCP 那樣先斷開連接，這就可以保證連接的順暢遷移或切換，用戶基本不會感知到連接切換過程。
三、QUIC 如何改進TCP 的擁塞控制機制？
3.1 TCP 擁塞控制機制的瓶頸在哪？
計算機網絡都處於一個共享環境中，可能會因爲其它主機之間的通信使得網絡擁堵，如果在通信剛開始時就突然發送大量數據，可能會導致整個網絡的擁堵阻塞。TCP爲了防止該問題的出現，設計了擁塞控制機制來限制數據包的發送帶寬，實際就是控制發送窗口的大小。TCP 發送數據的速率受到兩個因素限制：一個是目前接收窗口的大小，通過接收端的實際接收能力來控制發送速率的機制稱爲流量控制機制；另一個是目前擁塞窗口的大小，通過慢啓動和擁塞避免算法來控制發送速率的機制稱爲擁塞控制機制，TCP 發送窗口大小被限制爲不超過接收窗口和擁塞窗口的較小值。
TCP 通信開始時，會通過慢啓動算法得出的擁塞窗口大小對發送數據速率進行控制，慢啓動階段擁塞窗口大小從1 開始按指數增大（每收到一次確認應答擁塞窗口值加1，收到一個窗口大小數量的確認應答則擁塞窗口大小翻倍），雖然擁塞窗口增長率較快，但由於初始值較小，增長到慢啓動閾值仍然需要花費不少時間。爲了防止擁塞窗口後期增長過快，當擁塞窗口大小超過慢啓動閾值（一般爲發生超時重傳或重複確認應答時，擁塞窗口一半的大小）後，就變更爲線性增長（每收到一個窗口大小數量的確認應答則擁塞窗口大小增加一個數據段），直到發生超時重傳或重複確認應答，擁塞窗口向下調整，擁塞窗口大小變化過程如下圖示：
從上圖可以看出，TCP 發生超時重傳時，擁塞窗口直接下調爲 1，並從慢啓動階段開始逐漸增大擁塞窗口，當超過慢啓動閾值後進入擁塞避免階段，這個過程對網絡傳輸效率影響較大。TCP 發生重複確認應答而觸發快速重傳時，判斷網絡擁堵情況更輕些，因此擁塞窗口下調爲慢啓動閾值 + 3個數據段的大小，相當於直接跨過慢啓動階段進入擁塞避免階段，這個過程對網絡傳輸效率影響相對較小，這種機制稱爲快速恢復機制。
現在網絡帶寬相比TCP協議剛誕生時有了明顯的改善，TCP 的擁塞控制算法也成爲影響網絡傳輸效率的一個瓶頸，如果觸發超時重傳的次數比較多，對網絡傳輸效率的影響相當大。
3.2 QUIC 如何降低重傳概率
TCP 的擁塞控制機制是被超時重傳或者快速重傳觸發的，想要提高網絡傳輸效率，容易想到兩個方案：一個是改進擁塞控制算法；另一個是降低重傳次數。這裏先介紹如何降低重傳次數/概率？
降低TCP 的重傳概率有兩個方向：
- 降低超時重傳概率：可以通過改善網絡環境，提高重發超時閾值的計算準確度，也就是提高往返時間RTT 的測量準確度，來降低超時重傳概率；
- 降低丟包重傳概率：可以增加傳輸一定的冗餘數據比如糾錯碼，當丟失部分數據時可以通過糾錯碼恢復丟失的數據，降低丟包重傳的概率。
由於TCP 重傳 segment 的 Sequence Number 和原始的 segment 的 Sequence Number 保持不變，當發送端觸發重傳數據包Sequence N後，接收到了該數據包，發送端無法判斷接收到的數據包是來自原始請求的響應，還是來自重傳請求的響應，這就帶來了TCP 重傳的歧義性，該問題肯定會影響採樣RTT 測量值的準確性，進而影響重發超時閾值計算的準確度，可能會增大數據包超時重傳的概率。
QUIC 採用單向遞增的Packet Number 來標識數據包，原始請求的數據包與重傳請求的數據包編號並不一樣，自然也就不會引起重傳的歧義性，採樣RTT 的測量更準確。
除此之外，QUIC 計算RTT 時除去了接收端的應答延遲時間，更準確的反映了網絡往返時間，進一步提高了RTT 測量的準確性，降低了數據包超時重傳的概率。
TCP 傳輸的數據只包括校驗碼，並沒有增加糾錯碼等冗餘數據，如果出現部分數據丟失或損壞，只能重新發送該數據包。沒有冗餘的數據包雖然降低了傳輸開銷，但增加了丟包重傳概率，因爲重傳觸發擁塞控制機制，勢必會降低網絡傳輸效率。適當增加點冗餘數據，當丟失或損壞的數據量較少時，就可以靠冗餘數據恢復丟失或損壞的部分，降低丟包重傳概率。只要冗餘數據比例設置得當，提高的網絡傳輸效率就可以超過增加的網絡傳輸開銷，帶來網絡利用率的正向提升。
QUIC 引入了前向冗餘糾錯碼（FEC: Fowrard Error Correcting），如果接收端出現少量（不超過FEC的糾錯能力）的丟包或錯包，可以藉助冗餘糾錯碼恢復丟失或損壞的數據包，這就不需要再重傳該數據包了，降低了丟包重傳概率，自然就減少了擁塞控制機制的觸發次數，可以維持較高的網絡利用效率。
糾錯碼的原理比較複雜，如果想對糾錯碼有更多的瞭解，可以參考文章：二維碼的祕密，文中簡單介紹了二維碼中的糾錯碼是如何實現信息糾錯和補全的。
3.3 QUIC 如何改進擁塞控制機制
TCP 的擁塞控制實際上包含了四個算法：慢啓動、擁塞避免、快速重傳、快速恢復。現在網絡環境改善速度較快，TCP 的慢啓動與擁塞避免過程需要的時間較長，雖然TCP 也在不斷更新改進擁塞控制算法，但由於TCP 內置於操作系統，擁塞控制算法的更新速度太過緩慢，跟不上網絡環境改善速度，TCP 落後的擁塞控制算法自然會降低網絡利用效率。
QUIC 協議當前默認使用了 TCP 的 Cubic 擁塞控制算法，同時也支持 CubicBytes、Reno、RenoBytes、BBR、PCC 等擁塞控制算法，相當於將TCP 的擁塞控制算法照搬過來了，QUIC 是如何改進TCP 的擁塞控制算法的呢？
QUIC 直接照搬TCP 的擁塞控制算法只是借鑑了TCP 經過驗證的成熟方案，由於QUIC 是處於應用層的，可以隨瀏覽器更新，QUIC 的擁塞控制算法就可以有較快的迭代速度，在TCP 的擁塞控制算法基礎上快速迭代，可以跟上網絡環境改善的速度，儘快提高擁塞恢復的效率。
QUIC 還將擁塞控制算法設計爲可插拔模塊，可以根據需要爲不同的連接配置不同的擁塞控制算法，這樣可以爲每個連接根據其網絡環境配置最適合的擁塞控制算法（可以根據大數據和人工智能計算結果自動精準配置），儘可能讓每個連接的網絡帶寬得到最高效的利用。