圖解：為什么HTTP3.0使用UDP協(xié)議？

1. 大白和小黑

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

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

這不，小黑聽說了個(gè)新鮮玩意，然后和大白聊了起來：

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

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

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

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

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

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

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

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

• HTTP2.0和TCP存在的一些問題

• QUIC協(xié)議為什么選擇UDP

• QUIC協(xié)議的重要特性

• HTTP3.0和QUIC協(xié)議的前景和應(yīng)用效果
  

2.HTTP2.0和HTTP3.0

科技永不止步。

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

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

3.2 0RTT 建鏈

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

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

一般來說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)單來說，基于TCP協(xié)議和TLS協(xié)議的HTTP2.0在真正發(fā)送數(shù)據(jù)包之前需要花費(fèi)一些時(shí)間來完成握手和加密協(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算法開辟了密鑰交換的新思路，在之前的文章中提到的RSA算法也是基于這種思想實(shí)現(xiàn)的，但是DH算法和RSA的密鑰交換不完全一樣，感興趣的讀者可以看看DH算法的數(shù)學(xué)原理。

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

1. 客戶端對(duì)于首次連接的服務(wù)端先發(fā)送client hello請(qǐng)求。

2. 服務(wù)端生成一個(gè)素?cái)?shù)p和一個(gè)整數(shù)g，同時(shí)生成一個(gè)隨機(jī)數(shù) (筆誤-此處應(yīng)該是Ks_pri)為私鑰，然后計(jì)算出公鑰 = mod p，服務(wù)端將 ，p，g三個(gè)元素打包稱為config，后續(xù)發(fā)送給客戶端。

3. 客戶端隨機(jī)生成一個(gè)自己的私鑰 ，再從config中讀取g和p，計(jì)算客戶端公鑰 = mod p。

4. 客戶端使用自己的私鑰 和服務(wù)端發(fā)來的config中讀取的服務(wù)端公鑰 ，生成后續(xù)數(shù)據(jù)加密用的密鑰K = mod p。

5. 客戶端使用密鑰K加密業(yè)務(wù)數(shù)據(jù)，并追加自己的公鑰 ，都傳遞給服務(wù)端。

6. 服務(wù)端根據(jù)自己的私鑰 和客戶端公鑰 生成客戶端加密用的密鑰K = mod p。

7. 為了保證數(shù)據(jù)安全，上述生成的密鑰K只會(huì)生成使用1次，后續(xù)服務(wù)端會(huì)按照相同的規(guī)則生成一套全新的公鑰和私鑰，并使用這組公私鑰生成新的密鑰M。

8. 服務(wù)端將新公鑰和新密鑰M加密的數(shù)據(jù)發(fā)給客戶端，客戶端根據(jù)新的服務(wù)端公鑰和自己原來的私鑰計(jì)算出本次的密鑰M，進(jìn)行解密。

9. 之后的客戶端和服務(wù)端數(shù)據(jù)交互都使用密鑰M來完成，密鑰K只使用1次。

3.4 前向安全問題

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

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

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

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

前面提到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)了前向安全。

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

通過前面的一些介紹我們看出來QUIC協(xié)議雖然是基于UDP來實(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)來實(shí)現(xiàn)，同時(shí)在加密傳輸方向的嘗試也推動(dòng)了TLS1.3的發(fā)展。

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

主導(dǎo)者谷歌在自家產(chǎn)品做了很多嘗試，國內(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)，給出了來自生產(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é)議的普及度都沒有預(yù)想高，IPv6也是如此，不過QUIC已經(jīng)展現(xiàn)了強(qiáng)大的生命力，讓我們拭目以待吧！

5.本文小結(jié)

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

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

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

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

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

技術(shù)進(jìn)步也非朝夕之功，需要在實(shí)踐中反復(fù)錘煉。

最后感謝各位的傾情安排，歡迎文末積極討論哦！