QUIC 是如何解決 TCP 性能瓶頸的？

作者：流雲 IoT

鏈接：https://blog.csdn.net/m0_37621078/article/details/106506532

重新整理：極客重生

文章目錄

一、QUIC 如何解決 TCP 的隊頭阻塞問題？

二、QUIC 如何優化 TCP 的連接管理機制？

三、QUIC 如何改進 TCP 的擁塞控制機制？

1.1 TCP 爲何會有隊頭阻塞問題

HTTP/2 相比 HTTP/1.1 設計出的一些優秀的改進方案，大幅提高了 HTTP 的網絡利用效率。HTTP/2 在應用協議層通過多路複用同一個 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 陷入阻塞等待的情況。

2.1 TCP 連接的本質是什麼？

你可能熟悉 TCP 建立連接的三次握手和四次揮手過程，但你知道 **TCP 建立的連接本質上是什麼嗎？**這裏的連接跟我們熟悉的物理介質連接（比如電路連接）不同，主要是用來說明如何在物理介質上傳輸數據的。

爲了更直觀瞭解網絡連接概念，我們拿面向連接的 TCP 與無連接的 UDP 做對比，網絡傳輸層的兩個主流協議，他們的主要區別是什麼呢？UDP 每個分組的處理都獨立於所有其他分組，TCP 每個分組的傳輸都有確認應答過程和可能的丟包重傳過程，需要爲每個分組數據進行狀態信息記錄和管理（比如未發送、已發送、未確認、已確認等狀態）。

TCP 建立連接的三次握手過程都做了哪些工作呢？首先確認雙方是否能正常收發數據，通信雙方交換待發送數據的初始序列編號並作爲有序確認應答的基點，通信雙方根據預設的狀態轉換圖完成各自的狀態遷移過程，通信雙方爲分組數據的可靠傳輸和狀態信息的記錄管理分配控制塊緩存資源等。下面給出 TCP 連接建立、數據傳輸、連接釋放三個階段的報文交互過程和狀態遷移圖示（詳見博文：TCP 協議與 Transmission Control Protocol）：

從上圖可以看出，TCP 連接主要是雙方記錄並同步維護的狀態組成的。一般來說，建立連接是爲了維護前後分組數據的承繼關係，維護前後承繼關係最常用的方法就是對其進行狀態記錄和管理。

TCP 的狀態管理可以分爲連接狀態管理和分組數據狀態管理兩種，連接狀態管理用於雙方同步數據發送與接收狀態，分組數據狀態管理用於保證數據的可靠傳輸。涉及到狀態管理一般都有狀態轉換圖，TCP 連接管理的狀態轉換圖上面已經給出了，HTTP/2 的 Stream 實際上也記錄並維護了每個 Stream Frame 的狀態信息，Stream 的狀態轉換圖如下：

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 開銷對比：

LfNt5l

從上表可以看出，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 那樣先斷開連接，這就可以保證連接的順暢遷移或切換，用戶基本不會感知到連接切換過程。

3.1 TCP 擁塞控制機制的瓶頸在哪？

計算機網絡都處於一個共享環境中，可能會因爲其它主機之間的通信使得網絡擁堵，如果在通信剛開始時就突然發送大量數據，可能會導致整個網絡的擁堵阻塞。TCP 爲了防止該問題的出現，設計了擁塞控制機制來限制數據包的發送帶寬，實際就是控制發送窗口的大小。TCP 發送數據的速率受到兩個因素限制：一個是目前接收窗口的大小，通過接收端的實際接收能力來控制發送速率的機制稱爲流量控制機制；另一個是目前擁塞窗口的大小，通過慢啓動和擁塞避免算法來控制發送速率的機制稱爲擁塞控制機制，TCP 發送窗口大小被限制爲不超過接收窗口和擁塞窗口的較小值。

TCP 通信開始時，會通過慢啓動算法得出的擁塞窗口大小對發送數據速率進行控制，慢啓動階段擁塞窗口大小從 1 開始按指數增大（每收到一次確認應答擁塞窗口值加 1，收到一個窗口大小數量的確認應答則擁塞窗口大小翻倍），雖然擁塞窗口增長率較快，但由於初始值較小，增長到慢啓動閾值仍然需要花費不少時間。爲了防止擁塞窗口後期增長過快，當擁塞窗口大小超過慢啓動閾值（一般爲發生超時重傳或重複確認應答時，擁塞窗口一半的大小）後，就變更爲線性增長（每收到一個窗口大小數量的確認應答則擁塞窗口大小增加一個數據段），直到發生超時重傳或重複確認應答，擁塞窗口向下調整，擁塞窗口大小變化過程如下圖示：

從上圖可以看出，TCP 發生超時重傳時，擁塞窗口直接下調爲 1，並從慢啓動階段開始逐漸增大擁塞窗口，當超過慢啓動閾值後進入擁塞避免階段，這個過程對網絡傳輸效率影響較大。TCP 發生重複確認應答而觸發快速重傳時，判斷網絡擁堵情況更輕些，因此擁塞窗口下調爲慢啓動閾值 + 3 個數據段的大小，相當於直接跨過慢啓動階段進入擁塞避免階段，這個過程對網絡傳輸效率影響相對較小，這種機制稱爲快速恢復機制。

現在網絡帶寬相比 TCP 協議剛誕生時有了明顯的改善，TCP 的擁塞控制算法也成爲影響網絡傳輸效率的一個瓶頸，如果觸發超時重傳的次數比較多，對網絡傳輸效率的影響相當大。

3.2 QUIC 如何降低重傳概率？

TCP 的擁塞控制機制是被超時重傳或者快速重傳觸發的，想要提高網絡傳輸效率，容易想到兩個方案：一個是改進擁塞控制算法；另一個是降低重傳次數。這裏先介紹如何降低重傳次數 / 概率？

降低 TCP 的重傳概率有兩個方向：

由於 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 還將擁塞控制算法設計爲可插拔模塊，可以根據需要爲不同的連接配置不同的擁塞控制算法，這樣可以爲每個連接根據其網絡環境配置最適合的擁塞控制算法（可以根據大數據和人工智能計算結果自動精準配置），儘可能讓每個連接的網絡帶寬得到最高效的利用。

擴展閱讀

歡迎加我微信 easy_coder 圍觀我的朋友圈～

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/PZ1IbXe396b6gzmWYpFk-Q

猜你喜歡