• <menu id="sssag"></menu>
  • <menu id="sssag"></menu>
  • QUIC協議詳解

    聲明

    本文可以自由轉載但需注明原始鏈接。本文為本人原創,作者LightningStar,原文發表在博客園。本文主體內容參考論文[1]完成。

    介紹

    QUIC,發音同quick,是"Quick UDP Internet Connections"的簡稱,是一種通用的傳輸層網絡協議。QUIC與TCP相同,是一種有連接的傳輸協議。但是與TCP不同的是QUIC是建立在UDP傳輸層協議之上的,實現了在兩個端點之間的多路復用。QUIC的是在用戶空間實現的,TCP/UDP則是在內核空間實現的。[2]

    QUIC所處的網絡層次如下圖所示。圖源文獻[1:1]。

    image_204

    優勢

    Quic 相比現在廣泛應用的 http2+tcp+tls 協議有如下優勢:
    1、減少了 TCP 三次握手及 TLS 握手時間。
    2、改進的擁塞控制。
    3、避免隊頭阻塞的多路復用。
    4、連接遷移。
    5、前向安全。

    建立連接(握手)

    QUIC實現了快速握手,并把握手過程分為兩種情況,分別是1-RTT和0-RTT。在介紹這兩種握手過程之前,讀者需自行熟悉Diffie-Hellman算法的基本原理[3]。

    image_202

    在上圖(文獻[1:2])中顯示了三種不同情況的連接過程。其中最左邊的圖表示的是第一次連接時的情況,中間的圖表示重復連接的情況(在一定條件下,客戶端可以重新連接服務器而不需要從初始化情況連接),最右邊的圖則是重連失敗之后從初始話連接的情況。最后一種情況是第一種情況的組會,0-RTT也是1-RTT的一部分,后文中將重點介紹1-RTT的連接過程。

    1-RTT

    QUIC_1_RTT

    第一次握手

    • 客戶端主動向服務器發送Inchoate CHLO報文
    • 服務器會向客戶端發送REJ報文。REJ報文包含了服務器的配置信息,如長期的Diffie-Hellman值,服務器配置的簽名,source-address-token(stk, 用于驗證的加密塊,包含有服務器看到的客戶端的IP地址和服務器當前的時間戳,之后客戶端會將該stk發回)等,為了進行身份證明還會使用私鑰進行簽名,同時也可以防篡改;
    • 在收到服務器的配置信息后,客戶端會通過證書鏈機制驗簽,并實現對服務器的身份認證。

    第二次握手

    • 客戶端在通過對服務器的驗證之后,客戶端會生成一個Diffie-Hellman值。此時客戶端有了自身和對方的Diffie-Hellman值,就可以計算出初始密鑰(initial key, ik);
    • 客戶端將包含有DH公開之的明文Complete CHLO發送至服務器;
    • 客戶端使用ik對請求數據加密,發送至服務器;
    • 服務器收到Complete CHLO之后就可以獲得客戶端的Diffie-Hellman的值,就可以計算出初始密鑰。
    • 服務器立即向客戶端發送SHLO報文(ik加密的)。SHLO報文含有一個服務器臨時Diffie-Hellman值,可以用于計算前向安全的密鑰(會話密鑰);
    • 服務器收到加密的請求數據,使用初始密鑰進行解密;
    • 服務器使用會話密鑰對響應數據進行加密,發回給客戶端。
    • 客戶端在收到SHLO之后使用初始密鑰解密得到服務器的臨時DH公開值,根據該臨時值計算出會話密鑰;
    • 客戶端收到加密的響應數據后,使用會話密鑰進行解密。

    整個握手過程會在2個RTT內完成。

    0-RTT

    客戶端在重連同一個服務器時,會使用已經緩存的服務器相關配置信息(stk,DH公開值等信息),并直接向服務器發送Complete CHLO報文,并使用ik對請求報文進行加密。但是服務器方面會標識相應的stk等信息已經過期,這時服務器會發送REJ信息,客戶端需要重新與服務器進行連接。

    如果沒有過期的話,就可以直接建立連接,省下了重新建立連接的開銷。

    前向安全性

    所謂前向安全性就是指,在最后一次握手時,會生成一個會話密鑰sk。這樣即使服務器的長期DH值被破獲,且生成了初始密鑰ik,也無法對會話中的數據進行解密。

    多路復用機制

    基于TCP的應用程序會在TCP單字節流抽象層中實現多路復用。為了避免由于TCP順序傳遞導致的頭部阻塞(head-of-line blocking)[4],QUIC支持在單個UDP連接中復用多個流,并保證UDP報文的丟失僅影響相應的流,而不會影響其他的流(stream)。

    可以在QUIC流上構建任意大小的應用程序報文,最多支持\(2^{64}\)的字節。并且stream的實現是輕量級的,即使消息報文很小也可以為它們使用單獨的流。每一個Stream都有stream ID唯一標識。這些流ID由客戶端/服務器進行靜態分配??蛻舳酥鲃影l起的流的ID永遠是奇數,服務器發起的流的ID是偶數。這樣可以避免沖突。當在一個未使用過的流上發送數據時,流會自動創建;當需要關閉時,就會在最后一幀數據上設置一個FIN的標志指示接收方關閉流。如果發送方或接收方確定不再需要流上的數據,則可以取消流,而無需斷開整個 QUIC 連接。盡管流是可靠的抽象,但 QUIC 不會為已取消的流重新傳輸數據。

    一個QUIC包是由一個公共的頭后面跟著一個或多個幀組成的,如下圖(圖源[1:3])所示。QUIC流復用是通過將流數據封裝在一個或多個流幀中來實現的,單個QUIC包可以攜帶來自多個流的流幀.

    image_205

    報文丟失重傳

    TCP 序列號有助于提高可靠性,并表示在接收方傳送字節的順序。這種混淆會導致“重傳模糊”(retransmission ambiguity)問題,因為重傳的 TCP 段攜帶與原始數據包相同的序列號 。 TCP ACK 的接收者無法確定 ACK 是為原始傳輸還是為重傳而發送,并且通常通過昂貴的超時來檢測重傳段的丟失。每個 QUIC 數據包都攜帶一個新的數據包編號,包括那些攜帶重傳數據的數據包。這種設計不需要單獨的機制來區分重傳的 ACK 和原始傳輸的 ACK,從而避免了 TCP 的重傳模糊問題。流幀中的流偏移用于傳遞排序,數據包編號表示一個明確的時間順序,這使得丟失檢測比 TCP 更簡單、更準確。

    QUIC的ACK顯示地記錄了接收的數據報文和ACK之間的延遲。單調增加的報文編號一起,可以精確估算RTT,有助于丟失檢測。QUIC的確認報文支持多達256個ACK,這是使得QUIC比帶有SACK的TCP更能適應重新排序或丟失的情況下在線路上保留更多字節。

    更多內容參見[5]。

    流量控制(Flow Control)

    當應用程序從QUIC的接收緩沖區中讀取數據較慢時,留戀控制就會限制接收者必須保持的接收緩沖區大小。一個緩慢耗盡的stream會逐漸耗盡整個連接connection的緩沖區,因此必須要限制QUIC連接上的每個流可以消耗的緩沖區大小,避免消耗其他流的緩沖區的大小。這樣可以改善流之間潛在的隊頭阻塞(head-of-line blocking)。因此QUIC采用連接級別的流量控制(connection-level flow control),這樣可以限制發送者在所有流中接收者使用的聚合緩沖區;采用流級別的流量控制(stream-level flow control)可以限制發送者在任何給定流上使用的緩沖區。

    與HTTP/2類似,QUIC采用基于信用的流量控制。QUIC接收器在每個流中通告接收器愿意接收數據的絕對字節偏移量。在特定流上發送、接收和傳遞數據時,接收器會定期發送窗口更新幀,以增加該流的窗口偏移限制,從而允許對等方在該流上發送更多數據。連接級流量控制的工作方式與流級流量控制相同,但傳遞的字節數和接收到的最高偏移量是所有流的。

    擁塞控制(Congestion Control)

    QUIC支持的擁塞控制算法有:
    Reno(TCP用的)、基于Pacing的擁塞控制算法(PBCCA)、TCP CUBIC等。

    連接遷移

    QUIC連接使用隨機生成的64bit的cid唯一確定。cid允許客戶機在網絡之間漫游,而不受網絡或傳輸層參數變化的影響。

    cid使得客戶端能夠獨立于網絡地址轉換(network address translation, NAT)之外。cid 在路由中起著重要作用,特別是用于連接標識的目的。此外,使用 cids 可以通過探測連接的新路徑實現多路徑。

    在連接遷移期間,端點假設對等方愿意在其當前地址接受數據包。因此,端點可以遷移到新的 IP 地址,而無需首先驗證對等方的 IP 地址。新的路由路徑可能不支持端點的當前發送速率。在這種情況下,端點需要重新構建它的擁塞控制器。另一方面,從一個新的對等地址接收非探測包 ,確認對等地址已遷移到新的 IP 地址。

    實現參考

    • Google Quic Project[6]

    拓展閱讀

    參考文獻


    1. LANGLEY A, RIDDOCH A, WILK A, 等. The QUIC Transport Protocol: Design and Internet-Scale Deployment[C/OL]//Proceedings of the Conference of the ACM Special Interest Group on Data Communication. Los Angeles CA USA: ACM, 2017: 183-196[2022-03-05]. https://dl.acm.org/doi/10.1145/3098822.3098842. DOI:10.1145/3098822.3098842. ?? ?? ?? ??

    2. QUIC wikipedia ??

    3. 應用密碼學 | Diffie-Hellman密鑰交換算法 ??

    4. 關于隊頭阻塞(Head-of-Line blocking),看這一篇就足夠了 ??

    5. J. Iyengar and I. Swett. 2016. QUIC Loss Detection and Congestion Control.IETF Internet Draft, draft-ietf-quic-recovery ??

    6. QUIC Crypto ??

    7. KUMAR P, DEZFOULI B. Implementation and analysis of QUIC for MQTT[J/OL]. Computer Networks, 2019, 150: 28-45. DOI:10.1016/j.comnet.2018.12.012. ??

    posted @ 2022-03-07 19:44  LightningStar  閱讀(155)  評論(0編輯  收藏  舉報
    国产在线码观看超清无码视频,人妻精品动漫H无码,十大看黄台高清视频,国产在线无码视频一区二区三区,国产男女乱婬真视频免费,免费看女人的隐私超爽,狠狠色狠狠色综合久久蜜芽