本文轉(zhuǎn)載自微信公眾號(hào)「后端技術(shù)指南針」，作者指南針氪金入口 。轉(zhuǎn)載本文請(qǐng)聯(lián)系后端技術(shù)指南針公眾號(hào)。

 1. 大白和小黑

生活不止眼前的茍且，還有詩(shī)和遠(yuǎn)方的田野。

新的一周又開(kāi)始了，大白和小黑是同事，平時(shí)倆人一起喝酒吃肉打游戲居多，當(dāng)然有時(shí)候也討論下學(xué)術(shù)和前沿技術(shù)。

這不，小黑聽(tīng)說(shuō)了個(gè)新鮮玩意，然后和大白聊了起來(lái)：

小黑：大白大白，聽(tīng)說(shuō)HTTP協(xié)議已經(jīng)到3.0了?

大白：是的，已經(jīng)到3.0了，甚至我還要告訴你它還是基于UDP開(kāi)發(fā)的!

小黑：UDP?沒(méi)搞錯(cuò)吧?!UDP可是不靠譜代言人啊，TCP不香了嗎?

大白：千真萬(wàn)確，而且已經(jīng)跑起來(lái)效果不錯(cuò)，正在推廣呢，據(jù)說(shuō)Chrome金絲雀版本已經(jīng)支持了，可以搶鮮試用。

小黑：害!我這個(gè)憨憨HTTP2.0還沒(méi)整明白，3.0就來(lái)了，快快快，給俺講講這個(gè)黑科技。

 

小黑是個(gè)爽快人，許諾大白給他講清楚了，周五就請(qǐng)一頓木屋燒烤，再小酌幾杯，放松一下。

[[341812]]

 

大白看在小黑對(duì)知識(shí)的渴求和燒烤的份上，決定給小黑講講HTTP3.0和QUIC協(xié)議那些事。

通過(guò)本文你將了解到以下內(nèi)容：

• HTTP2.0和TCP存在的一些問(wèn)題
• QUIC協(xié)議為什么選擇UDP
• QUIC協(xié)議的重要特性
• HTTP3.0和QUIC協(xié)議的前景和應(yīng)用效果

[[341813]]

 

2.HTTP2.0和HTTP3.0

科技永不止步。

我們都知道互聯(lián)網(wǎng)中業(yè)務(wù)是不斷迭代前進(jìn)的，像HTTP這種重要的網(wǎng)絡(luò)協(xié)議也是如此，新版本是對(duì)舊版本的揚(yáng)棄。

2.1 HTTP2.0和TCP的愛(ài)恨糾葛

HTTP2.0是2015年推出的，還是比較年輕的，其重要的二進(jìn)制分幀協(xié)議、多路復(fù)用、頭部壓縮、服務(wù)端推送等重要優(yōu)化使HTTP協(xié)議真正上了一個(gè)新臺(tái)階。

 

像谷歌這種重要的公司并沒(méi)有滿足于此，而且想繼續(xù)提升HTTP的性能，花最少的時(shí)間和資源獲取極致體驗(yàn)。

那么肯定要問(wèn)HTTP2.0雖然性能已經(jīng)不錯(cuò)了，還有什么不足嗎?

• 建立連接時(shí)間長(zhǎng)(本質(zhì)上是TCP的問(wèn)題)
• 隊(duì)頭阻塞問(wèn)題
• 移動(dòng)互聯(lián)網(wǎng)領(lǐng)域表現(xiàn)不佳(弱網(wǎng)環(huán)境)
• ......

熟悉HTTP2.0協(xié)議的同學(xué)應(yīng)該知道，這些缺點(diǎn)基本都是由于TCP協(xié)議引起的，水能載舟亦能覆舟，其實(shí)TCP也很無(wú)辜呀!

 

在我們眼里，TCP是面向連接、可靠的傳輸層協(xié)議，當(dāng)前幾乎所有重要的協(xié)議和應(yīng)用都是基于TCP來(lái)實(shí)現(xiàn)的。

網(wǎng)絡(luò)環(huán)境的改變速度很快，但是TCP協(xié)議相對(duì)緩慢，正是這種矛盾促使谷歌做出了一個(gè)看似出乎意料的決定-基于UDP來(lái)開(kāi)發(fā)新一代HTTP協(xié)議。

2.2 谷歌為什么選擇UDP

上文提到，谷歌選擇UDP是看似出乎意料的，仔細(xì)想一想其實(shí)很有道理。

我們單純地看看TCP協(xié)議的不足和UDP的一些優(yōu)點(diǎn)：

• 基于TCP開(kāi)發(fā)的設(shè)備和協(xié)議非常多，兼容困難
• TCP協(xié)議棧是Linux內(nèi)部的重要部分，修改和升級(jí)成本很大
• UDP本身是無(wú)連接的、沒(méi)有建鏈和拆鏈成本
• UDP的數(shù)據(jù)包無(wú)隊(duì)頭阻塞問(wèn)題
• UDP改造成本小

從上面的對(duì)比可以知道，谷歌要想從TCP上進(jìn)行改造升級(jí)絕非易事，但是UDP雖然沒(méi)有TCP為了保證可靠連接而引發(fā)的問(wèn)題，但是UDP本身不可靠，又不能直接用。

 

綜合而知，谷歌決定在UDP基礎(chǔ)上改造一個(gè)具備TCP協(xié)議優(yōu)點(diǎn)的新協(xié)議也就順理成章了，這個(gè)新協(xié)議就是QUIC協(xié)議。

2.3 QUIC協(xié)議和HTTP3.0

QUIC其實(shí)是Quick UDP Internet Connections的縮寫(xiě)，直譯為快速UDP互聯(lián)網(wǎng)連接。

 

我們來(lái)看看維基百科對(duì)于QUIC協(xié)議的一些介紹：

QUIC協(xié)議最初由Google的Jim Roskind設(shè)計(jì)，實(shí)施并于2012年部署，在2013年隨著實(shí)驗(yàn)的擴(kuò)大而公開(kāi)宣布，并向IETF進(jìn)行了描述。

QUIC提高了當(dāng)前正在使用TCP的面向連接的Web應(yīng)用程序的性能。它在兩個(gè)端點(diǎn)之間使用用戶數(shù)據(jù)報(bào)協(xié)議(UDP)建立多個(gè)復(fù)用連接來(lái)實(shí)現(xiàn)此目的。

QUIC的次要目標(biāo)包括減少連接和傳輸延遲，在每個(gè)方向進(jìn)行帶寬估計(jì)以避免擁塞。它還將擁塞控制算法移動(dòng)到用戶空間，而不是內(nèi)核空間，此外使用前向糾錯(cuò)(FEC)進(jìn)行擴(kuò)展，以在出現(xiàn)錯(cuò)誤時(shí)進(jìn)一步提高性能。

HTTP3.0又稱為HTTP Over QUIC，其棄用TCP協(xié)議，改為使用基于UDP協(xié)議的QUIC協(xié)議來(lái)實(shí)現(xiàn)。

 

3. QUIC協(xié)議詳解

擇其善者而從之，其不善者而改之。

HTTP3.0既然選擇了QUIC協(xié)議，也就意味著HTTP3.0基本繼承了HTTP2.0的強(qiáng)大功能，并且進(jìn)一步解決了HTTP2.0存在的一些問(wèn)題，同時(shí)必然引入了新的問(wèn)題。

 

QUIC協(xié)議必須要實(shí)現(xiàn)HTTP2.0在TCP協(xié)議上的重要功能，同時(shí)解決遺留問(wèn)題，我們來(lái)看看QUIC是如何實(shí)現(xiàn)的。

3.1 隊(duì)頭阻塞問(wèn)題

隊(duì)頭阻塞 Head-of-line blocking(縮寫(xiě)為HOL blocking)是計(jì)算機(jī)網(wǎng)絡(luò)中是一種性能受限的現(xiàn)象，通俗來(lái)說(shuō)就是：一個(gè)數(shù)據(jù)包影響了一堆數(shù)據(jù)包，它不來(lái)大家都走不了。

隊(duì)頭阻塞問(wèn)題可能存在于HTTP層和TCP層，在HTTP1.x時(shí)兩個(gè)層次都存在該問(wèn)題。

 

HTTP2.0協(xié)議的多路復(fù)用機(jī)制解決了HTTP層的隊(duì)頭阻塞問(wèn)題，但是在TCP層仍然存在隊(duì)頭阻塞問(wèn)題。

TCP協(xié)議在收到數(shù)據(jù)包之后，這部分?jǐn)?shù)據(jù)可能是亂序到達(dá)的，但是TCP必須將所有數(shù)據(jù)收集排序整合后給上層使用，如果其中某個(gè)包丟失了，就必須等待重傳，從而出現(xiàn)某個(gè)丟包數(shù)據(jù)阻塞整個(gè)連接的數(shù)據(jù)使用。

QUIC協(xié)議是基于UDP協(xié)議實(shí)現(xiàn)的，在一條鏈接上可以有多個(gè)流，流與流之間是互不影響的，當(dāng)一個(gè)流出現(xiàn)丟包影響范圍非常小，從而解決隊(duì)頭阻塞問(wèn)題。

3.2 0RTT 建鏈

衡量網(wǎng)絡(luò)建鏈的常用指標(biāo)是RTT Round-Trip Time，也就是數(shù)據(jù)包一來(lái)一回的時(shí)間消耗。

 

RTT包括三部分：往返傳播時(shí)延、網(wǎng)絡(luò)設(shè)備內(nèi)排隊(duì)時(shí)延、應(yīng)用程序數(shù)據(jù)處理時(shí)延。

 

一般來(lái)說(shuō)HTTPS協(xié)議要建立完整鏈接包括:TCP握手和TLS握手，總計(jì)需要至少2-3個(gè)RTT，普通的HTTP協(xié)議也需要至少1個(gè)RTT才可以完成握手。

然而，QUIC協(xié)議可以實(shí)現(xiàn)在第一個(gè)包就可以包含有效的應(yīng)用數(shù)據(jù)，從而實(shí)現(xiàn)0RTT，但這也是有條件的。

 

簡(jiǎn)單來(lái)說(shuō)，基于TCP協(xié)議和TLS協(xié)議的HTTP2.0在真正發(fā)送數(shù)據(jù)包之前需要花費(fèi)一些時(shí)間來(lái)完成握手和加密協(xié)商，完成之后才可以真正傳輸業(yè)務(wù)數(shù)據(jù)。

但是QUIC則第一個(gè)數(shù)據(jù)包就可以發(fā)業(yè)務(wù)數(shù)據(jù)，從而在連接延時(shí)有很大優(yōu)勢(shì)，可以節(jié)約數(shù)百毫秒的時(shí)間。

 

QUIC的0RTT也是需要條件的，對(duì)于第一次交互的客戶端和服務(wù)端0RTT也是做不到的，畢竟雙方完全陌生。

因此，QUIC協(xié)議可以分為首次連接和非首次連接，兩種情況進(jìn)行討論。

3.3 首次連接和非首次連接

使用QUIC協(xié)議的客戶端和服務(wù)端要使用1RTT進(jìn)行密鑰交換，使用的交換算法是DH(Diffie-Hellman)迪菲-赫爾曼算法。

DH算法開(kāi)辟了密鑰交換的新思路，在之前的文章中提到的RSA算法也是基于這種思想實(shí)現(xiàn)的，但是DH算法和RSA的密鑰交換不完全一樣，感興趣的讀者可以看看DH算法的數(shù)學(xué)原理。

DH算法開(kāi)辟了密鑰交換的新思路，在之前的文章中提到的RSA算法也是基于這種思想實(shí)現(xiàn)的，但是DH算法和RSA的密鑰交換不完全一樣，感興趣的讀者可以看看DH算法的數(shù)學(xué)原理。

3.3.1 首次連接

簡(jiǎn)單來(lái)說(shuō)一下，首次連接時(shí)客戶端和服務(wù)端的密鑰協(xié)商和數(shù)據(jù)傳輸過(guò)程，其中涉及了DH算法的基本過(guò)程：

 

3.3.2 非首次連接

前面提到客戶端和服務(wù)端首次連接時(shí)服務(wù)端傳遞了config包，里面包含了服務(wù)端公鑰和兩個(gè)隨機(jī)數(shù)，客戶端會(huì)將config存儲(chǔ)下來(lái)，后續(xù)再連接時(shí)可以直接使用，從而跳過(guò)這個(gè)1RTT，實(shí)現(xiàn)0RTT的業(yè)務(wù)數(shù)據(jù)交互。

客戶端保存config是有時(shí)間期限的，在config失效之后仍然需要進(jìn)行首次連接時(shí)的密鑰交換。

3.4 前向安全問(wèn)題

前向安全是密碼學(xué)領(lǐng)域的專業(yè)術(shù)語(yǔ)，看下百度上的解釋：

前向安全或前向保密Forward Secrecy是密碼學(xué)中通訊協(xié)議的安全屬性，指的是長(zhǎng)期使用的主密鑰泄漏不會(huì)導(dǎo)致過(guò)去的會(huì)話密鑰泄漏。

前向安全能夠保護(hù)過(guò)去進(jìn)行的通訊不受密碼或密鑰在未來(lái)暴露的威脅，如果系統(tǒng)具有前向安全性，就可以保證在主密鑰泄露時(shí)歷史通訊的安全，即使系統(tǒng)遭到主動(dòng)攻擊也是如此。

通俗來(lái)說(shuō)，前向安全指的是密鑰泄漏也不會(huì)讓之前加密的數(shù)據(jù)被泄漏，影響的只有當(dāng)前，對(duì)之前的數(shù)據(jù)無(wú)影響。

前面提到QUIC協(xié)議首次連接時(shí)先后生成了兩個(gè)加密密鑰，由于config被客戶端存儲(chǔ)了，如果期間服務(wù)端私鑰泄漏，那么可以根據(jù)K = mod p計(jì)算出密鑰K。

如果一直使用這個(gè)密鑰進(jìn)行加解密，那么就可以用K解密所有歷史消息，因此后續(xù)又生成了新密鑰，使用其進(jìn)行加解密，當(dāng)時(shí)完成交互時(shí)則銷毀，從而實(shí)現(xiàn)了前向安全。

 

3.5 前向糾錯(cuò)

前向糾錯(cuò)是通信領(lǐng)域的術(shù)語(yǔ)，看下百科的解釋：

前向糾錯(cuò)也叫前向糾錯(cuò)碼Forward Error Correction 簡(jiǎn)稱FEC 是增加數(shù)據(jù)通訊可信度的方法，在單向通訊信道中，一旦錯(cuò)誤被發(fā)現(xiàn)，其接收器將無(wú)權(quán)再請(qǐng)求傳輸。

FEC 是利用數(shù)據(jù)進(jìn)行傳輸冗余信息的方法，當(dāng)傳輸中出現(xiàn)錯(cuò)誤，將允許接收器再建數(shù)據(jù)。

聽(tīng)這段描述就是做校驗(yàn)的，看看QUIC協(xié)議是如何實(shí)現(xiàn)的：

QUIC每發(fā)送一組數(shù)據(jù)就對(duì)這組數(shù)據(jù)進(jìn)行異或運(yùn)算，并將結(jié)果作為一個(gè)FEC包發(fā)送出去，接收方收到這一組數(shù)據(jù)后根據(jù)數(shù)據(jù)包和FEC包即可進(jìn)行校驗(yàn)和糾錯(cuò)。

3.6 連接遷移

網(wǎng)絡(luò)切換幾乎無(wú)時(shí)無(wú)刻不在發(fā)生。

TCP協(xié)議使用五元組來(lái)表示一條唯一的連接，當(dāng)我們從4G環(huán)境切換到wifi環(huán)境時(shí)，手機(jī)的IP地址就會(huì)發(fā)生變化，這時(shí)必須創(chuàng)建新的TCP連接才能繼續(xù)傳輸數(shù)據(jù)。

QUIC協(xié)議基于UDP實(shí)現(xiàn)摒棄了五元組的概念，使用64位的隨機(jī)數(shù)作為連接的ID，并使用該ID表示連接。

基于QUIC協(xié)議之下，我們?cè)谌粘ifi和4G切換時(shí)，或者不同基站之間切換都不會(huì)重連，從而提高業(yè)務(wù)層的體驗(yàn)。

 

4. QUIC的應(yīng)用和前景

通過(guò)前面的一些介紹我們看出來(lái)QUIC協(xié)議雖然是基于UDP來(lái)實(shí)現(xiàn)的，但是它將TCP的重要功能都進(jìn)行了實(shí)現(xiàn)和優(yōu)化，否則使用者是不會(huì)買賬的。

QUIC協(xié)議的核心思想是將TCP協(xié)議在內(nèi)核實(shí)現(xiàn)的諸如可靠傳輸、流量控制、擁塞控制等功能轉(zhuǎn)移到用戶態(tài)來(lái)實(shí)現(xiàn)，同時(shí)在加密傳輸方向的嘗試也推動(dòng)了TLS1.3的發(fā)展。

但是TCP協(xié)議的勢(shì)力過(guò)于強(qiáng)大，很多網(wǎng)絡(luò)設(shè)備甚至對(duì)于UDP數(shù)據(jù)包做了很多不友好的策略，進(jìn)行攔截從而導(dǎo)致成功連接率下降。

主導(dǎo)者谷歌在自家產(chǎn)品做了很多嘗試，國(guó)內(nèi)騰訊公司也做了很多關(guān)于QUIC協(xié)議的嘗試。

其中騰訊云對(duì)QUIC協(xié)議表現(xiàn)了很大的興趣，并做了一些優(yōu)化然后在一些重點(diǎn)產(chǎn)品中對(duì)連接遷移、QUIC成功率、弱網(wǎng)環(huán)境耗時(shí)等進(jìn)行了實(shí)驗(yàn)，給出了來(lái)自生產(chǎn)環(huán)境的諸多寶貴數(shù)據(jù)。

簡(jiǎn)單看一組騰訊云在移動(dòng)互聯(lián)網(wǎng)場(chǎng)景下的不同丟包率下的請(qǐng)求耗時(shí)分布：

 

任何新生事物的推動(dòng)都是需要時(shí)間的，出現(xiàn)多年的HTTP2.0和HTTPS協(xié)議的普及度都沒(méi)有預(yù)想高，IPv6也是如此，不過(guò)QUIC已經(jīng)展現(xiàn)了強(qiáng)大的生命力，讓我們拭目以待吧!

5.本文小結(jié)

網(wǎng)絡(luò)協(xié)議本身就很復(fù)雜，本文只能從整體出發(fā)對(duì)重要的部分做粗淺的闡述，如果對(duì)某個(gè)點(diǎn)很感興趣，可以查閱相關(guān)代碼和RFC文檔。

我們之前可能遇到過(guò)這個(gè)面試題：

如何用UDP協(xié)議來(lái)實(shí)現(xiàn)TCP協(xié)議的主要功能。

我確實(shí)筆試遇到過(guò)這道題，可以說(shuō)很抓狂，題目太宏大了。

不過(guò)現(xiàn)在看看QUIC協(xié)議就回答了這個(gè)問(wèn)題：基于UDP主體將TCP的重要功能轉(zhuǎn)移到用戶空間來(lái)實(shí)現(xiàn)，從而繞開(kāi)內(nèi)核實(shí)現(xiàn)用戶態(tài)的TCP協(xié)議，但是真正實(shí)現(xiàn)起來(lái)還是非常復(fù)雜的。