很多同學第一反應就會說把 TCP 可靠傳輸的特性（序列號、確認應答、超時重傳、流量控制、擁塞控制）在應用層實現一遍。

實現的思路確實這樣沒錯，但是有沒有想過，既然 TCP 天然支持可靠傳輸，為什么還需要基于 UDP 實現可靠傳輸呢？這不是重復造輪子嗎？

所以，我們要先弄清楚 TCP 協議有哪些痛點？而這些痛點是否可以在基于 UDP 協議實現的可靠傳輸協議中得到改進？

在之前這篇文章：TCP 就沒什么缺陷嗎？，我已經說了 TCP 協議四個方面的缺陷：

• 升級 TCP 的工作很困難；
• TCP 建立連接的延遲；
• TCP 存在隊頭阻塞問題；
• 網絡遷移需要重新建立 TCP 連接；

現在市面上已經有基于 UDP 協議實現的可靠傳輸協議的成熟方案了，那就是 QUIC 協議，已經應用在了 HTTP/3。

這次，聊聊 QUIC 是如何實現可靠傳輸的？又是如何解決上面 TCP 協議四個方面的缺陷？

QUIC 是如何實現可靠傳輸的？

要基于 UDP 實現的可靠傳輸協議，那么就要在應用層下功夫，也就是要設計好協議的頭部字段。

拿 HTTP/3 舉例子，在 UDP 報文頭部與 HTTP 消息之間，共有 3 層頭部：

整體看的視角是這樣的：

接下來，分別對每一個 Header 做個介紹。

Packet Header

Packet Header 首次建立連接時和日常傳輸數據時使用的 Header 是不同的。如下圖，注意我沒有把 Header 所有字段都畫出來，只是畫出了重要的字段：

細分這兩種：

• Long Packet Header 用于首次建立連接。
• Short Packet Header 用于日常傳輸數據。

QUIC 也是需要三次握手來建立連接的，主要目的是為了確定連接 ID。

建立連接時，連接 ID 是由服務器根據客戶端的 Source Connection ID 字段生成的，這樣后續傳輸時，雙方只需要固定住 Destination Connection ID（連接 ID ），從而實現連接遷移功能。所以，你可以看到日常傳輸數據的 Short Packet Header 不需要在傳輸 Source Connection ID 字段了。

Short Packet Header 中的 Packet Number 是每個報文獨一無二的編號，它是嚴格遞增的，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經不是 N，而是一個比 N 大的值。

為什么要這么設計呢？

我們先來看看 TCP 的問題，TCP 在重傳報文時的序列號和原始報文的序列號是一樣的，也正是由于這個特性，引入了 TCP 重傳的歧義問題。

比如上圖，當 TCP 發生超時重傳后，客戶端發起重傳，然后接收到了服務端確認 ACK 。由于客戶端原始報文和重傳報文序列號都是一樣的，那么服務端針對這兩個報文回復的都是相同的 ACK。

這樣的話，客戶端就無法判斷出是原始報文的響應還是重傳報文的響應，這樣在計算 RTT（往返時間） 時應該選擇從發送原始報文開始計算，還是重傳原始報文開始計算呢？

• 如果算成原始報文的響應，但實際上是重傳報文的響應（上圖右），會導致采樣 RTT 變大；
• 如果算成重傳報文的響應，但實際上是原始報文的響應（上圖左），又很容易導致采樣 RTT 過小；

RTT 計算不精確的話，那么 RTO （超時時間）也就不精確，因為 RTO 是基于 RTT 來計算的，RTO 計算不準確可能導致重傳的概率事件增大。

QUIC 報文中的 Pakcet Number 是嚴格遞增的， 即使是重傳報文，它的 Pakcet Number 也是遞增的，這樣就能更加精確計算出報文的 RTT。

如果 ACK 的 Packet Number 是 N+M，就根據重傳報文計算采樣 RTT。如果 ACK 的 Pakcet Number 是 N，就根據原始報文的時間計算采樣 RTT，沒有歧義性的問題。

另外，還有一個好處，QUIC 使用的 Packet Number 單調遞增的設計，可以讓數據包不再像TCP 那樣必須有序確認，QUIC 支持亂序確認，當數據包Packet N 丟失后，只要有新的已接收數據包確認，當前窗口就會繼續向右滑動。

待發送端超過一定時間沒收到 Packet N 的確認報文后，會將需要重傳的數據包放到待發送隊列，重新編號比如數據包 Packet N+M 后重新發送給接收端，對重傳數據包的處理跟發送新的數據包類似，這樣就不會因為丟包重傳將當前窗口阻塞在原地，從而解決了隊頭阻塞問題。

所以，Packet Number 單調遞增的兩個好處：

• 可以更加精確計算 RTT，沒有 TCP 重傳的歧義性問題；
• 可以支持亂序確認，防止因為丟包重傳將當前窗口阻塞在原地，而 TCP 必須是順序確認的，丟包時會導致窗口不滑動；

QUIC Frame Header

一個 Packet 報文中可以存放多個 QUIC Frame。

每一個 Frame 都有明確的類型，針對類型的不同，功能也不同，自然格式也不同。我這里只舉例 Stream 類型的 Frame 格式，Stream 可以認為就是一條 HTTP 請求，它長這樣：

• Stream ID 作用：多個并發傳輸的 HTTP 消息，通過不同的 Stream ID 加以區別；
• Offset 作用：類似于 TCP 協議中的 Seq 序號，保證數據的順序性和可靠性；
• Length 作用：指明了 Frame 數據的長度。

在前面介紹 Packet Header 時，說到 Packet Number 是嚴格遞增，即使重傳報文的 Packet Number 也是遞增的，既然重傳數據包的 Packet N+M 與丟失數據包的 Packet N 編號并不一致，我們怎么確定這兩個數據包的內容一樣呢？

所以引入 Frame Header 這一層，通過 Stream ID + Offset 字段信息實現數據的有序性，通過比較兩個數據包的 Stream ID 與 Stream Offset ，如果都是一致，就說明這兩個數據包的內容一致。

舉個例子，下圖中，數據包 Packet N 丟失了，后面重傳該數據包的編號為 Packet N+2，丟失的數據包和重傳的數據包 Stream ID 與 Offset 都一致，說明這兩個數據包的內容一致。這些數據包傳輸到接收端后，接收端能根據 Stream ID 與 Offset 字段信息將 Stream x 和 Stream x+y 按照順序組織起來，然后交給應用程序處理。

總的來說，QUIC 通過單向遞增的 Packet Number，配合 Stream ID 與 Offset 字段信息，可以支持亂序確認而不影響數據包的正確組裝，擺脫了TCP 必須按順序確認應答 ACK 的限制，解決了 TCP 因某個數據包重傳而阻塞后續所有待發送數據包的問題。

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

什么是 TCP 隊頭阻塞問題？

TCP 隊頭阻塞的問題要從兩個角度看，一個是發送窗口的隊頭阻塞，另外一個是接收窗口的隊頭阻塞。

先來說說發送窗口的隊頭阻塞。

TCP 發送出去的數據，都是需要按序確認的，只有在數據都被按順序確認完后，發送窗口才會往前滑動。

舉個例子，比如下圖的發送方把發送窗口內的數據全部都發出去了，可用窗口的大小就為 0 了，表明可用窗口耗盡，在沒收到 ACK 確認之前是無法繼續發送數據了。

接著，當發送方收到對第 32~36 字節的 ACK 確認應答后，則滑動窗口往右邊移動 5 個字節，因為有 5 個字節的數據被應答確認，接下來第 52~56 字節又變成了可用窗口，那么后續也就可以發送 52~56 這 5 個字節的數據了。

但是如果某個數據報文丟失或者其對應的 ACK 報文在網絡中丟失，會導致發送方無法移動發送窗口，這時就無法再發送新的數據，只能超時重傳這個數據報文，直到收到這個重傳報文的 ACK，發送窗口才會移動，繼續后面的發送行為。

舉個例子，比如下圖，客戶端是發送方，服務器是接收方。

客戶端發送了第 5～9 字節的數據，但是第 5 字節的 ACK 確認報文在網絡中丟失了，那么即使客戶端收到第 6～9 字節的 ACK 確認報文，發送窗口也不會往前移動。

此時的第 5 字節相當于“隊頭”，因為沒有收到“隊頭”的 ACK 確認報文，導致發送窗口無法往前移動，此時發送方就無法繼續發送后面的數據，相當于按下了發送行為的暫停鍵，這就是發送窗口的隊頭阻塞問題。

再來說說接收窗口的隊頭阻塞。

接收方收到的數據范圍必須在接收窗口范圍內，如果收到超過接收窗口范圍的數據，就會丟棄該數據，比如下圖接收窗口的范圍是 32 ～ 51 字節，如果收到第 52 字節以上數據都會被丟棄。

接收窗口什么時候才能滑動？當接收窗口收到有序數據時，接收窗口才能往前滑動，然后那些已經接收并且被確認的「有序」數據就可以被應用層讀取。

但是，當接收窗口收到的數據不是有序的，比如收到第 33～40 字節的數據，由于第 32 字節數據沒有收到， 接收窗口無法向前滑動，那么即使先收到第 33～40 字節的數據，這些數據也無法被應用層讀取的。只有當發送方重傳了第 32 字節數據并且被接收方收到后，接收窗口才會往前滑動，然后應用層才能從內核讀取第 32～40 字節的數據。

好了，至此發送窗口和接收窗口的隊頭阻塞問題都說完了，這兩個問題的原因都是因為 TCP 必須按序處理數據，也就是 TCP 層為了保證數據的有序性，只有在處理完有序的數據后，滑動窗口才能往前滑動，否則就停留。

• 停留「發送窗口」會使得發送方無法繼續發送數據。

• 停留「接收窗口」會使得應用層無法讀取新的數據。

其實也不能怪 TCP 協議，它本來設計目的就是為了保證數據的有序性。

HTTP/2 的隊頭阻塞

HTTP/2 通過抽象出 Stream 的概念，實現了 HTTP 并發傳輸，一個 Stream 就代表 HTTP/1.1 里的請求和響應。

在 HTTP/2 連接上，不同 Stream 的幀是可以亂序發送的（因此可以并發不同的 Stream ），因為每個幀的頭部會攜帶 Stream ID 信息，所以接收端可以通過 Stream ID 有序組裝成 HTTP 消息，而同一 Stream 內部的幀必須是嚴格有序的。

但是 HTTP/2 多個 Stream 請求都是在一條 TCP 連接上傳輸，這意味著多個 Stream 共用同一個 TCP 滑動窗口，那么當發生數據丟失，滑動窗口是無法往前移動的，此時就會阻塞住所有的 HTTP 請求，這屬于 TCP 層隊頭阻塞。

沒有隊頭阻塞的 QUIC

QUIC 也借鑒 HTTP/2 里的 Stream 的概念，在一條 QUIC 連接上可以并發發送多個 HTTP 請求 (Stream)。

但是 QUIC 給每一個 Stream 都分配了一個獨立的滑動窗口，這樣使得一個連接上的多個 Stream 之間沒有依賴關系，都是相互獨立的，各自控制的滑動窗口。

假如 Stream2 丟了一個 UDP 包，也只會影響 Stream2 的處理，不會影響其他 Stream，與 HTTP/2 不同，HTTP/2 只要某個流中的數據包丟失了，其他流也會因此受影響。

QUIC 是如何做流量控制的？

TCP 流量控制是通過讓「接收方」告訴「發送方」，它（接收方）的接收窗口有多大，從而讓「發送方」根據「接收方」的實際接收能力控制發送的數據量。

在前面說到，TCP 的接收窗口在收到有序的數據后，接收窗口才能往前滑動，否則停止滑動；TCP 的發送窗口在收到對已發送數據的順序確認 ACK后，發送窗口才能往前滑動，否則停止滑動。

QUIC 是基于 UDP 傳輸的，而 UDP 沒有流量控制，因此 QUIC 實現了自己的流量控制機制。不過，QUIC 的滑動窗口滑動的條件跟 TCP 有所差別的。

QUIC 實現了兩種級別的流量控制，分別為 Stream 和 Connection 兩種級別：

• Stream 級別的流量控制：每個 Stream 都有獨立的滑動窗口，所以每個 Stream 都可以做流量控制，防止單個 Stream 消耗連接（Connection）的全部接收緩沖。
• Connection 流量控制：限制連接中所有 Stream 相加起來的總字節數，防止發送方超過連接的緩沖容量。

Stream 級別的流量控制

回想一下 TCP，當發送方發送 seq1、seq2、seq3 報文，由于 seq2 報文丟失了，接收方收到 seq1 后會 ack1，然后接收方收到 seq3 后還是回 ack1（因為沒有收到 seq2），這時發送窗口無法往前滑動。

但是，QUIC 就不一樣了，即使中途有報文丟失，發送窗口依然可以往前滑動，具體怎么做到的呢？我們來看看。

最開始，接收方的接收窗口初始狀態如下：

接著，接收方收到了發送方發送過來的數據，有的數據被上層讀取了，有的數據丟包了，此時的接收窗口狀況如下：

可以看到，接收窗口的左邊界取決于接收到的最大偏移字節數，此時的接收窗口 = 最大窗口數 - 接收到的最大偏移數，這里就跟 TCP 不一樣了。

那接收窗口觸發的滑動條件是什么呢？看下圖：

當圖中的綠色部分數據超過最大接收窗口的一半后，最大接收窗口向右移動，同時給對端發送「窗口更新幀」。當發送方收到接收方的窗口更新幀后，發送窗口也會往前滑動，即使中途有丟包，依然也會滑動，這樣就防止像 TCP 那樣在出現丟包的時候，導致發送窗口無法移動，從而避免了無法繼續發送數據。

在前面我們說過，每個 Stream 都有各自的滑動窗口，不同 Stream 互相獨立，隊頭的 Stream A 被阻塞后，不妨礙 StreamB、C的讀取。而對于 TCP 而言，其不知道將不同的 Stream 交給上層哪一個請求，因此同一個Connection內，Stream A 被阻塞后，StreamB、C 必須等待。

經過了解完 QUIC 的流量控制機制后，對于隊頭阻塞問題解決得更加徹底。

QUIC 協議中同一個 Stream 內，滑動窗口的移動僅取決于接收到的最大字節偏移（盡管期間可能有部分數據未被接收），而對于 TCP 而言，窗口滑動必須保證此前的 packet 都有序的接收到了，其中一個 packet 丟失就會導致窗口等待。

Connection 流量控制

而對于 Connection 級別的流量窗口，其接收窗口大小就是各個 Stream 接收窗口大小之和。

上圖所示的例子，所有 Streams 的最大窗口數為 120，其中：

• Stream 1 的最大接收偏移為 100，可用窗口 = 120 - 100 = 20
• Stream 2 的最大接收偏移為 90，可用窗口 = 120 - 90 = 30
• Stream 3 的最大接收偏移為 110，可用窗口 = 120 - 110 = 10

那么整個 Connection 的可用窗口 = 20 + 30 + 10 = 60

可用窗口 = Stream 1 可用窗口 + Stream 2 可用窗口 + Stream 3 可用窗口

QUIC 對擁塞控制改進

QUIC 協議當前默認使用了 TCP 的 Cubic 擁塞控制算法（我們熟知的慢開始、擁塞避免、快重傳、快恢復策略），同時也支持 CubicBytes、Reno、RenoBytes、BBR、PCC 等擁塞控制算法，相當于將 TCP 的擁塞控制算法照搬過來了，QUIC 是如何改進 TCP 的擁塞控制算法的呢？

QUIC 是處于應用層的，應用程序層面就能實現不同的擁塞控制算法，不需要操作系統，不需要內核支持。這是一個飛躍，因為傳統的 TCP 擁塞控制，必須要端到端的網絡協議棧支持，才能實現控制效果。而內核和操作系統的部署成本非常高，升級周期很長，所以 TCP 擁塞控制算法迭代速度是很慢的。而 QUIC 可以隨瀏覽器更新，QUIC 的擁塞控制算法就可以有較快的迭代速度。

TCP 更改擁塞控制算法是對系統中所有應用都生效，無法根據不同應用設定不同的擁塞控制策略。但是因為 QUIC 處于應用層，所以就可以針對不同的應用設置不同的擁塞控制算法，這樣靈活性就很高了。

QUIC 更快的連接建立

對于 HTTP/1 和 HTTP/2 協議，TCP 和 TLS 是分層的，分別屬于內核實現的傳輸層、openssl 庫實現的表示層，因此它們難以合并在一起，需要分批次來握手，先 TCP 握手（1RTT），再 TLS 握手（2RTT），所以需要 3RTT 的延遲才能傳輸數據，就算 Session 會話服用，也需要至少 2 個 RTT。

HTTP/3 在傳輸數據前雖然需要 QUIC 協議握手，這個握手過程只需要 1 RTT，握手的目的是為確認雙方的「連接 ID」，連接遷移就是基于連接 ID 實現的。

但是 HTTP/3 的 QUIC 協議并不是與 TLS 分層，而是QUIC 內部包含了 TLS，它在自己的幀會攜帶 TLS 里的“記錄”，再加上 QUIC 使用的是 TLS1.3，因此僅需 1 個 RTT 就可以「同時」完成建立連接與密鑰協商，甚至在第二次連接的時候，應用數據包可以和 QUIC 握手信息（連接信息 + TLS 信息）一起發送，達到 0-RTT 的效果。

如下圖右邊部分，HTTP/3 當會話恢復時，有效負載數據與第一個數據包一起發送，可以做到 0-RTT：

QUIC 是如何遷移連接的？

基于 TCP 傳輸協議的 HTTP 協議，由于是通過四元組（源 IP、源端口、目的 IP、目的端口）確定一條 TCP 連接。

那么當移動設備的網絡從 4G 切換到 WIFI 時，意味著 IP 地址變化了，那么就必須要斷開連接，然后重新建立 TCP 連接。

而建立連接的過程包含 TCP 三次握手和 TLS 四次握手的時延，以及 TCP 慢啟動的減速過程，給用戶的感覺就是網絡突然卡頓了一下，因此連接的遷移成本是很高的。

QUIC 協議沒有用四元組的方式來“綁定”連接，而是通過連接 ID來標記通信的兩個端點，客戶端和服務器可以各自選擇一組 ID 來標記自己，因此即使移動設備的網絡變化后，導致 IP 地址變化了，只要仍保有上下文信息（比如連接 ID、TLS 密鑰等），就可以“無縫”地復用原連接，消除重連的成本，沒有絲毫卡頓感，達到了連接遷移的功能。