【面試】字節(jié)一面：如何用 UDP 實(shí)現(xiàn)可靠傳輸？

作者：小林coding

圖解網(wǎng)站：https://xiaolincoding.com/

大家好，我是小林。

我記得之前在群里看到，有位讀者字節(jié)一面的時(shí)候被問到：「如何基于 UDP 協(xié)議實(shí)現(xiàn)可靠傳輸？」

很多同學(xué)第一反應(yīng)就會(huì)說把 TCP 可靠傳輸?shù)奶匦裕ㄐ蛄刑?hào)、確認(rèn)應(yīng)答、超時(shí)重傳、流量控制、擁塞控制）在應(yīng)用層實(shí)現(xiàn)一遍。

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

所以，我們要先弄清楚 TCP 協(xié)議有哪些痛點(diǎn)？而這些痛點(diǎn)是否可以在基于 UDP 協(xié)議實(shí)現(xiàn)的可靠傳輸協(xié)議中得到改進(jìn)？

在之前這篇文章：TCP 就沒什么缺陷嗎？，我已經(jīng)說了 TCP 協(xié)議四個(gè)方面的缺陷：

• 升級(jí) TCP 的工作很困難；
• TCP 建立連接的延遲；
• TCP 存在隊(duì)頭阻塞問題；
• 網(wǎng)絡(luò)遷移需要重新建立 TCP 連接；

現(xiàn)在市面上已經(jīng)有基于 UDP 協(xié)議實(shí)現(xiàn)的可靠傳輸協(xié)議的成熟方案了，那就是 QUIC 協(xié)議，已經(jīng)應(yīng)用在了 HTTP/3。

這次，聊聊 QUIC 是如何實(shí)現(xiàn)可靠傳輸?shù)?？又是如何解決上面 TCP 協(xié)議四個(gè)方面的缺陷？

QUIC 是如何實(shí)現(xiàn)可靠傳輸?shù)模?/h2>

要基于 UDP 實(shí)現(xiàn)的可靠傳輸協(xié)議，那么就要在應(yīng)用層下功夫，也就是要設(shè)計(jì)好協(xié)議的頭部字段。

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

 

整體看的視角是這樣的：

接下來，分別對(duì)每一個(gè) Header 做個(gè)介紹。

Packet Header

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

Packet Header

細(xì)分這兩種：

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

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

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

Short Packet Header 中的 Packet Number 是每個(gè)報(bào)文獨(dú)一無二的編號(hào)，它是嚴(yán)格遞增的，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N，而是一個(gè)比 N 大的值。

為什么要這么設(shè)計(jì)呢？

我們先來看看  TCP 的問題，TCP 在重傳報(bào)文時(shí)的序列號(hào)和原始報(bào)文的序列號(hào)是一樣的，也正是由于這個(gè)特性，引入了 TCP 重傳的歧義問題。

TCP 重傳的歧義問題

比如上圖，當(dāng) TCP 發(fā)生超時(shí)重傳后，客戶端發(fā)起重傳，然后接收到了服務(wù)端確認(rèn) ACK 。由于客戶端原始報(bào)文和重傳報(bào)文序列號(hào)都是一樣的，那么服務(wù)端針對(duì)這兩個(gè)報(bào)文回復(fù)的都是相同的 ACK。

這樣的話，客戶端就無法判斷出是原始報(bào)文的響應(yīng)還是重傳報(bào)文的響應(yīng)，這樣在計(jì)算 RTT（往返時(shí)間） 時(shí)應(yīng)該選擇從發(fā)送原始報(bào)文開始計(jì)算，還是重傳原始報(bào)文開始計(jì)算呢？

• 如果算成原始報(bào)文的響應(yīng)，但實(shí)際上是重傳報(bào)文的響應(yīng)（上圖右），會(huì)導(dǎo)致采樣 RTT 變大；
• 如果算成重傳報(bào)文的響應(yīng)，但實(shí)際上是原始報(bào)文的響應(yīng)（上圖左），又很容易導(dǎo)致采樣 RTT 過??；

RTT 計(jì)算不精確的話，那么 RTO （超時(shí)時(shí)間）也就不精確，因?yàn)?RTO 是基于 RTT 來計(jì)算的，RTO 計(jì)算不準(zhǔn)確可能導(dǎo)致重傳的概率事件增大。

QUIC 報(bào)文中的 Pakcet Number 是嚴(yán)格遞增的， 即使是重傳報(bào)文，它的 Pakcet Number 也是遞增的，這樣就能更加精確計(jì)算出報(bào)文的 RTT。

如果 ACK 的 Packet Number 是 N+M，就根據(jù)重傳報(bào)文計(jì)算采樣 RTT。如果 ACK 的 Pakcet Number 是 N，就根據(jù)原始報(bào)文的時(shí)間計(jì)算采樣 RTT，沒有歧義性的問題。

另外，還有一個(gè)好處，QUIC 使用的 Packet Number 單調(diào)遞增的設(shè)計(jì)，可以讓數(shù)據(jù)包不再像TCP 那樣必須有序確認(rèn)，QUIC 支持亂序確認(rèn)，當(dāng)數(shù)據(jù)包Packet N 丟失后，只要有新的已接收數(shù)據(jù)包確認(rèn)，當(dāng)前窗口就會(huì)繼續(xù)向右滑動(dòng)。

待發(fā)送端超過一定時(shí)間沒收到 Packet N 的確認(rèn)報(bào)文后，會(huì)將需要重傳的數(shù)據(jù)包放到待發(fā)送隊(duì)列，重新編號(hào)比如數(shù)據(jù)包 Packet N+M 后重新發(fā)送給接收端，對(duì)重傳數(shù)據(jù)包的處理跟發(fā)送新的數(shù)據(jù)包類似，這樣就不會(huì)因?yàn)閬G包重傳將當(dāng)前窗口阻塞在原地，從而解決了隊(duì)頭阻塞問題。

所以，Packet Number 單調(diào)遞增的兩個(gè)好處：

• 可以更加精確計(jì)算 RTT，沒有 TCP 重傳的歧義性問題；
• 可以支持亂序確認(rèn)，防止因?yàn)閬G包重傳將當(dāng)前窗口阻塞在原地，而 TCP 必須是順序確認(rèn)的，丟包時(shí)會(huì)導(dǎo)致窗口不滑動(dòng)；

QUIC Frame Header

一個(gè) Packet 報(bào)文中可以存放多個(gè) QUIC Frame。

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

• Stream ID 作用：多個(gè)并發(fā)傳輸?shù)?HTTP 消息，通過不同的 Stream ID 加以區(qū)別；Offset 作用：類似于 TCP 協(xié)議中的 Seq 序號(hào)，保證數(shù)據(jù)的順序性和可靠性；Length 作用：指明了 Frame 數(shù)據(jù)的長度。

在前面介紹 Packet Header 時(shí)，說到 Packet Number 是嚴(yán)格遞增，即使重傳報(bào)文的 Packet Number 也是遞增的，既然重傳數(shù)據(jù)包的 Packet N+M 與丟失數(shù)據(jù)包的 Packet N 編號(hào)并不一致，我們?cè)趺创_定這兩個(gè)數(shù)據(jù)包的內(nèi)容一樣呢？

所以引入 Frame Header 這一層，通過 Stream ID + Offset 字段信息實(shí)現(xiàn)數(shù)據(jù)的有序性，通過比較兩個(gè)數(shù)據(jù)包的 Stream ID 與 Stream Offset ，如果都是一致，就說明這兩個(gè)數(shù)據(jù)包的內(nèi)容一致。

舉個(gè)例子，下圖中，數(shù)據(jù)包 Packet N 丟失了，后面重傳該數(shù)據(jù)包的編號(hào)為 Packet N+2，丟失的數(shù)據(jù)包和重傳的數(shù)據(jù)包 Stream ID 與 Offset 都一致，說明這兩個(gè)數(shù)據(jù)包的內(nèi)容一致。這些數(shù)據(jù)包傳輸?shù)浇邮斩撕螅邮斩四芨鶕?jù) Stream ID 與 Offset 字段信息將  Stream x 和 Stream x+y 按照順序組織起來，然后交給應(yīng)用程序處理。

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

QUIC 是如何解決 TCP 隊(duì)頭阻塞問題的？

什么是 TCP 隊(duì)頭阻塞問題？

TCP 隊(duì)頭阻塞的問題要從兩個(gè)角度看，一個(gè)是發(fā)送窗口的隊(duì)頭阻塞，另外一個(gè)是接收窗口的隊(duì)頭阻塞。

先來說說發(fā)送窗口的隊(duì)頭阻塞。

TCP 發(fā)送出去的數(shù)據(jù)，都是需要按序確認(rèn)的，只有在數(shù)據(jù)都被按順序確認(rèn)完后，發(fā)送窗口才會(huì)往前滑動(dòng)。

舉個(gè)例子，比如下圖的發(fā)送方把發(fā)送窗口內(nèi)的數(shù)據(jù)全部都發(fā)出去了，可用窗口的大小就為 0 了，表明可用窗口耗盡，在沒收到 ACK 確認(rèn)之前是無法繼續(xù)發(fā)送數(shù)據(jù)了。

可用窗口耗盡

接著，當(dāng)發(fā)送方收到對(duì)第 32~36 字節(jié)的 ACK 確認(rèn)應(yīng)答后，則滑動(dòng)窗口往右邊移動(dòng) 5 個(gè)字節(jié)，因?yàn)橛?5 個(gè)字節(jié)的數(shù)據(jù)被應(yīng)答確認(rèn)，接下來第 52~56 字節(jié)又變成了可用窗口，那么后續(xù)也就可以發(fā)送 52~56 這 5 個(gè)字節(jié)的數(shù)據(jù)了。

32 ~ 36 字節(jié)已確認(rèn)

但是如果某個(gè)數(shù)據(jù)報(bào)文丟失或者其對(duì)應(yīng)的 ACK 報(bào)文在網(wǎng)絡(luò)中丟失，會(huì)導(dǎo)致發(fā)送方無法移動(dòng)發(fā)送窗口，這時(shí)就無法再發(fā)送新的數(shù)據(jù)，只能超時(shí)重傳這個(gè)數(shù)據(jù)報(bào)文，直到收到這個(gè)重傳報(bào)文的 ACK，發(fā)送窗口才會(huì)移動(dòng)，繼續(xù)后面的發(fā)送行為。

舉個(gè)例子，比如下圖，客戶端是發(fā)送方，服務(wù)器是接收方。

客戶端發(fā)送了第 5～9 字節(jié)的數(shù)據(jù)，但是第 5 字節(jié)的 ACK 確認(rèn)報(bào)文在網(wǎng)絡(luò)中丟失了，那么即使客戶端收到第 6～9 字節(jié)的 ACK 確認(rèn)報(bào)文，發(fā)送窗口也不會(huì)往前移動(dòng)。

此時(shí)的第 5 字節(jié)相當(dāng)于“隊(duì)頭”，因?yàn)闆]有收到“隊(duì)頭”的 ACK 確認(rèn)報(bào)文，導(dǎo)致發(fā)送窗口無法往前移動(dòng)，此時(shí)發(fā)送方就無法繼續(xù)發(fā)送后面的數(shù)據(jù)，相當(dāng)于按下了發(fā)送行為的暫停鍵，這就是發(fā)送窗口的隊(duì)頭阻塞問題。

再來說說接收窗口的隊(duì)頭阻塞。

接收方收到的數(shù)據(jù)范圍必須在接收窗口范圍內(nèi)，如果收到超過接收窗口范圍的數(shù)據(jù)，就會(huì)丟棄該數(shù)據(jù)，比如下圖接收窗口的范圍是 32 ～ 51 字節(jié)，如果收到第 52 字節(jié)以上數(shù)據(jù)都會(huì)被丟棄。

接收窗口

接收窗口什么時(shí)候才能滑動(dòng)？當(dāng)接收窗口收到有序數(shù)據(jù)時(shí)，接收窗口才能往前滑動(dòng)，然后那些已經(jīng)接收并且被確認(rèn)的「有序」數(shù)據(jù)就可以被應(yīng)用層讀取。

但是，當(dāng)接收窗口收到的數(shù)據(jù)不是有序的，比如收到第 33～40 字節(jié)的數(shù)據(jù)，由于第 32 字節(jié)數(shù)據(jù)沒有收到， 接收窗口無法向前滑動(dòng)，那么即使先收到第 33～40 字節(jié)的數(shù)據(jù)，這些數(shù)據(jù)也無法被應(yīng)用層讀取的。只有當(dāng)發(fā)送方重傳了第 32 字節(jié)數(shù)據(jù)并且被接收方收到后，接收窗口才會(huì)往前滑動(dòng)，然后應(yīng)用層才能從內(nèi)核讀取第 32～40 字節(jié)的數(shù)據(jù)。

好了，至此發(fā)送窗口和接收窗口的隊(duì)頭阻塞問題都說完了，這兩個(gè)問題的原因都是因?yàn)?TCP 必須按序處理數(shù)據(jù)，也就是 TCP 層為了保證數(shù)據(jù)的有序性，只有在處理完有序的數(shù)據(jù)后，滑動(dòng)窗口才能往前滑動(dòng)，否則就停留。

停留「發(fā)送窗口」會(huì)使得發(fā)送方無法繼續(xù)發(fā)送數(shù)據(jù)。

停留「接收窗口」會(huì)使得應(yīng)用層無法讀取新的數(shù)據(jù)。

其實(shí)也不能怪 TCP 協(xié)議，它本來設(shè)計(jì)目的就是為了保證數(shù)據(jù)的有序性。

HTTP/2  的隊(duì)頭阻塞

HTTP/2 通過抽象出 Stream 的概念，實(shí)現(xiàn)了 HTTP 并發(fā)傳輸，一個(gè) Stream 就代表 HTTP/1.1 里的請(qǐng)求和響應(yīng)。

HTTP/2

在 HTTP/2 連接上，不同 Stream 的幀是可以亂序發(fā)送的（因此可以并發(fā)不同的 Stream ），因?yàn)槊總€(gè)幀的頭部會(huì)攜帶 Stream ID 信息，所以接收端可以通過 Stream ID 有序組裝成 HTTP 消息，而同一 Stream 內(nèi)部的幀必須是嚴(yán)格有序的。

但是 HTTP/2 多個(gè) Stream 請(qǐng)求都是在一條 TCP 連接上傳輸，這意味著多個(gè) Stream 共用同一個(gè) TCP 滑動(dòng)窗口，那么當(dāng)發(fā)生數(shù)據(jù)丟失，滑動(dòng)窗口是無法往前移動(dòng)的，此時(shí)就會(huì)阻塞住所有的 HTTP 請(qǐng)求，這屬于 TCP 層隊(duì)頭阻塞。

沒有隊(duì)頭阻塞的 QUIC

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

但是 QUIC 給每一個(gè) Stream 都分配了一個(gè)獨(dú)立的滑動(dòng)窗口，這樣使得一個(gè)連接上的多個(gè) Stream 之間沒有依賴關(guān)系，都是相互獨(dú)立的，各自控制的滑動(dòng)窗口。

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

QUIC 是如何做流量控制的？

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

在前面說到，TCP 的接收窗口在收到有序的數(shù)據(jù)后，接收窗口才能往前滑動(dòng)，否則停止滑動(dòng)；TCP 的發(fā)送窗口在收到對(duì)已發(fā)送數(shù)據(jù)的順序確認(rèn) ACK后，發(fā)送窗口才能往前滑動(dòng)，否則停止滑動(dòng)。

QUIC 是基于 UDP 傳輸?shù)?，?UDP 沒有流量控制，因此 QUIC 實(shí)現(xiàn)了自己的流量控制機(jī)制。不過，QUIC 的滑動(dòng)窗口滑動(dòng)的條件跟 TCP 有所差別的。

QUIC 實(shí)現(xiàn)了兩種級(jí)別的流量控制，分別為 Stream 和 Connection 兩種級(jí)別：

• Stream 級(jí)別的流量控制：每個(gè) Stream 都有獨(dú)立的滑動(dòng)窗口，所以每個(gè) Stream 都可以做流量控制，防止單個(gè) Stream 消耗連接（Connection）的全部接收緩沖。

• Connection 流量控制：限制連接中所有 Stream 相加起來的總字節(jié)數(shù)，防止發(fā)送方超過連接的緩沖容量。

Stream 級(jí)別的流量控制

回想一下 TCP，當(dāng)發(fā)送方發(fā)送 seq1、seq2、seq3 報(bào)文，由于 seq2 報(bào)文丟失了，接收方收到 seq1 后會(huì) ack1，然后接收方收到 seq3 后還是回 ack1（因?yàn)闆]有收到 seq2），這時(shí)發(fā)送窗口無法往前滑動(dòng)。

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

最開始，接收方的接收窗口初始狀態(tài)如下：

接著，接收方收到了發(fā)送方發(fā)送過來的數(shù)據(jù)，有的數(shù)據(jù)被上層讀取了，有的數(shù)據(jù)丟包了，此時(shí)的接收窗口狀況如下：

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

那接收窗口觸發(fā)的滑動(dòng)條件是什么呢？看下圖：

接收窗口觸發(fā)的滑動(dòng)

當(dāng)圖中的綠色部分?jǐn)?shù)據(jù)超過最大接收窗口的一半后，最大接收窗口向右移動(dòng)，同時(shí)給對(duì)端發(fā)送「窗口更新幀」。當(dāng)發(fā)送方收到接收方的窗口更新幀后，發(fā)送窗口也會(huì)往前滑動(dòng)，即使中途有丟包，依然也會(huì)滑動(dòng)，這樣就防止像 TCP 那樣在出現(xiàn)丟包的時(shí)候，導(dǎo)致發(fā)送窗口無法移動(dòng)，從而避免了無法繼續(xù)發(fā)送數(shù)據(jù)。

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

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

QUIC 協(xié)議中同一個(gè) Stream 內(nèi)，滑動(dòng)窗口的移動(dòng)僅取決于接收到的最大字節(jié)偏移（盡管期間可能有部分?jǐn)?shù)據(jù)未被接收），而對(duì)于 TCP 而言，窗口滑動(dòng)必須保證此前的 packet 都有序的接收到了，其中一個(gè) packet 丟失就會(huì)導(dǎo)致窗口等待。

Connection 流量控制

而對(duì)于 Connection 級(jí)別的流量窗口，其接收窗口大小就是各個(gè) Stream 接收窗口大小之和。

Connection 流量控制

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

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

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

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

QUIC 對(duì)擁塞控制改進(jìn)

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

QUIC 是處于應(yīng)用層的，應(yīng)用程序?qū)用婢湍軐?shí)現(xiàn)不同的擁塞控制算法，不需要操作系統(tǒng)，不需要內(nèi)核支持。這是一個(gè)飛躍，因?yàn)閭鹘y(tǒng)的 TCP 擁塞控制，必須要端到端的網(wǎng)絡(luò)協(xié)議棧支持，才能實(shí)現(xiàn)控制效果。而內(nèi)核和操作系統(tǒng)的部署成本非常高，升級(jí)周期很長，所以 TCP 擁塞控制算法迭代速度是很慢的。而 QUIC 可以隨瀏覽器更新，QUIC 的擁塞控制算法就可以有較快的迭代速度。

TCP 更改擁塞控制算法是對(duì)系統(tǒng)中所有應(yīng)用都生效，無法根據(jù)不同應(yīng)用設(shè)定不同的擁塞控制策略。但是因?yàn)?QUIC 處于應(yīng)用層，所以就可以針對(duì)不同的應(yīng)用設(shè)置不同的擁塞控制算法，這樣靈活性就很高了。

QUIC 更快的連接建立

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

HTTP/3 在傳輸數(shù)據(jù)前雖然需要 QUIC 協(xié)議握手，這個(gè)握手過程只需要 1 RTT，握手的目的是為確認(rèn)雙方的「連接 ID」，連接遷移就是基于連接 ID 實(shí)現(xiàn)的。

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

如下圖右邊部分，HTTP/3 當(dāng)會(huì)話恢復(fù)時(shí)，有效負(fù)載數(shù)據(jù)與第一個(gè)數(shù)據(jù)包一起發(fā)送，可以做到 0-RTT：

QUIC 是如何遷移連接的？

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

那么當(dāng)移動(dòng)設(shè)備的網(wǎng)絡(luò)從 4G 切換到 WIFI 時(shí)，意味著 IP 地址變化了，那么就必須要斷開連接，然后重新建立 TCP 連接。

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

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

參考資料：

• https://www.taohui.tech/2021/02/04/%E7%BD%91%E7%BB%9C%E5%8D%8F%E8%AE%AE/%E6%B7%B1%E5%85%A5%E5%89%96%E6%9E%90HTTP3%E5%8D%8F%E8%AE%AE/https://zhuanlan.zhihu.com/p/32553477