1.QUIC是啥？

1.1 什么是QUIC

QUIC(Quick UDP Internet Connection)是谷歌推出的一套基于UDP的傳輸協(xié)議，它實(shí)現(xiàn)了TCP + HTTPS + HTTP/2的功能，目的是保證可靠性的同時(shí)降低網(wǎng)絡(luò)延遲。因?yàn)閁DP是一個(gè)簡(jiǎn)單傳輸協(xié)議，基于UDP可以擺脫TCP傳輸確認(rèn)、重傳慢啟動(dòng)等因素，建立安全連接只需要一的個(gè)往返時(shí)間，它還實(shí)現(xiàn)了HTTP/2多路復(fù)用、頭部壓縮等功能。

眾所周知UDP比TCP傳輸速度快，TCP是可靠協(xié)議，但是代價(jià)是雙方確認(rèn)數(shù)據(jù)而衍生的一系列消耗。其次TCP是系統(tǒng)內(nèi)核實(shí)現(xiàn)的，如果升級(jí)TCP協(xié)議，就得讓用戶升級(jí)系統(tǒng)，這個(gè)的門檻比較高，而QUIC在UDP基礎(chǔ)上由客戶端自由發(fā)揮，只要有服務(wù)器能對(duì)接就可以。

1.2 HTTP協(xié)議發(fā)展

1.2.1 HTTP歷史進(jìn)程

• HTTP 0.9（1991年）只支持get方法不支持請(qǐng)求頭；
• HTTP 1.0（1996年）基本成型，支持請(qǐng)求頭、富文本、狀態(tài)碼、緩存、連接無(wú)法復(fù)用；
• HTTP 1.1（1999年）支持連接復(fù)用、分塊發(fā)送、斷點(diǎn)續(xù)傳；
• HTTP 2.0（2015年）二進(jìn)制分幀傳輸、多路復(fù)用、頭部壓縮、服務(wù)器推送等；
• HTTP 3.0（2018年）QUIC 于2013年實(shí)現(xiàn)、2018年正式更名為HTTP3；

1.2.2 HTTP 1.0和HTTP1.1

• 隊(duì)頭阻塞：下個(gè)請(qǐng)求必須在前一個(gè)請(qǐng)求返回后才能發(fā)出，導(dǎo)致帶寬無(wú)法被充分利用，后續(xù)請(qǐng)求被阻塞（HTTP 1.1 嘗試使用流水線（Pipelining）技術(shù)，但先天 FIFO（先進(jìn)先出）機(jī)制導(dǎo)致當(dāng)前請(qǐng)求的執(zhí)行依賴于上一個(gè)請(qǐng)求執(zhí)行的完成，容易引起隊(duì)頭阻塞，并沒有從根本上解決問題）
• 協(xié)議開銷大：header里攜帶的內(nèi)容過大，且不能壓縮，增加了傳輸?shù)某杀?/li>
• 單向請(qǐng)求：只能單向請(qǐng)求，客戶端請(qǐng)求什么，服務(wù)器返回什么

HTTP 1.0和HTTP 1.1的區(qū)別：

HTTP 1.0HTTP 1.1

僅支持保持短暫的TCP連接（連接無(wú)法復(fù)用）	默認(rèn)支持長(zhǎng)連接（請(qǐng)求可復(fù)用TCP連接）
不支持?jǐn)帱c(diǎn)續(xù)傳	支持?jǐn)帱c(diǎn)續(xù)傳（通過在 Header 設(shè)置參數(shù)）
前一個(gè)請(qǐng)求響應(yīng)到達(dá)之后下一個(gè)請(qǐng)求才能發(fā)送，存在隊(duì)頭阻塞	優(yōu)化了緩存控制策略
/	管道化，可以一次發(fā)送多個(gè)請(qǐng)求，但是響應(yīng)仍是順序返回，仍然無(wú)法解決隊(duì)頭阻塞的問題
/	新增錯(cuò)誤狀態(tài)碼通知
/	請(qǐng)求消息和響應(yīng)消息都支持Host頭域

1.2.3 HTTP2

解決 HTTP1 的一些問題，但是解決不了底層 TCP 協(xié)議層面上的隊(duì)頭阻塞問題。

1.二進(jìn)制傳輸：二進(jìn)制格式傳輸數(shù)據(jù)解析起來比文本更高效；

2.多路復(fù)用：重新定義底層 http 語(yǔ)義映射，允許同一個(gè)連接上使用請(qǐng)求和響應(yīng)雙向數(shù)據(jù)流。同一域名只需占用一個(gè) TCP 連接，通過數(shù)據(jù)流（Stream）以幀為基本協(xié)議單位，避免了因頻繁創(chuàng)建連接產(chǎn)生的延遲，減少了內(nèi)存消耗，提升了使用性能，并行請(qǐng)求，且慢的請(qǐng)求或先發(fā)送的請(qǐng)求不會(huì)阻塞其他請(qǐng)求的返回；

3.Header壓縮：減少請(qǐng)求中的冗余數(shù)據(jù)，降低開銷；

4.服務(wù)端可以主動(dòng)推送：提前給客戶端推送必要的資源，這樣就可以相對(duì)減少一點(diǎn)延遲時(shí)間；

5.流優(yōu)先級(jí)：數(shù)據(jù)傳輸優(yōu)先級(jí)可控，使網(wǎng)站可以實(shí)現(xiàn)更靈活和強(qiáng)大的頁(yè)面控制；

6.可重置：能在不中斷 TCP 連接的情況下停止數(shù)據(jù)的發(fā)送；

缺點(diǎn)：HTTP 2中，多個(gè)請(qǐng)求在一個(gè)TCP管道中的，出現(xiàn)了丟包時(shí)，HTTP 2的表現(xiàn)反倒不如HTTP 1.1了。因?yàn)?TCP 為了保證可靠傳輸，有個(gè)特別的“丟包重傳”機(jī)制，丟失的包必須要等待重新傳輸確認(rèn)，HTTP 2出現(xiàn)丟包時(shí)，整個(gè) TCP 都要開始等待重傳，那么就會(huì)阻塞該TCP連接中的所有請(qǐng)求。而對(duì)于 HTTP 1.1 來說，可以開啟多個(gè) TCP 連接，出現(xiàn)這種情況反到只會(huì)影響其中一個(gè)連接，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)。

1.2.4 HTTP3——QUIC

HTTP 是建立在 TCP 協(xié)議之上，所有 HTTP 協(xié)議的瓶頸及其優(yōu)化技巧都是基于 TCP 協(xié)議本身的特性，HTTP2 雖然實(shí)現(xiàn)了多路復(fù)用，底層 TCP 協(xié)議層面上的問題并沒有解決（HTTP 2.0 同一域名下只需要使用一個(gè) TCP 連接。但是如果這個(gè)連接出現(xiàn)了丟包，會(huì)導(dǎo)致整個(gè) TCP 都要開始等待重傳，后面的所有數(shù)據(jù)都被阻塞了），而 HTTP3 的 QUIC 就是為解決 HTTP2 的 TCP 問題而生。

2. QUIC的關(guān)鍵特性

關(guān)于 QUIC 的原理，相關(guān)介紹的文章很多，這里再列舉一下 QUIC 的重要特性。這些特性是 QUIC 得以被廣泛應(yīng)用的關(guān)鍵。不同業(yè)務(wù)也可以根據(jù)業(yè)務(wù)特點(diǎn)利用 QUIC 的特性去做一些優(yōu)化。同時(shí)，這些特性也是我們?nèi)ヌ峁?QUIC 服務(wù)的切入點(diǎn)。

2.1 連接遷移

2.1.1 TCP的連接重連之痛

一條 TCP 連接是由四元組標(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 連接。

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

2.1.2 基于UDP的QUIC連接遷移實(shí)現(xiàn)

當(dāng)用戶的地址發(fā)生變化時(shí)，如 WIFI 切換到 4G 場(chǎng)景，基于 TCP 的 HTTP 協(xié)議無(wú)法保持連接的存活。QUIC 基于連接 ID 唯一識(shí)別連接。當(dāng)源地址發(fā)生改變時(shí)，QUIC 仍然可以保證連接存活和數(shù)據(jù)正常收發(fā)。

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

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

圖2-1 TCP 和 QUIC 在 Wi-Fi 和 cellular 切換時(shí)，唯一標(biāo)識(shí)的不同情況

2.2 低連接延時(shí)

2.2.1 TLS的連接時(shí)延問題

以一次簡(jiǎn)單的瀏覽器訪問為例，在地址欄中輸入https://www.abc.com，實(shí)際會(huì)產(chǎn)生以下動(dòng)作：

◎DNS遞歸查詢www.abc.com，獲取地址解析的對(duì)應(yīng)IP；

◎TCP握手，我們熟悉的TCP三次握手需要需要1個(gè)RTT；

◎TLS握手，以目前應(yīng)用最廣泛的TLS 1.2而言，需要2個(gè)RTT。對(duì)于非首次建連，可以選擇啟用會(huì)話重用，則可縮小握手時(shí)間到1個(gè)RTT；

◎HTTP業(yè)務(wù)數(shù)據(jù)交互，假設(shè)abc.com的數(shù)據(jù)在一次交互就能取回來。那么業(yè)務(wù)數(shù)據(jù)的交互需要1個(gè)RTT；經(jīng)過上面的過程分析可知，要完成一次簡(jiǎn)短的HTTPS業(yè)務(wù)數(shù)據(jù)交互，需要經(jīng)歷：新連接 4RTT + DNS；會(huì)話重用 3RTT + DNS。

所以，對(duì)于數(shù)據(jù)量小的請(qǐng)求而言，單一次的請(qǐng)求握手就占用了大量的時(shí)間，對(duì)于用戶體驗(yàn)的影響非常大。同時(shí)，在用戶網(wǎng)絡(luò)不佳的情況下，RTT延時(shí)會(huì)變得較高，極其影響用戶體驗(yàn)。

下圖對(duì)比了TLS各版本與場(chǎng)景下的延時(shí)對(duì)比：

圖2-2 TLS各個(gè)版本握手時(shí)延

從對(duì)比我們可以看到，即使用上了TLS 1.3，精簡(jiǎn)了握手過程，最快能做到0-RTT握手(首次是1-RTT)；但是對(duì)用戶感知而言, 還要加上1RTT的TCP握手開銷。

Google有提出Fastopen的方案來使得TCP非首次握手就能附帶用戶數(shù)據(jù)，但是由于TCP實(shí)現(xiàn)僵化，無(wú)法升級(jí)應(yīng)用，相關(guān)RFC到現(xiàn)今都是experimental狀態(tài)。這種分層設(shè)計(jì)帶來的延時(shí),有沒有辦法進(jìn)一步降低呢? QUIC通過合并加密與連接管理解決了這個(gè)問題，我們來看看其是如何實(shí)現(xiàn)真正意義上的0-RTT的握手, 讓與server進(jìn)行第一個(gè)數(shù)據(jù)包的交互就能帶上用戶數(shù)據(jù)。

2.2.2 真0-RTT的QUIC握手

QUIC 由于基于 UDP，無(wú)需 TCP 連接，在最好情況下，短連接下 QUIC 可以做到 0RTT 開啟數(shù)據(jù)傳輸。而基于 TCP 的 HTTPS，即使在最好的 TLS1.3 的 early data 下仍然需要 1RTT 開啟數(shù)據(jù)傳輸。而對(duì)于目前線上常見的 TLS1.2 完全握手的情況，則需要 3RTT 開啟數(shù)據(jù)傳輸。對(duì)于 RTT 敏感的業(yè)務(wù)，QUIC 可以有效的降低連接建立延遲。

究其原因一方面是TCP和TLS分層設(shè)計(jì)導(dǎo)致的：分層的設(shè)計(jì)需要每個(gè)邏輯層次分別建立自己的連接狀態(tài)。另一方面是TLS的握手階段復(fù)雜的密鑰協(xié)商機(jī)制導(dǎo)致的。要降低建連耗時(shí)，需要從這兩方面著手。

QUIC具體握手過程如下：

1.客戶端判斷本地是否已有服務(wù)器的全部配置參數(shù)（證書配置信息），如果有則直接跳轉(zhuǎn)到(5)，否則繼續(xù) ；

2.客戶端向服務(wù)器發(fā)送inchoate client hello(CHLO)消息，請(qǐng)求服務(wù)器傳輸配置參數(shù)；

3.服務(wù)器收到CHLO，回復(fù)rejection(REJ)消息，其中包含服務(wù)器的部分配置參數(shù)；

4.客戶端收到REJ，提取并存儲(chǔ)服務(wù)器配置參數(shù)，跳回到(1) ；

5.客戶端向服務(wù)器發(fā)送full client hello消息，開始正式握手，消息中包括客戶端選擇的公開數(shù)。此時(shí)客戶端根據(jù)獲取的服務(wù)器配置參數(shù)和自己選擇的公開數(shù)，可以計(jì)算出初始密鑰K1；

6.服務(wù)器收到full client hello，如果不同意連接就回復(fù)REJ，同(3)；如果同意連接，根據(jù)客戶端的公開數(shù)計(jì)算出初始密鑰K1，回復(fù)server hello(SHLO)消息，SHLO用初始密鑰K1加密，并且其中包含服務(wù)器選擇的一個(gè)臨時(shí)公開數(shù)；

7.客戶端收到服務(wù)器的回復(fù)，如果是REJ則情況同(4)；如果是SHLO，則嘗試用初始密鑰K1解密，提取出臨時(shí)公開數(shù)；

8.客戶端和服務(wù)器根據(jù)臨時(shí)公開數(shù)和初始密鑰K1，各自基于SHA-256算法推導(dǎo)出會(huì)話密鑰K2；

9.雙方更換為使用會(huì)話密鑰K2通信，初始密鑰K1此時(shí)已無(wú)用，QUIC握手過程完畢。之后會(huì)話密鑰K2更新的流程與以上過程類似，只是數(shù)據(jù)包中的某些字段略有不同。

圖2-3 QUIC 0-RTT 握手

2.3 可自定義的擁塞控制

Quic使用可插拔的擁塞控制，相較于TCP，它能提供更豐富的擁塞控制信息。比如對(duì)于每一個(gè)包，不管是原始包還是重傳包，都帶有一個(gè)新的序列號(hào)(seq)，這使得Quic能夠區(qū)分ACK是重傳包還是原始包，從而避免了TCP重傳模糊的問題。Quic同時(shí)還帶有收到數(shù)據(jù)包與發(fā)出ACK之間的時(shí)延信息。這些信息能夠幫助更精確的計(jì)算RTT。此外，Quic的ACK Frame 支持256個(gè)NACK 區(qū)間，相比于TCP的SACK(Selective Acknowledgment)更彈性化，更豐富的信息會(huì)讓client和server 哪些包已經(jīng)被對(duì)方收到。

QUIC 的傳輸控制不再依賴內(nèi)核的擁塞控制算法，而是實(shí)現(xiàn)在應(yīng)用層上，這意味著我們根據(jù)不同的業(yè)務(wù)場(chǎng)景，實(shí)現(xiàn)和配置不同的擁塞控制算法以及參數(shù)。GOOGLE 提出的 BBR 擁塞控制算法與 CUBIC 是思路完全不一樣的算法，在弱網(wǎng)和一定丟包場(chǎng)景，BBR 比 CUBIC 更不敏感，性能也更好。在 QUIC 下我們可以根據(jù)業(yè)務(wù)隨意指定擁塞控制算法和參數(shù)，甚至同一個(gè)業(yè)務(wù)的不同連接也可以使用不同的擁塞控制算法。

圖2-4 BBR擁塞弱網(wǎng)下算法效果對(duì)比

2.4 無(wú)隊(duì)頭阻塞

2.4.1 TCP的隊(duì)頭阻塞問題

雖然 HTTP2 實(shí)現(xiàn)了多路復(fù)用，但是因?yàn)槠浠诿嫦蜃止?jié)流的 TCP，因此一旦丟包，將會(huì)影響多路復(fù)用下的所有請(qǐng)求流。QUIC 基于 UDP，在設(shè)計(jì)上就解決了隊(duì)頭阻塞問題。

TCP 隊(duì)頭阻塞的主要原因是數(shù)據(jù)包超時(shí)確認(rèn)或丟失阻塞了當(dāng)前窗口向右滑動(dòng)，我們最容易想到的解決隊(duì)頭阻塞的方案是不讓超時(shí)確認(rèn)或丟失的數(shù)據(jù)包將當(dāng)前窗口阻塞在原地。QUIC也正是采用上述方案來解決TCP 隊(duì)頭阻塞問題的。

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

圖2-5 HTTP2隊(duì)頭阻塞
如上圖，應(yīng)用層可以順利讀取stream1中的內(nèi)容，但由于stream2中的第三個(gè)segment發(fā)生了丟包，TCP 為了保證數(shù)據(jù)的可靠性，需要發(fā)送端重傳第 3 個(gè) segment 才能通知應(yīng)用層讀取接下去的數(shù)據(jù)。所以即使stream3 stream4的內(nèi)容已順利抵達(dá)，應(yīng)用層仍然無(wú)法讀取，只能等待stream2中丟失的包進(jìn)行重傳。

在弱網(wǎng)環(huán)境下，HTTP2的隊(duì)頭阻塞問題在用戶體驗(yàn)上極為糟糕。

2.4.2 QUIC的無(wú)隊(duì)頭阻塞解決方案

QUIC 同樣是一個(gè)可靠的協(xié)議，它使用 Packet Number 代替了 TCP 的 Sequence Number，并且每個(gè) Packet Number 都嚴(yán)格遞增，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N，而是一個(gè)比 N 大的值，比如Packet N+M。

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ù)據(jù)包Packet N 丟失后，會(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ì)頭阻塞問題。那么，既然重傳數(shù)據(jù)包的Packet N+M 與丟失數(shù)據(jù)包的Packet N 編號(hào)并不一致，我們?cè)趺创_定這兩個(gè)數(shù)據(jù)包的內(nèi)容一樣呢？

QUIC使用Stream ID 來標(biāo)識(shí)當(dāng)前數(shù)據(jù)流屬于哪個(gè)資源請(qǐng)求，這同時(shí)也是數(shù)據(jù)包多路復(fù)用傳輸?shù)浇邮斩撕竽苷＝M裝的依據(jù)。重傳的數(shù)據(jù)包Packet N+M 和丟失的數(shù)據(jù)包Packet N 單靠Stream ID 的比對(duì)一致仍然不能判斷兩個(gè)數(shù)據(jù)包內(nèi)容一致，還需要再新增一個(gè)字段Stream Offset，標(biāo)識(shí)當(dāng)前數(shù)據(jù)包在當(dāng)前Stream ID 中的字節(jié)偏移量。

有了Stream Offset 字段信息，屬于同一個(gè)Stream ID 的數(shù)據(jù)包也可以亂序傳輸了（HTTP/2 中僅靠Stream ID 標(biāo)識(shí)，要求同屬于一個(gè)Stream ID 的數(shù)據(jù)幀必須有序傳輸），通過兩個(gè)數(shù)據(jù)包的Stream ID 與 Stream Offset 都一致，就說明這兩個(gè)數(shù)據(jù)包的內(nèi)容一致。

3. QUIC協(xié)議組成

QUIC 的 packet 除了個(gè)別報(bào)文比如 PUBLIC_RESET 和 CHLO，所有報(bào)文頭部都是經(jīng)過認(rèn)證的，報(bào)文 Body 都是經(jīng)過加密的。這樣只要對(duì) QUIC 報(bào)文任何修改，接收端都能夠及時(shí)發(fā)現(xiàn)，有效地降低了安全風(fēng)險(xiǎn)。

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

圖3-1 QUIC的協(xié)議組成

• Flags：用于表示Connection ID長(zhǎng)度、Packet Number長(zhǎng)度等信息；
• Connection ID：客戶端隨機(jī)選擇的最大長(zhǎng)度為64位的無(wú)符號(hào)整數(shù)。但是，長(zhǎng)度可以協(xié)商；
• QUIC Version：QUIC協(xié)議的版本號(hào)，32位的可選字段。如果Public Flag & FLAG_VERSION != 0，這個(gè)字段必填。客戶端設(shè)置Public Flag中的Bit0為1，并且填寫期望的版本號(hào)。如果客戶端期望的版本號(hào)服務(wù)端不支持，服務(wù)端設(shè)置Public Flag中的Bit0為1，并且在該字段中列出服務(wù)端支持的協(xié)議版本（0或者多個(gè)），并且該字段后不能有任何報(bào)文；
• Packet Number：長(zhǎng)度取決于Public Flag中Bit4及Bit5兩位的值，最大長(zhǎng)度6字節(jié)。發(fā)送端在每個(gè)普通報(bào)文中設(shè)置Packet Number。發(fā)送端發(fā)送的第一個(gè)包的序列號(hào)是1，隨后的數(shù)據(jù)包中的序列號(hào)的都大于前一個(gè)包中的序列號(hào)；
• Stream ID：用于標(biāo)識(shí)當(dāng)前數(shù)據(jù)流屬于哪個(gè)資源請(qǐng)求；
• Offset：標(biāo)識(shí)當(dāng)前數(shù)據(jù)包在當(dāng)前Stream ID 中的字節(jié)偏移量；

QUIC報(bào)文的大小需要滿足路徑MTU的大小以避免被分片。當(dāng)前QUIC在IPV6下的最大報(bào)文長(zhǎng)度為1350，IPV4下的最大報(bào)文長(zhǎng)度為1370。

4. 結(jié)語(yǔ)

QUIC具有眾多優(yōu)點(diǎn)，它融合了UDP協(xié)議的速度、性能與TCP的安全與可靠，同時(shí)也解決了HTTP1、HTTP1.1、HTTP2中引入的一些缺點(diǎn)，大大優(yōu)化了互聯(lián)網(wǎng)傳輸體驗(yàn)。

騰訊云CDN也緊跟技術(shù)浪潮，于今年年初迭代中加入了QUIC的功能支持，目前正在內(nèi)測(cè)當(dāng)中。掃碼可以申請(qǐng)內(nèi)測(cè)資格&查看文檔指引

申請(qǐng)內(nèi)測(cè)

參考資料
[1] QUIC 在 Facebook 是如何部署的？
[2] STGW 下一代互聯(lián)網(wǎng)標(biāo)準(zhǔn)傳輸協(xié)議QUIC大規(guī)模運(yùn)營(yíng)之路
[3] QUIC 0-RTT實(shí)現(xiàn)簡(jiǎn)析及一種分布式的0-RTT實(shí)現(xiàn)方案
[4] 科普：QUIC協(xié)議原理分析
[5] TCP BBR - Exploring TCP congestion control
[6] 淺談QUIC協(xié)議原理與性能分析及部署方案
[7] QUIC 是如何解決TCP 性能瓶頸的？
[8] QUIC協(xié)議和TCP/UDP協(xié)議
[9] QUIC的那些事 | 包類型及格式

總結(jié)

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

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