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

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

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

寫在前面

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

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

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

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

你愿意花一點點時間了解這個協(xié)議嗎？你愿意投入精力去研究這個協(xié)議嗎？你愿意全力推動業(yè)務(wù)來使用這個協(xié)議嗎？

QUIC 概述

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

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

減少了 TCP 三次握手及 TLS 握手時間。

改進的擁塞控制。

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

連接遷移。

前向冗余糾錯。

為什么需要 QUIC

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

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

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

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

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

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

建立連接的握手延遲大。

隊頭阻塞。

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

中間設(shè)備的僵化

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

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

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

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

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

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

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

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

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

建立連接的握手延遲大

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

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

2.TLS 完全握手需要至少 2 個 RTT 才能建立，簡化握手需要 1 個 RTT 的握手延遲。

對于很多短連接場景，這樣的握手延遲影響很大，且無法消除。

隊頭阻塞

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

另外 TLS 協(xié)議層面也有一個隊頭阻塞，因為 TLS 協(xié)議都是按照 record 來處理數(shù)據(jù)的，如果一個 record 中丟失了數(shù)據(jù)，也會導(dǎo)致整個 record 無法正確處理。

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

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

QUIC 核心特性

連接建立延時低

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

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

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

圖 1 HTTPS 及 QUIC 建連過程

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

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

改進的擁塞控制

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

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

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

可插拔

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

應(yīng)用程序?qū)用婢湍軐崿F(xiàn)不同的擁塞控制算法，不需要操作系統(tǒng)，不需要內(nèi)核支持。這是一個飛躍，因為傳統(tǒng)的 TCP 擁塞控制，必須要端到端的網(wǎng)絡(luò)協(xié)議棧支持，才能實現(xiàn)控制效果。而內(nèi)核和操作系統(tǒng)的部署成本非常高，升級周期很長，這在產(chǎn)品快速迭代，網(wǎng)絡(luò)爆炸式增長的今天，顯然有點滿足不了需求。

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

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

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

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

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

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

圖 2 Tcp 重傳歧義性

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

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

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

圖 3 Quic 重傳沒有歧義性

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

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

即一個 Stream 可以經(jīng)過多個 Packet 傳輸，Packet Number 嚴(yán)格遞增，沒有依賴。但是 Packet 里的 Payload 如果是 Stream 的話，就需要依靠 Stream 的 Offset 來保證應(yīng)用數(shù)據(jù)的順序。如錯誤! 未找到引用源。所示，發(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 按照順序組織起來，交給應(yīng)用程序處理。

圖 4 Stream Offset 保證有序性

不允許 Reneging

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

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

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

更多的 Ack 塊

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

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

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

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

Ack Delay 時間

Tcp 的 Timestamp 選項存在一個問題 [25]，它只是回顯了發(fā)送方的時間戳，但是沒有計算接收端接收到 segment 到發(fā)送 Ack 該 segment 的時間。這個時間可以簡稱為 Ack Delay。

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

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

而 Quic 計算如下：

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

基于 stream 和 connecton 級別的流量控制

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

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

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

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

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

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

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

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

圖 5 Quic Flow Control

針對 Stream：

針對 Connection：

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

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

沒有隊頭阻塞的多路復(fù)用

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

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

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

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

圖 6 HTTP2 隊頭阻塞

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

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

圖 7 TLS 隊頭阻塞

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

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

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

Stream 之間相互獨立，比如 Stream2 丟了一個 Pakcet，不會影響 Stream3 和 Stream4。不存在 TCP 隊頭阻塞。

圖 8 QUIC 多路復(fù)用時沒有隊頭阻塞的問題

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

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

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

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

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

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

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

連接遷移

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

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

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

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

所以從 TCP 連接的角度來講，這個問題是無解的。

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

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

其他亮點

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

QUIC 還能實現(xià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ù)工程官方號將轉(zhuǎn)為訂閱號。推薦你將“騰訊技術(shù)工程官方號”置頂，以免錯過有關(guān)騰訊技術(shù)工程的重大消息。近期還將有大量騰訊周邊禮品贈送活動哦！

總結(jié)

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

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