作者介紹：lancelot，騰訊資深研發(fā)工程師。目前主要負(fù)責(zé)騰訊 stgw(騰訊安全云網(wǎng)關(guān)）的相關(guān)工作，整體推進(jìn)騰訊內(nèi)部及騰訊公有云，混合云的七層負(fù)載均衡及全站 HTTPS 接入。對(duì) HTTPS，SPDY，HTTP2，QUIC 等應(yīng)用層協(xié)議、高性能服務(wù)器技術(shù)、云網(wǎng)絡(luò)技術(shù)、用戶訪問(wèn)速度、分布式文件傳輸?shù)扔休^深的理解。

本文系由“騰訊技術(shù)工程官方號(hào)”公眾號(hào)與“InfoQ”公眾號(hào)合辦的“騰訊技術(shù)工程”專欄第二篇文章（第一篇回顧：QQ相冊(cè)后臺(tái)存儲(chǔ)架構(gòu)重構(gòu)與跨IDC容災(zāi)實(shí)踐），新的一年，騰訊技術(shù)工程專欄將為大家提供更多的騰訊技術(shù)干貨與落地實(shí)踐。同時(shí)，該專欄歡迎TEGer投遞優(yōu)質(zhì)稿件，投稿請(qǐng)聯(lián)系RTX（alvisshao）。

本文將主要介紹 QUIC 協(xié)議產(chǎn)生的背景和核心特性。

寫(xiě)在前面

?如果你的 App，在不需要任何修改的情況下就能提升 15% 以上的訪問(wèn)速度。特別是弱網(wǎng)絡(luò)的時(shí)候能夠提升 20% 以上的訪問(wèn)速度。

如果你的 App，在頻繁切換 4G 和 WIFI 網(wǎng)絡(luò)的情況下，不會(huì)斷線，不需要重連，用戶無(wú)任何感知。如果你的 App，既需要 TLS 的安全，也想實(shí)現(xiàn) HTTP2 多路復(fù)用的強(qiáng)大。

如果你剛剛才聽(tīng)說(shuō) HTTP2 是下一代互聯(lián)網(wǎng)協(xié)議，如果你剛剛才關(guān)注到 TLS1.3 是一個(gè)革命性具有里程碑意義的協(xié)議，但是這兩個(gè)協(xié)議卻一直在被另一個(gè)更新興的協(xié)議所影響和挑戰(zhàn)。

如果這個(gè)新興的協(xié)議，它的名字就叫做“快”，并且正在標(biāo)準(zhǔn)化為新一代的互聯(lián)網(wǎng)傳輸協(xié)議。

你愿意花一點(diǎn)點(diǎn)時(shí)間了解這個(gè)協(xié)議嗎？你愿意投入精力去研究這個(gè)協(xié)議嗎？你愿意全力推動(dòng)業(yè)務(wù)來(lái)使用這個(gè)協(xié)議嗎？

QUIC 概述

?Quic 全稱 quick udp internet connection [1]，“快速 UDP 互聯(lián)網(wǎng)連接”，（和英文 quick 諧音，簡(jiǎn)稱“快”）是由 google 提出的使用 udp 進(jìn)行多路并發(fā)傳輸?shù)膮f(xié)議。

Quic 相比現(xiàn)在廣泛應(yīng)用的 http2+tcp+tls 協(xié)議有如下優(yōu)勢(shì) [2]：

減少了 TCP 三次握手及 TLS 握手時(shí)間。

改進(jìn)的擁塞控制。

避免隊(duì)頭阻塞的多路復(fù)用。

連接遷移。

前向冗余糾錯(cuò)。

為什么需要 QUIC

?從上個(gè)世紀(jì) 90 年代互聯(lián)網(wǎng)開(kāi)始興起一直到現(xiàn)在，大部分的互聯(lián)網(wǎng)流量傳輸只使用了幾個(gè)網(wǎng)絡(luò)協(xié)議。使用 IPv4 進(jìn)行路由，使用 TCP 進(jìn)行連接層面的流量控制，使用 SSL/TLS 協(xié)議實(shí)現(xiàn)傳輸安全，使用 DNS 進(jìn)行域名解析，使用 HTTP 進(jìn)行應(yīng)用數(shù)據(jù)的傳輸。

而且近三十年來(lái)，這幾個(gè)協(xié)議的發(fā)展都非常緩慢。TCP 主要是擁塞控制算法的改進(jìn)，SSL/TLS 基本上停留在原地，幾個(gè)小版本的改動(dòng)主要是密碼套件的升級(jí)，TLS1.3[3] 是一個(gè)飛躍式的變化，但截止到今天，還沒(méi)有正式發(fā)布。IPv4 雖然有一個(gè)大的進(jìn)步，實(shí)現(xiàn)了 IPv6，DNS 也增加了一個(gè)安全的 DNSSEC，但和 IPv6 一樣，部署進(jìn)度較慢。

隨著移動(dòng)互聯(lián)網(wǎng)快速發(fā)展以及物聯(lián)網(wǎng)的逐步興起，網(wǎng)絡(luò)交互的場(chǎng)景越來(lái)越豐富，網(wǎng)絡(luò)傳輸?shù)膬?nèi)容也越來(lái)越龐大，用戶對(duì)網(wǎng)絡(luò)傳輸效率和 WEB 響應(yīng)速度的要求也越來(lái)越高。

一方面是歷史悠久使用廣泛的古老協(xié)議，另外一方面用戶的使用場(chǎng)景對(duì)傳輸性能的要求又越來(lái)越高。如下幾個(gè)由來(lái)已久的問(wèn)題和矛盾就變得越來(lái)越突出。

協(xié)議歷史悠久導(dǎo)致中間設(shè)備僵化。

依賴于操作系統(tǒng)的實(shí)現(xiàn)導(dǎo)致協(xié)議本身僵化。

建立連接的握手延遲大。

隊(duì)頭阻塞。

這里分小節(jié)簡(jiǎn)單說(shuō)明一下：

中間設(shè)備的僵化

可能是 TCP 協(xié)議使用得太久，也非常可靠。所以我們很多中間設(shè)備，包括防火墻、NAT 網(wǎng)關(guān)，整流器等出現(xiàn)了一些約定俗成的動(dòng)作。

比如有些防火墻只允許通過(guò) 80 和 443，不放通其他端口。NAT 網(wǎng)關(guān)在轉(zhuǎn)換網(wǎng)絡(luò)地址時(shí)重寫(xiě)傳輸層的頭部，有可能導(dǎo)致雙方無(wú)法使用新的傳輸格式。整流器和中間代理有時(shí)候出于安全的需要，會(huì)刪除一些它們不認(rèn)識(shí)的選項(xiàng)字段。

TCP 協(xié)議本來(lái)是支持端口、選項(xiàng)及特性的增加和修改。但是由于 TCP 協(xié)議和知名端口及選項(xiàng)使用的歷史太悠久，中間設(shè)備已經(jīng)依賴于這些潛規(guī)則，所以對(duì)這些內(nèi)容的修改很容易遭到中間環(huán)節(jié)的干擾而失敗。

而這些干擾，也導(dǎo)致很多在 TCP 協(xié)議上的優(yōu)化變得小心謹(jǐn)慎，步履維艱。

依賴于操作系統(tǒng)的實(shí)現(xiàn)導(dǎo)致協(xié)議僵化

TCP 是由操作系統(tǒng)在內(nèi)核西方棧層面實(shí)現(xiàn)的，應(yīng)用程序只能使用，不能直接修改。雖然應(yīng)用程序的更新迭代非常快速和簡(jiǎn)單。但是 TCP 的迭代卻非常緩慢，原因就是操作系統(tǒng)升級(jí)很麻煩。

現(xiàn)在移動(dòng)終端更加流行，但是移動(dòng)端部分用戶的操作系統(tǒng)升級(jí)依然可能滯后數(shù)年時(shí)間。PC 端的系統(tǒng)升級(jí)滯后得更加嚴(yán)重，windows xp 現(xiàn)在還有大量用戶在使用，盡管它已經(jīng)存在快 20 年。

服務(wù)端系統(tǒng)不依賴用戶升級(jí)，但是由于操作系統(tǒng)升級(jí)涉及到底層軟件和運(yùn)行庫(kù)的更新，所以也比較保守和緩慢。

這也就意味著即使 TCP 有比較好的特性更新，也很難快速推廣。比如 TCP Fast Open。它雖然 2013 年就被提出了，但是 Windows 很多系統(tǒng)版本依然不支持它。

建立連接的握手延遲大

不管是 HTTP1.0/1.1 還是 HTTPS，HTTP2，都使用了 TCP 進(jìn)行傳輸。HTTPS 和 HTTP2 還需要使用 TLS 協(xié)議來(lái)進(jìn)行安全傳輸。這就出現(xiàn)了兩個(gè)握手延遲：

1.TCP 三次握手導(dǎo)致的 TCP 連接建立的延遲。

2.TLS 完全握手需要至少 2 個(gè) RTT 才能建立，簡(jiǎn)化握手需要 1 個(gè) RTT 的握手延遲。

對(duì)于很多短連接場(chǎng)景，這樣的握手延遲影響很大，且無(wú)法消除。

隊(duì)頭阻塞

隊(duì)頭阻塞主要是 TCP 協(xié)議的可靠性機(jī)制引入的。TCP 使用序列號(hào)來(lái)標(biāo)識(shí)數(shù)據(jù)的順序，數(shù)據(jù)必須按照順序處理，如果前面的數(shù)據(jù)丟失，后面的數(shù)據(jù)就算到達(dá)了也不會(huì)通知應(yīng)用層來(lái)處理。

另外 TLS 協(xié)議層面也有一個(gè)隊(duì)頭阻塞，因?yàn)?TLS 協(xié)議都是按照 record 來(lái)處理數(shù)據(jù)的，如果一個(gè) record 中丟失了數(shù)據(jù)，也會(huì)導(dǎo)致整個(gè) record 無(wú)法正確處理。

概括來(lái)講，TCP 和 TLS1.2 之前的協(xié)議存在著結(jié)構(gòu)性的問(wèn)題，如果繼續(xù)在現(xiàn)有的 TCP、TLS 協(xié)議之上實(shí)現(xiàn)一個(gè)全新的應(yīng)用層協(xié)議，依賴于操作系統(tǒng)、中間設(shè)備還有用戶的支持。部署成本非常高，阻力非常大。

所以 QUIC 協(xié)議選擇了 UDP，因?yàn)?UDP 本身沒(méi)有連接的概念，不需要三次握手，優(yōu)化了連接建立的握手延遲，同時(shí)在應(yīng)用程序?qū)用鎸?shí)現(xiàn)了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并發(fā)性，只需要用戶端和服務(wù)端的應(yīng)用程序支持 QUIC 協(xié)議，完全避開(kāi)了操作系統(tǒng)和中間設(shè)備的限制。

QUIC 核心特性

連接建立延時(shí)低

0RTT 建連可以說(shuō)是 QUIC 相比 HTTP2 最大的性能優(yōu)勢(shì)。那什么是 0RTT 建連呢？這里面有兩層含義。

傳輸層 0RTT 就能建立連接。

加密層 0RTT 就能建立加密連接。

圖 1 HTTPS 及 QUIC 建連過(guò)程

比如上圖左邊是 HTTPS 的一次完全握手的建連過(guò)程，需要 3 個(gè) RTT。就算是 Session Resumption[14]，也需要至少 2 個(gè) RTT。

而 QUIC 呢？由于建立在 UDP 的基礎(chǔ)上，同時(shí)又實(shí)現(xiàn)了 0RTT 的安全握手，所以在大部分情況下，只需要 0 個(gè) RTT 就能實(shí)現(xiàn)數(shù)據(jù)發(fā)送，在實(shí)現(xiàn)前向加密 [15] 的基礎(chǔ)上，并且 0RTT 的成功率相比 TLS 的 Sesison Ticket[13] 要高很多。

改進(jìn)的擁塞控制

TCP 的擁塞控制實(shí)際上包含了四個(gè)算法：慢啟動(dòng)，擁塞避免，快速重傳，快速恢復(fù) [22]。

QUIC 協(xié)議當(dāng)前默認(rèn)使用了 TCP 協(xié)議的 Cubic 擁塞控制算法 [6]，同時(shí)也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法。

從擁塞算法本身來(lái)看，QUIC 只是按照 TCP 協(xié)議重新實(shí)現(xiàn)了一遍，那么 QUIC 協(xié)議到底改進(jìn)在哪些方面呢？主要有如下幾點(diǎn)：

可插拔

什么叫可插拔呢？就是能夠非常靈活地生效，變更和停止。體現(xiàn)在如下方面：

應(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í)周期很長(zhǎng)，這在產(chǎn)品快速迭代，網(wǎng)絡(luò)爆炸式增長(zhǎng)的今天，顯然有點(diǎn)滿足不了需求。

即使是單個(gè)應(yīng)用程序的不同連接也能支持配置不同的擁塞控制。就算是一臺(tái)服務(wù)器，接入的用戶網(wǎng)絡(luò)環(huán)境也千差萬(wàn)別，結(jié)合大數(shù)據(jù)及人工智能處理，我們能為各個(gè)用戶提供不同的但又更加精準(zhǔn)更加有效的擁塞控制。比如 BBR 適合，Cubic 適合。

應(yīng)用程序不需要停機(jī)和升級(jí)就能實(shí)現(xiàn)擁塞控制的變更，我們?cè)诜?wù)端只需要修改一下配置，reload 一下，完全不需要停止服務(wù)就能實(shí)現(xiàn)擁塞控制的切換。

STGW 在配置層面進(jìn)行了優(yōu)化，我們可以針對(duì)不同業(yè)務(wù)，不同網(wǎng)絡(luò)制式，甚至不同的 RTT，使用不同的擁塞控制算法。

單調(diào)遞增的 Packet Number

TCP 為了保證可靠性，使用了基于字節(jié)序號(hào)的 Sequence Number 及 Ack 來(lái)確認(rèn)消息的有序到達(dá)。

QUIC 同樣是一個(gè)可靠的協(xié)議，它使用 Packet Number 代替了 TCP 的 sequence number，并且每個(gè) Packet Number 都嚴(yán)格遞增，也就是說(shuō)就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N，而是一個(gè)比 N 大的值。而 TCP 呢，重傳 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不變，也正是由于這個(gè)特性，引入了 Tcp 重傳的歧義問(wèn)題。

圖 2 Tcp 重傳歧義性

如上圖所示，超時(shí)事件 RTO 發(fā)生后，客戶端發(fā)起重傳，然后接收到了 Ack 數(shù)據(jù)。由于序列號(hào)一樣，這個(gè) Ack 數(shù)據(jù)到底是原始請(qǐng)求的響應(yīng)還是重傳請(qǐng)求的響應(yīng)呢？不好判斷。

如果算成原始請(qǐng)求的響應(yīng)，但實(shí)際上是重傳請(qǐng)求的響應(yīng)（上圖左），會(huì)導(dǎo)致采樣 RTT 變大。如果算成重傳請(qǐng)求的響應(yīng)，但實(shí)際上是原始請(qǐng)求的響應(yīng)，又很容易導(dǎo)致采樣 RTT 過(guò)小。

由于 Quic 重傳的 Packet 和原始 Packet 的 Pakcet Number 是嚴(yán)格遞增的，所以很容易就解決了這個(gè)問(wèn)題。

圖 3 Quic 重傳沒(méi)有歧義性

如上圖所示，RTO 發(fā)生后，根據(jù)重傳的 Packet Number 就能確定精確的 RTT 計(jì)算。如果 Ack 的 Packet Number 是 N+M，就根據(jù)重傳請(qǐng)求計(jì)算采樣 RTT。如果 Ack 的 Pakcet Number 是 N，就根據(jù)原始請(qǐng)求的時(shí)間計(jì)算采樣 RTT，沒(méi)有歧義性。

但是單純依靠嚴(yán)格遞增的 Packet Number 肯定是無(wú)法保證數(shù)據(jù)的順序性和可靠性。QUIC 又引入了一個(gè) Stream Offset 的概念。

即一個(gè) Stream 可以經(jīng)過(guò)多個(gè) Packet 傳輸，Packet Number 嚴(yán)格遞增，沒(méi)有依賴。但是 Packet 里的 Payload 如果是 Stream 的話，就需要依靠 Stream 的 Offset 來(lái)保證應(yīng)用數(shù)據(jù)的順序。如錯(cuò)誤! 未找到引用源。所示，發(fā)送端先后發(fā)送了 Pakcet N 和 Pakcet N+1，Stream 的 Offset 分別是 x 和 x+y。

假設(shè) Packet N 丟失了，發(fā)起重傳，重傳的 Packet Number 是 N+2，但是它的 Stream 的 Offset 依然是 x，這樣就算 Packet N + 2 是后到的，依然可以將 Stream x 和 Stream x+y 按照順序組織起來(lái)，交給應(yīng)用程序處理。

圖 4 Stream Offset 保證有序性

不允許 Reneging

什么叫 Reneging 呢？就是接收方丟棄已經(jīng)接收并且上報(bào)給 SACK 選項(xiàng)的內(nèi)容 [8]。TCP 協(xié)議不鼓勵(lì)這種行為，但是協(xié)議層面允許這樣的行為。主要是考慮到服務(wù)器資源有限，比如 Buffer 溢出，內(nèi)存不夠等情況。

Reneging 對(duì)數(shù)據(jù)重傳會(huì)產(chǎn)生很大的干擾。因?yàn)?Sack 都已經(jīng)表明接收到了，但是接收端事實(shí)上丟棄了該數(shù)據(jù)。

QUIC 在協(xié)議層面禁止 Reneging，一個(gè) Packet 只要被 Ack，就認(rèn)為它一定被正確接收，減少了這種干擾。

更多的 Ack 塊

TCP 的 Sack 選項(xiàng)能夠告訴發(fā)送方已經(jīng)接收到的連續(xù) Segment 的范圍，方便發(fā)送方進(jìn)行選擇性重傳。

由于 TCP 頭部最大只有 60 個(gè)字節(jié)，標(biāo)準(zhǔn)頭部占用了 20 字節(jié)，所以 Tcp Option 最大長(zhǎng)度只有 40 字節(jié)，再加上 Tcp Timestamp option 占用了 10 個(gè)字節(jié) [25]，所以留給 Sack 選項(xiàng)的只有 30 個(gè)字節(jié)。

每一個(gè) Sack Block 的長(zhǎng)度是 8 個(gè)，加上 Sack Option 頭部 2 個(gè)字節(jié)，也就意味著 Tcp Sack Option 最大只能提供 3 個(gè) Block。

但是 Quic Ack Frame 可以同時(shí)提供 256 個(gè) Ack Block，在丟包率比較高的網(wǎng)絡(luò)下，更多的 Sack Block 可以提升網(wǎng)絡(luò)的恢復(fù)速度，減少重傳量。

Ack Delay 時(shí)間

Tcp 的 Timestamp 選項(xiàng)存在一個(gè)問(wèn)題 [25]，它只是回顯了發(fā)送方的時(shí)間戳，但是沒(méi)有計(jì)算接收端接收到 segment 到發(fā)送 Ack 該 segment 的時(shí)間。這個(gè)時(shí)間可以簡(jiǎn)稱為 Ack Delay。

這樣就會(huì)導(dǎo)致 RTT 計(jì)算誤差。如下圖：

可以認(rèn)為 TCP 的 RTT 計(jì)算：

而 Quic 計(jì)算如下：

當(dāng)然 RTT 的具體計(jì)算沒(méi)有這么簡(jiǎn)單，需要采樣，參考?xì)v史數(shù)值進(jìn)行平滑計(jì)算，參考如下公式 [9]。

基于 stream 和 connecton 級(jí)別的流量控制

?QUIC 的流量控制 [22] 類似 HTTP2，即在 Connection 和 Stream 級(jí)別提供了兩種流量控制。為什么需要兩類流量控制呢？主要是因?yàn)?QUIC 支持多路復(fù)用。

Stream 可以認(rèn)為就是一條 HTTP 請(qǐng)求。

Connection 可以類比一條 TCP 連接。多路復(fù)用意味著在一條 Connetion 上會(huì)同時(shí)存在多條 Stream。既需要對(duì)單個(gè) Stream 進(jìn)行控制，又需要針對(duì)所有 Stream 進(jìn)行總體控制。

QUIC 實(shí)現(xiàn)流量控制的原理比較簡(jiǎn)單：

通過(guò) window_update 幀告訴對(duì)端自己可以接收的字節(jié)數(shù)，這樣發(fā)送方就不會(huì)發(fā)送超過(guò)這個(gè)數(shù)量的數(shù)據(jù)。

通過(guò) BlockFrame 告訴對(duì)端由于流量控制被阻塞了，無(wú)法發(fā)送數(shù)據(jù)。

QUIC 的流量控制和 TCP 有點(diǎn)區(qū)別，TCP 為了保證可靠性，窗口左邊沿向右滑動(dòng)時(shí)的長(zhǎng)度取決于已經(jīng)確認(rèn)的字節(jié)數(shù)。如果中間出現(xiàn)丟包，就算接收到了更大序號(hào)的 Segment，窗口也無(wú)法超過(guò)這個(gè)序列號(hào)。

但 QUIC 不同，就算此前有些 packet 沒(méi)有接收到，它的滑動(dòng)只取決于接收到的最大偏移字節(jié)數(shù)。

圖 5 Quic Flow Control

針對(duì) Stream：

針對(duì) Connection：

同樣地，STGW 也在連接和 Stream 級(jí)別設(shè)置了不同的窗口數(shù)。

最重要的是，我們可以在內(nèi)存不足或者上游處理性能出現(xiàn)問(wèn)題時(shí)，通過(guò)流量控制來(lái)限制傳輸速率，保障服務(wù)可用性。

沒(méi)有隊(duì)頭阻塞的多路復(fù)用

?QUIC 的多路復(fù)用和 HTTP2 類似。在一條 QUIC 連接上可以并發(fā)發(fā)送多個(gè) HTTP 請(qǐng)求 (stream)。但是 QUIC 的多路復(fù)用相比 HTTP2 有一個(gè)很大的優(yōu)勢(shì)。

QUIC 一個(gè)連接上的多個(gè) stream 之間沒(méi)有依賴。這樣假如 stream2 丟了一個(gè) udp packet，也只會(huì)影響 stream2 的處理。不會(huì)影響 stream2 之前及之后的 stream 的處理。

這也就在很大程度上緩解甚至消除了隊(duì)頭阻塞的影響。

多路復(fù)用是 HTTP2 最強(qiáng)大的特性 [7]，能夠?qū)⒍鄺l請(qǐng)求在一條 TCP 連接上同時(shí)發(fā)出去。但也惡化了 TCP 的一個(gè)問(wèn)題，隊(duì)頭阻塞 [11]，如下圖示：

圖 6 HTTP2 隊(duì)頭阻塞

HTTP2 在一個(gè) TCP 連接上同時(shí)發(fā)送 4 個(gè) Stream。其中 Stream1 已經(jīng)正確到達(dá)，并被應(yīng)用層讀取。但是 Stream2 的第三個(gè) tcp ?segment 丟失了，TCP 為了保證數(shù)據(jù)的可靠性，需要發(fā)送端重傳第 3 個(gè) segment 才能通知應(yīng)用層讀取接下去的數(shù)據(jù)，雖然這個(gè)時(shí)候 Stream3 和 Stream4 的全部數(shù)據(jù)已經(jīng)到達(dá)了接收端，但都被阻塞住了。

不僅如此，由于 HTTP2 強(qiáng)制使用 TLS，還存在一個(gè) TLS 協(xié)議層面的隊(duì)頭阻塞 [12]。

圖 7 TLS 隊(duì)頭阻塞

Record 是 TLS 協(xié)議處理的最小單位，最大不能超過(guò) 16K，一些服務(wù)器比如 Nginx 默認(rèn)的大小就是 16K。由于一個(gè) record 必須經(jīng)過(guò)數(shù)據(jù)一致性校驗(yàn)才能進(jìn)行加解密，所以一個(gè) 16K 的 record，就算丟了一個(gè)字節(jié)，也會(huì)導(dǎo)致已經(jīng)接收到的 15.99K 數(shù)據(jù)無(wú)法處理，因?yàn)樗煌暾?/span>

那 QUIC 多路復(fù)用為什么能避免上述問(wèn)題呢？

QUIC 最基本的傳輸單元是 Packet，不會(huì)超過(guò) MTU 的大小，整個(gè)加密和認(rèn)證過(guò)程都是基于 Packet 的，不會(huì)跨越多個(gè) Packet。這樣就能避免 TLS 協(xié)議存在的隊(duì)頭阻塞。

Stream 之間相互獨(dú)立，比如 Stream2 丟了一個(gè) Pakcet，不會(huì)影響 Stream3 和 Stream4。不存在 TCP 隊(duì)頭阻塞。

圖 8 QUIC 多路復(fù)用時(shí)沒(méi)有隊(duì)頭阻塞的問(wèn)題

當(dāng)然，并不是所有的 QUIC 數(shù)據(jù)都不會(huì)受到隊(duì)頭阻塞的影響，比如 QUIC 當(dāng)前也是使用 Hpack 壓縮算法 [10]，由于算法的限制，丟失一個(gè)頭部數(shù)據(jù)時(shí)，可能遇到隊(duì)頭阻塞。

總體來(lái)說(shuō)，QUIC 在傳輸大量數(shù)據(jù)時(shí)，比如視頻，受到隊(duì)頭阻塞的影響很小。

加密認(rèn)證的報(bào)文

TCP 協(xié)議頭部沒(méi)有經(jīng)過(guò)任何加密和認(rèn)證，所以在傳輸過(guò)程中很容易被中間網(wǎng)絡(luò)設(shè)備篡改，注入和竊聽(tīng)。比如修改序列號(hào)、滑動(dòng)窗口。這些行為有可能是出于性能優(yōu)化，也有可能是主動(dòng)攻擊。

但是 QUIC 的 packet 可以說(shuō)是武裝到了牙齒。除了個(gè)別報(bào)文比如 PUBLIC_RESET 和 CHLO，所有報(bào)文頭部都是經(jīng)過(guò)認(rèn)證的，報(bào)文 Body 都是經(jīng)過(guò)加密的。

這樣只要對(duì) QUIC 報(bào)文任何修改，接收端都能夠及時(shí)發(fā)現(xiàn)，有效地降低了安全風(fēng)險(xiǎn)。

如下圖所示，紅色部分是 Stream Frame 的報(bào)文頭部，有認(rèn)證。綠色部分是報(bào)文內(nèi)容，全部經(jīng)過(guò)加密。

連接遷移

?一條 TCP 連接 [17] 是由四元組標(biāo)識(shí)的（源 IP，源端口，目的 IP，目的端口）。什么叫連接遷移呢？就是當(dāng)其中任何一個(gè)元素發(fā)生變化時(shí)，這條連接依然維持著，能夠保持業(yè)務(wù)邏輯不中斷。當(dāng)然這里面主要關(guān)注的是客戶端的變化，因?yàn)榭蛻舳瞬豢煽夭⑶揖W(wǎng)絡(luò)環(huán)境經(jīng)常發(fā)生變化，而服務(wù)端的 IP 和端口一般都是固定的。

比如大家使用手機(jī)在 WIFI 和 4G 移動(dòng)網(wǎng)絡(luò)切換時(shí)，客戶端的 IP 肯定會(huì)發(fā)生變化，需要重新建立和服務(wù)端的 TCP 連接。

又比如大家使用公共 NAT 出口時(shí)，有些連接競(jìng)爭(zhēng)時(shí)需要重新綁定端口，導(dǎo)致客戶端的端口發(fā)生變化，同樣需要重新建立 TCP 連接。

針對(duì) TCP 的連接變化，MPTCP[5] 其實(shí)已經(jīng)有了解決方案，但是由于 MPTCP 需要操作系統(tǒng)及網(wǎng)絡(luò)協(xié)議棧支持，部署阻力非常大，目前并不適用。

所以從 TCP 連接的角度來(lái)講，這個(gè)問(wèn)題是無(wú)解的。

那 QUIC 是如何做到連接遷移呢？很簡(jiǎn)單，任何一條 QUIC 連接不再以 IP 及端口四元組標(biāo)識(shí)，而是以一個(gè) 64 位的隨機(jī)數(shù)作為 ID 來(lái)標(biāo)識(shí)，這樣就算 IP 或者端口發(fā)生變化時(shí)，只要 ID 不變，這條連接依然維持著，上層業(yè)務(wù)邏輯感知不到變化，不會(huì)中斷，也就不需要重連。

由于這個(gè) ID 是客戶端隨機(jī)產(chǎn)生的，并且長(zhǎng)度有 64 位，所以沖突概率非常低。

其他亮點(diǎn)

?此外，QUIC 還能實(shí)現(xiàn)前向冗余糾錯(cuò)，在重要的包比如握手消息發(fā)生丟失時(shí)，能夠根據(jù)冗余信息還原出握手消息。

QUIC 還能實(shí)現(xiàn)證書(shū)壓縮，減少證書(shū)傳輸量，針對(duì)包頭進(jìn)行驗(yàn)證等。

限于篇幅，本文不再詳細(xì)介紹，有興趣的可以參考文檔 [23] 和文檔 [4] 和文檔 [26]。

參考線索

[1].?https://www.chromium.org/quic

[2].?https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit

[3].?E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3”, ?draft-ietf-tls-tls13-21, https://tools.ietf.org/html/draft-ietf-tls-tls13-21, July 03, 2017

[4].?Adam Langley,Wan-Teh Chang, “QUIC Crypto”，https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit, 20161206

[5].?https://www.multipath-tcp.org/

[6].?Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly?High-Speed TCP Variant", ACM SIGOPS Operating System?Review , 2008.

[7].?M. Belshe,BitGo, R. Peon, “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, May 2015

[8].?M. Mathis,J. Mahdavi,S. Floyd,A. Romanow,“TCP Selective Acknowledgment Options”, rfc2018, https://tools.ietf.org/html/rfc2018, October 1996

[9].?V. Paxson，M. Allman，J. Chu，M. Sargent，“Computing TCP's Retransmission Timer”， rfc6298, https://tools.ietf.org/html/rfc6298, June 2011

[10].?R. Peon,H. Ruellan,“HPACK: Header Compression for HTTP/2”,RFC7541,May 2015

[11].?M. Scharf, Alcatel-Lucent Bell Labs, S. Kiesel, “Quantifying Head-of-Line Blocking in TCP and SCTP”, https://tools.ietf.org/id/draft-scharf-tcpm-reordering-00.html, July 15, 2013

[12].??Ilya Grigorik，“Optimizing TLS Record Size & Buffering Latency”, https://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/, October 24, 2013

[13].?J. Salowey,H. Zhou,P. Eronen,H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State”, RFC5077, January 2008

[14].?Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[15].?Shirey, R., "Internet Security Glossary, Version 2", FYI?, RFC 4949, August 2007

[16].?羅成，“HTTPS性能優(yōu)化”，?http://www.infoq.com/cn/presentations/performance-optimization-of-https，February.2017

[17].?Postel, J., "Transmission Control Protocol", STD 7, RFC793, September 1981.

[18].?J. Postel,“User Datagram Protocol”, RFC768,August 1980

[19].?Q. Dang, S. Santesson,K. Moriarty,D. Brown.T. Polk, “Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA”,RFC5758, January 2010

[20].?Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002

[21].?D.Cooper,S.Santesson, S.Farrell,S. Boeyen,R. Housley,W.Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC5280, May 2008

[22].?M. Allman,V. Paxson,E. Blanton,?"TCP Congestion Control”,RFC5681, September 2009

[23].?Robbie Shade, “Flow control in QUIC”, https://docs.google.com/document/d/1F2YfdDXKpy20WVKJueEf4abn_LVZHhMUMS5gX6Pgjl4/edit#, ?May, 2016,

[24].?ianswett , “QUIC fec v1”, https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit#heading=h.xgjl2srtytjt, 2016-02-19

[25].?D.Borman,B.Braden,V.Jacobson,R.Scheffenegger, Ed. “TCP Extensions for High Performance”,rfc7323, https://tools.ietf.org/html/rfc7323,September 2014

[26].?羅成，“WEB加速，協(xié)議先行”，?https://zhuanlan.zhihu.com/p/27938635，july, 2017

讀者須知

為了給大家分享更多的騰訊技術(shù)消息，即日起，騰訊技術(shù)工程官方號(hào)將轉(zhuǎn)為訂閱號(hào)。推薦你將“騰訊技術(shù)工程官方號(hào)”置頂，以免錯(cuò)過(guò)有關(guān)騰訊技術(shù)工程的重大消息。近期還將有大量騰訊周邊禮品贈(zèng)送活動(dòng)哦！

總結(jié)

以上是生活随笔為你收集整理的科普：QUIC协议原理分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。