天天看點

QUIC的那些事 | QUIC為什麼那麼快

QUIC(Quick UDP Internet Connection)是谷歌提出的一種基于UDP的低延遲時間的網際網路傳輸層協定,QUIC的發音類似于Quick。實際上,QUIC确實很快。

QUIC解決了現代網站應用的一系列的傳輸層及應用層的問題,但隻需要應用開發者幾乎不用做出或者隻做出很小的改變。QUIC和TCP+TLS+HTTP很類似,但是基于UDP實作,基于QUIC實作的HTTP協定被提議為HTTP3。

0RTT 建立連接配接可以說是 QUIC 相比 HTTP2 最大的性能優勢。0RTT是指傳輸層0RTT建立連接配接(QUIC基于UDP,不需要三次握手)及加密層0RTT建立加密連接配接(注意是對于大多數連接配接,不是所有連接配接)。

QUIC可以不用等服務端的回包就直接下發封包,而一般的TCP+TLS連接配接在連接配接建立前需要等1-3個RTT。

TCP+TLS互動

三次握手的時間是1RTT(用戶端發送ACK後,就可以直接下發封包),流程圖如圖 1 所示 

QUIC的那些事 | QUIC為什麼那麼快

圖 1 三次握手RTT

TLS1.2(TLS1.1、TLS1.0逐漸被淘汰,暫且略過)的握手流程如圖 2 所示,需要2RTT(從client_hello到虛線之間)。

QUIC的那些事 | QUIC為什麼那麼快

圖 2 TLS1.2握手流程

為了減少TLS1.2的握手時間, TLS1.2中引入了會話緩存機制,其流程圖如圖 3所示,握手流程為3次互動,粗略看時1.5RTT,但是對于用戶端在完成最後一次向服務端發送change_cipher_spec消息後可以立刻下發封包,是以是1RTT(上下兩條虛線之間部分)。

QUIC的那些事 | QUIC為什麼那麼快

圖 3 TLS1.2會話緩存機制下的握手流程        

TCP+TLS1.2的互動流程如圖 4所示,一共需要3RTT後才可以進行應用層的資料互動(SYN到Application Data之間部分)。

QUIC的那些事 | QUIC為什麼那麼快

圖 4 TCP+TLS1.2流程

對于圖 4,引入TLS1.2的會話緩存機制後,也需要2RTT。

TLS1.3(2018年8月釋出)的互動流程如圖 5所示,需要1RTT,TCP+TLS1.3的時間就是2RTT。

QUIC的那些事 | QUIC為什麼那麼快

圖 5 TLS1.3互動流程

TLS1.3會話恢複時的流程如圖6所示,需要0RTT,此時TCP+TLS1.3的時間是1RTT。

QUIC的那些事 | QUIC為什麼那麼快

圖 6 TLS1.3會話恢複流程圖

QUIC互動

QUIC的流程如圖7所示

QUIC的那些事 | QUIC為什麼那麼快

 圖 7 QUIC握手流程

QUIC在握手過程中使用Diffie-Hellman算法協商初始密鑰,初始密鑰依賴于伺服器存儲的一組配置參數,該參數會周期性的更新。初始密鑰協商成功後,伺服器會提供一個臨時随機數,雙方根據這個數再生成會話密鑰。

具體握手過程如下

(1) 用戶端判斷本地是否已有伺服器的全部配置參數,如果有則直接跳轉到(5),否則繼續

(2) 用戶端向伺服器發送inchoate client hello(CHLO)消息,請求伺服器傳輸配置參數

(3) 伺服器收到CHLO,回複rejection(REJ)消息,其中包含伺服器的部配置設定置參數

(4) 用戶端收到REJ,提取并存儲伺服器配置參數,跳回到(1)

(5) 用戶端向伺服器發送full client hello消息,開始正式握手,消息中包括用戶端選擇的公開數。此時用戶端根據擷取的伺服器配置參數和自己選擇的公開數,可以計算出初始密鑰。

(6) 伺服器收到full client hello,如果不同意連接配接就回複REJ,同(3);如果同意連接配接,根據用戶端的公開數計算出初始密鑰,回複server hello(SHLO)消息,SHLO用初始密鑰加密,并且其中包含伺服器選擇的一個臨時公開數。

(7) 用戶端收到伺服器的回複,如果是REJ則情況同(4);如果是SHLO,則嘗試用初始密鑰解密,提取出臨時公開數

(8) 用戶端和伺服器根據臨時公開數和初始密鑰,各自基于SHA-256算法推導出會話密鑰

(9) 雙方更換為使用會話密鑰通信,初始密鑰此時已無用,QUIC握手過程完畢。之後會話密鑰更新的流程與以上過程類似,隻是資料包中的某些字段略有不同。

對于圖 7可以進行如下分解:

1. 用戶端沒有緩存服務端的配置參數,此時流程如圖 8所示

QUIC的那些事 | QUIC為什麼那麼快

圖 8 用戶端沒有緩存服務端配置參數流程

此時的最短時間是1RTT,為什麼說是最短想時間?因為服務端發送其配置參數可能需要多次互動才能完成。

2. 用戶端緩存服務端的配置參數,此時流程如圖9所示

QUIC的那些事 | QUIC為什麼那麼快

圖 9用戶端緩存服務端配置參數流程

QUIC時間分析

如果要取得0RTT的時間,用戶端需要緩存已經驗證的服務端配置資訊,即使緩存了服務端的配置資訊,也可能在于伺服器的互動過程中,需要更新配置資訊,此時的時間就會大于0RTT。如果用戶端和服務端是第一次互動,那麼必須發送CHLO信令,擷取服務端配置,而這個過程就可能耗費多個RTT,因為服務端一次不一定願意向未驗證身份的用戶端一次發送大量的配置資訊。

在用戶端儲存的服務端的配置資訊有效且足夠的情況下,QUIC握手能夠取得0RTT的時間,這就是QUIC快的原因。

參考資料

1. https://www.cnblogs.com/huanxiyun/articles/6554085.html

2. https://www.cnblogs.com/syfwhu/p/5219814.html

3. QUIC Crypto

4. https://www.cnblogs.com/mod109/p/7372577.html

QUIC的那些事 | QUIC為什麼那麼快

掃描二維碼,關注“清遠的夢呓”公衆号,在手機端檢視文章

繼續閱讀