QUIC(Quick UDP Internet Connections，快速UDP互聯(lián)網(wǎng)連接)是Google提出的一種基于UDP改進(jìn)的通信協(xié)議，其目的是降低網(wǎng)絡(luò)通信的延遲，提供更好的用戶互動(dòng)體驗(yàn)。

QUIC的主要特點(diǎn)包括：具有SPDY(SPDY是谷歌研制的提升HTTP速度的協(xié)議，是HTTP/2.0的基礎(chǔ))所有的優(yōu)點(diǎn)；0-RTT連接；減少丟包；前向糾錯(cuò)，減少重傳時(shí)延；自適應(yīng)擁塞控制， 減少重新連接；相當(dāng)于TLS加密。

1.重傳與恢復(fù)

與TCP類(lèi)似，QUIC每發(fā)送一個(gè)包后，都會(huì)等待回復(fù)一個(gè)確認(rèn)包。當(dāng)丟包率超過(guò)協(xié)議的糾錯(cuò)門(mén)限時(shí)，會(huì)顯式或隱式地進(jìn)行重傳

對(duì)于某些重要的數(shù)據(jù)包，如初始密鑰協(xié)商時(shí)的數(shù)據(jù)包，在建立連接時(shí)非常重要，如果這類(lèi)包丟失會(huì)阻塞整體數(shù)據(jù)流。QUIC對(duì)于這一類(lèi)數(shù)據(jù)包在確認(rèn)發(fā)生丟失前就會(huì)嘗試重傳，通常是等待較短的時(shí)間(如20ms)沒(méi)收到確認(rèn)后就馬上再次發(fā)送。這樣在網(wǎng)絡(luò)中會(huì)有若干個(gè)相同的包同時(shí)傳輸，只要有一個(gè)能成功抵達(dá)就完成了連接，這樣降低了丟包率。接收方對(duì)于關(guān)鍵數(shù)據(jù)包的多次發(fā)送和普通數(shù)據(jù)包的超時(shí)重傳，都采用相同的重復(fù)包處理機(jī)制

QUIC在擁塞避免算法的基礎(chǔ)上還加入了心跳包，用于減少丟包率

QUIC使用了FEC(前向糾錯(cuò)碼)來(lái)恢復(fù)數(shù)據(jù)，F(xiàn)EC采用簡(jiǎn)單異或的方式。每次發(fā)送一組數(shù)據(jù)，包括若干個(gè)數(shù)據(jù)包后，并對(duì)這些數(shù)據(jù)包依次作異或運(yùn)算，最后的結(jié)果作為一個(gè)FEC包再發(fā)送出去。接收方收到一組數(shù)據(jù)后，根據(jù)數(shù)據(jù)包和FEC包即可以進(jìn)行校驗(yàn)和糾錯(cuò)。

2.安全性

QUIC對(duì)每個(gè)散裝的UDP包都進(jìn)行了加密和認(rèn)證的保護(hù)，并且避免使用前向依賴(lài)的處理方法(如CBC模式)，這樣每個(gè)UDP包可以獨(dú)立地根據(jù)IV進(jìn)行加密或認(rèn)證處理。

QUIC采用了兩級(jí)密鑰機(jī)制：初始密鑰和會(huì)話密鑰。初次連接時(shí)不加密，并協(xié)商初始密鑰。初始密鑰協(xié)商完畢后會(huì)馬上再協(xié)商會(huì)話密鑰，這樣可以保證密鑰的前向安全性，之后可以在通信的過(guò)程中就實(shí)現(xiàn)對(duì)密鑰的更新。接收方意識(shí)到有新的密鑰要更新時(shí)，會(huì)嘗試用新舊兩種密鑰對(duì)數(shù)據(jù)進(jìn)行解密，直到成功才會(huì)正式更新密鑰，否則會(huì)一直保留舊密鑰有效。

3. 0-RTT握手過(guò)程

QUIC握手的過(guò)程是需要一次數(shù)據(jù)交互，0-RTT時(shí)延即可完成握手過(guò)程中的密鑰協(xié)商，比TLS相比效率提高了5倍，且具有更高的安全性。

QUIC在握手過(guò)程中使用Diffie-Hellman算法協(xié)商初始密鑰，初始密鑰依賴(lài)于服務(wù)器存儲(chǔ)的一組配置參數(shù)，該參數(shù)會(huì)周期性的更新。初始密鑰協(xié)商成功后，服務(wù)器會(huì)提供一個(gè)臨時(shí)隨機(jī)數(shù)，雙方根據(jù)這個(gè)數(shù)再生成會(huì)話密鑰。

具體握手過(guò)程如下：

(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消息，開(kāi)始正式握手，消息中包括客戶端選擇的公開(kāi)數(shù)。此時(shí)客戶端根據(jù)獲取的服務(wù)器配置參數(shù)和自己選擇的公開(kāi)數(shù)，可以計(jì)算出初始密鑰。

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

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

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

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

Quic協(xié)議原理
1，0RTT 建連

先聲明一點(diǎn)，如果一對(duì)使用QUIC進(jìn)行加密通信的雙方此前從來(lái)沒(méi)有通信過(guò)，0RTT是不可能的。

所以第一次C和S建連還是會(huì)走正常的tls握手流程，但過(guò)了一會(huì)兒或者一段時(shí)間后，C又想和S通信，此時(shí)C已經(jīng)有了剛剛和S協(xié)商出來(lái)的密鑰（可能是存在內(nèi)存or外存）。C就會(huì)利用剛剛的密鑰K1來(lái)和S加密首次數(shù)據(jù)，在第二個(gè)RTT期間，S會(huì)和C協(xié)商出新的密鑰K2，作為接下來(lái)的通信密鑰。

2，沒(méi)有歧義的重傳
TCP 重傳的 包 的 sequence number 和原始的 包 的 Sequence Number 是保持不變的，也正是由于這個(gè)特性，引入了 Tcp 重傳的歧義問(wèn)題。

超時(shí)事件 RTO 發(fā)生后，客戶端發(fā)起重傳，然后接收到了 Ack 數(shù)據(jù)。由于Sequence Number一樣，這個(gè) Ack 到底是原始請(qǐng)求的響應(yīng)還是重傳請(qǐng)求的響應(yīng)呢？這就間接導(dǎo)致了RTT計(jì)算的歧義。

Quic 使用 Packet Number 代替了 TCP 的 sequence number，并且每個(gè) Packet Number 都嚴(yán)格遞增，也就是說(shuō)就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N，而是一個(gè)比 N 大的值，這就解決了RTT計(jì)算的歧義問(wèn)題。

3，保證包的順序
QUIC 引入了一個(gè)叫 Stream Offset 的概念。

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

4，解決ack delay

TCP 的 RTT 計(jì)算：

Quic的RTT計(jì)算：

5，隊(duì)頭阻塞
拿http2舉例，

http2 在一個(gè) TCP 連接上同時(shí)發(fā)送 4 個(gè) 請(qǐng)求。其中 請(qǐng)求1 已經(jīng)正確到達(dá)，并被應(yīng)用層讀取。但是 請(qǐng)求2 的第三個(gè) tcp包丟失了，為了保證數(shù)據(jù)的順序，需要發(fā)送端重傳第 3 個(gè)包才能通知應(yīng)用層讀取接下去的數(shù)據(jù)，雖然這個(gè)時(shí)候 請(qǐng)求3 和 請(qǐng)求4 的全部數(shù)據(jù)已經(jīng)到達(dá)了接收端，但都被阻塞住了。

Quic基于UDP，各個(gè)請(qǐng)求之間相互獨(dú)立，比如 請(qǐng)求2 丟了一個(gè) Pakcet，不會(huì)影響 請(qǐng)求3 和 請(qǐng)求4，不存在 TCP 隊(duì)頭阻塞。

四，Quic和http3
QUIC 協(xié)議最初是由Google發(fā)起的項(xiàng)目，后面慢慢成為了 HTTP/2-encrypted-over-UDP 協(xié)議。
當(dāng) IETF 開(kāi)始進(jìn)行協(xié)議標(biāo)準(zhǔn)化工作時(shí)，協(xié)議被分為兩層：傳輸部分和 HTTP 部分。這個(gè)想法的初衷是考慮到該傳輸協(xié)議也可用于傳輸其他數(shù)據(jù)，而不僅僅用于 HTTP 協(xié)議。
社區(qū)中大家使用 iQUIC 和 gQUIC 這樣的非正式名稱(chēng)來(lái)引用這些不同版本的協(xié)議，以便將IETF 和 Google提出的QUIC 協(xié)議分開(kāi)。
通過(guò) iQUIC 發(fā)送 HTTP 請(qǐng)求的協(xié)議被稱(chēng)為HTTP-over-QUIC，即HTTP3。

例子：
https://www.cnblogs.com/jb2011/p/8458549.html

參考資料
下一代通信協(xié)議：Quic
https://knownsec-fed.com/2018-01-19-xia-yi-dai-tong-xin-xie-yi-quic/
QUIC協(xié)議是如何做到0RTT加密傳輸?shù)?br />https://blog.csdn.net/dog250/article/details/80935534
Web服務(wù)器快速啟用QUIC協(xié)議
https://my.oschina.net/u/347901/blog/1647385
QUIC協(xié)議原理分析
https://zhuanlan.zhihu.com/p/32553477
QUIC在騰訊的實(shí)踐及性能優(yōu)化
https://zhuanlan.zhihu.com/p/32560981
七牛云 QUIC 推流方案如何實(shí)現(xiàn)直播 0 卡頓
https://zhuanlan.zhihu.com/p/33698793
當(dāng)我們?cè)谟懻揾ttp隊(duì)頭阻塞時(shí)，我們?cè)谟懻撌裁矗?br />https://liudanking.com/arch/what-is-head-of-line-blocking-http2-quic/
QUIC官方文檔
https://www.chromium.org/quic
QUIC協(xié)議規(guī)范

https://www.wolfcstech.com/2017/01/13/QUIC%E5%8D%8F%E8%AE%AE%E8%A7%84%E8%8C%83/

總結(jié)

以上是生活随笔為你收集整理的新一代互联网传输协议QUIC的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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