最近一段時(shí)間以來(lái)，關(guān)于HTTP/3的新聞?dòng)泻芏啵絹?lái)越多的國(guó)際大公司已經(jīng)開始使用HTTP/3了。 

 

所以，HTTP/3已經(jīng)是箭在弦上了，全面使用只是個(gè)時(shí)間問題，那么，作為一線開發(fā)者，我們也是時(shí)候了解下到底什么是HTTP/3，為什么需要HTTP/3了。

那么，本文就來(lái)講解一下到底什么是HTTP/3?他用到了哪些技術(shù)?解決了什么問題?

HTTP/2 存在的問題

在撰寫本文之前，我專門寫了一篇文章《HTTP/2做錯(cuò)了什么?剛剛輝煌2年就要被棄用了?》分析HTTP/2存在的問題以及背后的原因。

這里就不詳細(xì)介紹了，強(qiáng)烈建議大家先閱讀下這篇文章，有助于本文的學(xué)習(xí)。

在上一篇文章中我們提到過HTTP/2因?yàn)榈讓邮褂玫膫鬏攲訁f(xié)議仍然是TCP，所以他存在著TCP隊(duì)頭阻塞、TCP握手延時(shí)長(zhǎng)以及協(xié)議僵化等問題。

這導(dǎo)致HTTP/2雖然使用了多路復(fù)用、二進(jìn)制分幀等技術(shù)，但是仍然存在著優(yōu)化空間。

QUIC協(xié)議

我們知道，HTTP/2之所以"被棄用"，是因?yàn)樗褂玫膫鬏攲訁f(xié)議仍然是TCP，所以HTTP/3首要解決的問題就是繞開TCP。

那么如果研發(fā)一種新的協(xié)議，同樣還是會(huì)因?yàn)槭艿街虚g設(shè)備僵化的影響，導(dǎo)致無(wú)法被大規(guī)模應(yīng)用。所以，研發(fā)人員們想到了一種基于UDP實(shí)現(xiàn)的方式。

于是，Google是最先采用這種方式并付諸于實(shí)踐的，他們?cè)?013年推出了一種叫做QUIC的協(xié)議，全稱是Quick UDP Internet Connections。

從名字中可以看出來(lái)，這是一種完全基于UDP的協(xié)議。

在設(shè)計(jì)之初，Google就希望使用這個(gè)協(xié)議來(lái)取代HTTPS/HTTP協(xié)議，使網(wǎng)頁(yè)傳輸速度加快。2015年6月，QUIC的網(wǎng)絡(luò)草案被正式提交至互聯(lián)網(wǎng)工程任務(wù)組。2018 年 10 月，互聯(lián)網(wǎng)工程任務(wù)組 HTTP 及 QUIC 工作小組正式將基于 QUIC 協(xié)議的 HTTP(英語(yǔ)：HTTP over QUIC)重命名為HTTP/3。

所以，我們現(xiàn)在所提到的HTTP/3，其實(shí)就是HTTP over QUIC，即基于QUIC協(xié)議實(shí)現(xiàn)的HTTP。

那么，想要了解HTTP/3的原理，只需要了解QUIC就可以了。

QUIC協(xié)議有以下特點(diǎn)：

• 基于UDP的傳輸層協(xié)議：它使用UDP端口號(hào)來(lái)識(shí)別指定機(jī)器上的特定服務(wù)器。
• 可靠性：雖然UDP是不可靠傳輸協(xié)議，但是QUIC在UDP的基礎(chǔ)上做了些改造，使得他提供了和TCP類似的可靠性。它提供了數(shù)據(jù)包重傳、擁塞控制、調(diào)整傳輸節(jié)奏以及其他一些TCP中存在的特性。
• 實(shí)現(xiàn)了無(wú)序、并發(fā)字節(jié)流：QUIC的單個(gè)數(shù)據(jù)流可以保證有序交付，但多個(gè)數(shù)據(jù)流之間可能亂序，這意味著單個(gè)數(shù)據(jù)流的傳輸是按序的，但是多個(gè)數(shù)據(jù)流中接收方收到的順序可能與發(fā)送方的發(fā)送順序不同!
• 快速握手：QUIC提供0-RTT和1-RTT的連接建立
• 使用TLS 1.3傳輸層安全協(xié)議：與更早的TLS版本相比，TLS 1.3有著很多優(yōu)點(diǎn)，但使用它的最主要原因是其握手所花費(fèi)的往返次數(shù)更低，從而能降低協(xié)議的延遲。

那么，QUIC到底屬于TCP/IP協(xié)議族中的那一層呢?我們知道，QUIC是基于UDP實(shí)現(xiàn)的，并且是HTTP/3的所依賴的協(xié)議，那么，按照TCP/IP的分層來(lái)講，他是屬于傳輸層的，也就是和TCP、UDP屬于同一層。

如果更加細(xì)化一點(diǎn)的話，因?yàn)镼UIC不僅僅承擔(dān)了傳輸層協(xié)議的職責(zé)，還具備了TLS的安全性相關(guān)能力，所以，可以通過下圖來(lái)理解QUIC在HTTP/3的實(shí)現(xiàn)中所處的位置。 

接下來(lái)我們分別展開分析一下QUIC協(xié)議。先來(lái)看下他是如何建立連接的。

QUIC的連接立

我們知道，TCP這種可靠傳輸協(xié)議需要進(jìn)行三次握手，也正是因?yàn)槿挝帐郑孕枰~外消耗1.5 RTT，而如果再加上TLS的話，則需要消耗3-4個(gè) RTT連接。

那么，QUIC是如何建立連接的呢?如何減少RTT的呢?

QUIC提出一種新的連接建立機(jī)制，基于這種連接接機(jī)制，實(shí)現(xiàn)了快速握手功能，一次QUIC連接建立可以實(shí)現(xiàn)使用 0-RTT 或者 1-RTT 來(lái)建立連接。 

• QUIC在握手過程中使用Diffie-Hellman算法來(lái)保證數(shù)據(jù)交互的安全性并合并了它的加密和握手過程來(lái)減小連接建立過程中的往返次數(shù)。
• Diffie–Hellman (以下簡(jiǎn)稱DH)密鑰交換是一個(gè)特殊的交換密鑰的方法。它是密碼學(xué)領(lǐng)域內(nèi)最早付諸實(shí)踐的密鑰交換方法之一。DH可以讓雙方在完全缺乏對(duì)方(私有)信息的前提條件下通過不安全的信道達(dá)成一個(gè)共享的密鑰。此密鑰用于對(duì)后續(xù)信息交換進(jìn)行對(duì)稱加密。
• QUIC 連接的建立整體流程大致為：QUIC在握手過程中使用Diffie-Hellman算法協(xié)商初始密鑰，初始密鑰依賴于服務(wù)器存儲(chǔ)的一組配置參數(shù)，該參數(shù)會(huì)周期性的更新。初始密鑰協(xié)商成功后，服務(wù)器會(huì)提供一個(gè)臨時(shí)隨機(jī)數(shù)，雙方根據(jù)這個(gè)數(shù)再生成會(huì)話密鑰。客戶端和服務(wù)器會(huì)使用新生的的密鑰進(jìn)行數(shù)據(jù)加解密。

以上過程主要分為兩個(gè)步驟：初始握手(Initial handshake)、最終(與重復(fù))握手(Final (and repeat) handshake)，分別介紹下這兩個(gè)過程。

初始握手(Initial handshake)

在連接開始建立時(shí)，客戶端會(huì)向服務(wù)端發(fā)送一個(gè)打招呼信息，(inchoate client hello (CHLO))，因?yàn)槭浅醮谓ⅲ裕?wù)端會(huì)返回一個(gè)拒絕消息(REJ)，表明握手未建立或者密鑰已過期。 

但是，這個(gè)拒絕消息中還會(huì)包含更多的信息(配置參數(shù))，主要有：

• Server Config：一個(gè)服務(wù)器配置，包括服務(wù)器端的Diffie-Hellman算法的長(zhǎng)期公鑰(long term Diffie-Hellman public value)
• Certificate Chain：用來(lái)對(duì)服務(wù)器進(jìn)行認(rèn)證的信任鏈
• Signature of the Server Config：將Server Config使用信任鏈的葉子證書的public key加密后的簽名
• Source-Address Token：一個(gè)經(jīng)過身份驗(yàn)證的加密塊，包含客戶端公開可見的IP地址和服務(wù)器的時(shí)間戳。

在客戶端接收到拒絕消息(REJ)之后，客戶端會(huì)進(jìn)行數(shù)據(jù)解析，簽名驗(yàn)證等操作，之后會(huì)將必要的配置緩存下來(lái)。

同時(shí)，在接收到REJ之后，客戶端會(huì)為這次連接隨機(jī)產(chǎn)生一對(duì)自己的短期密鑰(ephemeral Diffie-Hellman private value) 和 短期公鑰(ephemeral Diffie-Hellman public value)。

之后，客戶端會(huì)將自己剛剛產(chǎn)生的短期公鑰打包一個(gè)Complete CHLO的消息包中，發(fā)送給服務(wù)端。這個(gè)請(qǐng)求的目的是將自己的短期密鑰傳輸給服務(wù)端，方便做前向保密，后面篇幅會(huì)詳細(xì)介紹。 

在發(fā)送了Complete CHLO消息給到服務(wù)器之后，為了減少RTT，客戶端并不會(huì)等到服務(wù)器的響應(yīng)，而是立刻會(huì)進(jìn)行數(shù)據(jù)傳輸。

為了保證數(shù)據(jù)的安全性，客戶端會(huì)自己的短期密鑰和服務(wù)器返回的長(zhǎng)期公鑰進(jìn)行運(yùn)算，得到一個(gè)初始密鑰(initial keys)。

有了這個(gè)初識(shí)密鑰之后，客戶端就可以用這個(gè)密鑰，將想要傳輸?shù)男畔⑦M(jìn)行加密，然后把他們安全的傳輸給服務(wù)端了。

另外一面，接收到Complete CHLO請(qǐng)求的服務(wù)器，解析請(qǐng)求之后，就同時(shí)擁有了客戶端的短期公鑰和自己保存的長(zhǎng)期密鑰。這樣通過運(yùn)算，服務(wù)端就能得到一份和客戶端一模一樣的初始密鑰(initial keys)。

接下來(lái)他接收到客戶端使用初始密鑰加密的數(shù)據(jù)之后，就可以使用這個(gè)初始密鑰進(jìn)行解密了，并且可以將自己的響應(yīng)再通過這個(gè)初始密鑰進(jìn)行加密后返回給客戶端。

所以，從開始建立連接一直到數(shù)據(jù)傳送，只消耗了初始連接連接建立的 1 RTT

最終(與重復(fù))握手

那么，之后的數(shù)據(jù)傳輸就可以使用初始密鑰(initial keys)加密了嗎?

其實(shí)并不完全是，因?yàn)槌跏济荑€畢竟是基于服務(wù)器的長(zhǎng)期公鑰產(chǎn)生的，而在公鑰失效前，幾乎多有的連接使用的都是同一把公鑰，所以，這其實(shí)存在著一定的危險(xiǎn)性。

所以，為了達(dá)到前向保密 (Forward Secrecy) 的安全性，客戶端和服務(wù)端需要使用彼此的短期公鑰和自己的短期密鑰來(lái)進(jìn)行運(yùn)算。

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

那么現(xiàn)在問題是，客戶端的短期密鑰已經(jīng)發(fā)送給服務(wù)端，而服務(wù)端只把自己的長(zhǎng)期密鑰給了客戶端，并沒有給到自己的短期密鑰。

所以，服務(wù)端在收到Complete CHLO之后，會(huì)給到服務(wù)器一個(gè)server hello(SHLO)消息，這個(gè)消息會(huì)使用初始密鑰(initial keys)進(jìn)行加密。 

這個(gè)CHLO消息包中，會(huì)包含一個(gè)服務(wù)端重新生成的短期公鑰。

這樣客戶端和服務(wù)端就都有了對(duì)方的短期公鑰(ephemeral Diffie-Hellman public value)。

這樣，客戶端和服務(wù)端都可以基于自己的短期密鑰和對(duì)方的短期公鑰做運(yùn)算，產(chǎn)生一個(gè)僅限于本次連接使用的前向保密密鑰 (Forward-Secure Key)，后續(xù)的請(qǐng)求發(fā)送，都基于這個(gè)密鑰進(jìn)行加解密就可以了。

這樣，雙方就完成了最終的密鑰交換、連接的握手并且建立了QUIC連接。

當(dāng)下一次要重新創(chuàng)建連接的時(shí)候，客戶端會(huì)從緩存中取出自己之前緩存下來(lái)的服務(wù)器的長(zhǎng)期公鑰，并重新創(chuàng)建一個(gè)短期密鑰，重新生成一個(gè)初始密鑰，再使用這個(gè)初始密鑰對(duì)想要傳輸?shù)臄?shù)據(jù)進(jìn)行加密，向服務(wù)器發(fā)送一個(gè)Complete CHLO 請(qǐng)求即可。這樣就達(dá)到了0 RTT的數(shù)據(jù)傳輸。

所以，如果是有緩存的長(zhǎng)期公鑰，那么數(shù)據(jù)傳輸就會(huì)直接進(jìn)行，準(zhǔn)備時(shí)間是0 RTT

以上，通過使用Diffie-Hellman算法協(xié)商密鑰，并且對(duì)加密和握手過程進(jìn)行合并，大大減小連接過程的RTT ，使得基于QUIC的連接建立可以少到1 RTT甚至0 RTT。

以下，是Google官網(wǎng)上面的一張關(guān)于QUIC連接建立的流程圖，可以幫助大家理解這個(gè)過程。 

另外，通過以上關(guān)于握手建立的過程，我們也可以知道，QUIC在整個(gè)過程中通過加解密的方式很好的保證了安全性。

多路復(fù)用

基于TCP的協(xié)議實(shí)現(xiàn)的HTTP有一個(gè)最大的問題那就是隊(duì)頭阻塞問題，那么，在這方面，QUIC是如何解決這個(gè)問題的呢?

TCP傳輸過程中會(huì)把數(shù)據(jù)拆分為一個(gè)個(gè)按照順序排列的數(shù)據(jù)包，這些數(shù)據(jù)包通過網(wǎng)絡(luò)傳輸?shù)搅私邮斩耍邮斩嗽侔凑枕樞驅(qū)⑦@些數(shù)據(jù)包組合成原始數(shù)據(jù)，這樣就完成了數(shù)據(jù)傳輸。 

但是如果其中的某一個(gè)數(shù)據(jù)包沒有按照順序到達(dá)，接收端會(huì)一直保持連接等待數(shù)據(jù)包返回，這時(shí)候就會(huì)阻塞后續(xù)請(qǐng)求。這就發(fā)生了TCP隊(duì)頭阻塞。 

類似于HTTP/2，QUIC在同一物理連接上可以有多個(gè)獨(dú)立的邏輯數(shù)據(jù)流，這些數(shù)據(jù)流并行在同一個(gè)連接上傳輸，且多個(gè)數(shù)據(jù)流之間間的傳輸沒有時(shí)序性要求，也不會(huì)互相影響。

數(shù)據(jù)流(Streams)在QUIC中提供了一個(gè)輕量級(jí)、有序的字節(jié)流的抽象化

QUIC的單個(gè)數(shù)據(jù)流可以保證有序交付，但多個(gè)數(shù)據(jù)流之間可能亂序。這意味著單個(gè)數(shù)據(jù)流的傳輸是按序的，但是多個(gè)數(shù)據(jù)流中接收方收到的順序可能與發(fā)送方的發(fā)送順序不同!

也就是說(shuō)同一個(gè)連接上面的多個(gè)數(shù)據(jù)流之間沒有任何依賴(不要求按照順序到達(dá))，即使某一個(gè)數(shù)據(jù)包沒有達(dá)到，也只會(huì)影響自己這個(gè)數(shù)據(jù)流，并不會(huì)影響到到其他的數(shù)據(jù)流。 

連接遷移

對(duì)于TCP連接的識(shí)別，需要通過服務(wù)器和客戶端過雙方的ip和端口四個(gè)參數(shù)進(jìn)行的。在網(wǎng)絡(luò)切換的場(chǎng)景中，比如手機(jī)切換網(wǎng)絡(luò)，那么自身的ip就會(huì)發(fā)生變化。這就導(dǎo)致之前的TCP連接就會(huì)失效，就需要重新建立。

這種場(chǎng)景對(duì)于移動(dòng)端設(shè)備普及的今天來(lái)說(shuō)，還是比較頻繁的。

所以，在這一點(diǎn)上，QUIC進(jìn)行了優(yōu)化。

QUIC協(xié)議使用特有的UUID來(lái)標(biāo)記每一次連接，在網(wǎng)絡(luò)環(huán)境發(fā)生變化的時(shí)候，只要UUID不變，就能不需要握手，繼續(xù)傳輸數(shù)據(jù)。

可靠性

TCP之所以被稱之為可靠鏈接，不僅僅是因?yàn)樗腥挝帐趾退拇侮P(guān)閉的過程，還因?yàn)樗隽撕芏嘀T如流量控制、數(shù)據(jù)重傳、擁塞控制等可靠性保證。

這也是為什么一直以來(lái)都是以TCP作為HTTP實(shí)現(xiàn)的重要協(xié)議的原因。

那么，QUIC想要取代TCP，就需要在這方面也做出努力，畢竟UDP自身是不具備這些能力的。

TCP擁塞控制是TCP避免網(wǎng)絡(luò)擁塞的算法，是互聯(lián)網(wǎng)上主要的一個(gè)擁塞控制措施。經(jīng)典的算法實(shí)現(xiàn)有很多，諸如TCP Tahoe 和 Reno、TCP Vegas、TCP Hybla、TCP New Reno、TCP Westwood和Westwood+以及TCP BIC 和 CUBIC等等。

QUIC協(xié)議同樣實(shí)現(xiàn)了擁塞控制。不依賴于特定的擁塞控制算法，并且提供了一個(gè)可插拔的接口，允許用戶實(shí)驗(yàn)。默認(rèn)使用了 TCP 協(xié)議的 Cubic 擁塞控制算法。

關(guān)于流量控制，QUIC提供了基于stream和connection兩種級(jí)別的流量控制，既需要對(duì)單個(gè) Stream 進(jìn)行控制，又需要針對(duì)所有 Stream 進(jìn)行總體控制。

QUIC的連接級(jí)流控，用以限制 QUIC 接收端愿意分配給連接的總緩沖區(qū)，避免服務(wù)器為某個(gè)客戶端分配任意大的緩存。連接級(jí)流控與流級(jí)流控的過程基本相同，但轉(zhuǎn)發(fā)數(shù)據(jù)和接收數(shù)據(jù)的偏移限制是所有流中的總和。

弊端

以上，我們介紹了很多QUIC的相比較于TCP的優(yōu)點(diǎn)，可以說(shuō)這種協(xié)議相比較于TCP確實(shí)要優(yōu)秀一些。

因?yàn)樗腔赨DP的，并沒有改變UDP協(xié)議本身，只是做了一些增強(qiáng)，雖然可以避開中間設(shè)備僵化的問題，但是，在推廣上面也不是完全沒有問題的。

首先，很多企業(yè)、運(yùn)營(yíng)商和組織對(duì)53端口(DNS)以外的UDP流量會(huì)進(jìn)行攔截或者限流，因?yàn)檫@些流量近來(lái)常被濫用于攻擊。

特別是一些現(xiàn)有的UDP協(xié)議和實(shí)現(xiàn)易受放大攻擊(amplification attack)威脅，攻擊者可以控制無(wú)辜的主機(jī)向受害者投放發(fā)送大量的流量。

所以，基于UDP的QUIC協(xié)議的傳輸可能會(huì)受到屏蔽。

另外，因?yàn)閁DP一直以來(lái)定位都是不可靠連接，所以有很多中間設(shè)備對(duì)于他的支持和優(yōu)化程度并不高，所以，出現(xiàn)丟包的可能性還是比較高的。

總結(jié)

下表是我總結(jié)的HTTP/2和HTTP/3的異同點(diǎn)，有一些本文介紹過，有一些個(gè)人認(rèn)為并不是特別重要的，本文中并沒有提及，大家感興趣的可以自行學(xué)習(xí)下。