天天看點

QUIC協定設計(一)-QUIC的特點前言一、TCP的缺點二、QUIC是什麼總結

文章目錄

  • 前言
  • 一、TCP的缺點
    • 1.名詞解釋
      • 1.1 BDP
      • 1.2 TCP擁塞控制
      • 1.3 AIMD
      • 1.4 RTT
      • 1.5 隊頭阻塞
      • 1.6 TLS
      • 1.7 DTLS
    • 2.缺點說明
      • 2.1 高BDP下的低效
      • 2.2 帶寬配置設定不公平
      • 2.3 高延時
  • 二、QUIC是什麼
    • 1.發展過程
    • 2.協定模型
    • 3.特點
      • 3.1 0-RTT(或1-RTT)建立連接配接
      • 3.2 改進的擁塞控制(解決TCP低效、不公)
      • 3.3 無隊頭阻塞的多路複用(解決TCP高延時)
      • 3.4 連接配接遷移
      • 3.5 支援可靠和不可靠傳輸
      • 3.6 精細的流量控制
  • 總結

前言

随着HTTP3标準的釋出,HTTP3基于的QUIC協定受到越來越多的關注。

一、TCP的缺點

TCP協定是目前計算機網絡通信中最流行的協定之一。但是,随着網絡環境的變化,TCP愈發顯露出一些缺點。

在介紹缺點前,先了解一些名詞。

1.名詞解釋

1.1 BDP

bandwidth-delay product,即帶寬時延積。帶寬時延積 = 傳播時延(s)*帶寬(bit/s) 。

等同在任何特定時間該網絡線路上的最大資料量——已發送但尚未确認的資料。

1.2 TCP擁塞控制

TCP是基于丢包的擁塞控制,發生逾時重傳或者收到3個重複确認,就會觸發擁塞算法,減小擁塞視窗。

最大發送視窗(swnd)=min(遠端剩餘接收視窗rwnd,本地發送視窗swnd,擁塞視窗cwnd) 。

1.3 AIMD

additive increase multiplicative decrease,即和式增加,積式減少,是TCP的擁塞控制算法。

特點是,擁塞視窗的大小增加慢(和式增加),減小很快(積式減少)。

1.4 RTT

Round-Trip Time,即往返時間。

是指從資料完全發送完(完成最後一個bit推送到資料鍊路上),到發送方接收到确認的時間。

1.5 隊頭阻塞

Head-of-Line blocking或HOL blocking。是指第一個資料包(隊頭)受阻而導緻整列資料包傳輸受阻。

參見:http相關的隊頭阻塞有哪些

1.6 TLS

Transport Layer Security,即傳輸層安全協定。

HTTPS中的“s”就是指TLS,它是基于TCP的協定。常見的有TLS1.2、TLS1.3。

1.7 DTLS

Datagram Transport Layer Security,即資料包傳輸層安全協定。

基于TLS擴充,支援UDP協定,DTLS1.0 基于 TLS 1.1,DTLS 1.2 基于 TLS 1.2 。

2.缺點說明

2.1 高BDP下的低效

這個問題是TCP的擁塞控制機制引起的。

在高BDP(帶寬時延積)網絡(如高速廣域網)下,TCP協定發送效率低下。

以前網絡環境差,TCP為了适配低速網絡,設計上偏向于慢慢地控制網絡中的資料流量變大,來防止整個網絡的擁塞。

TCP的擁塞控制算法AIMD會“和式增加,積式減少”,導緻擁塞視窗快速減小後,不能快速增大,最終減少了發送視窗大小,降低了發送速率,浪費了高BDP的網絡資源。

2.2 帶寬配置設定不公平

這個問題仍然是TCP的擁塞控制機制引起的。

TCP帶寬配置設定不均,RTT(往返時間)較小的占用較大的帶寬。因為TCP的每輪RTT後,CWND(擁塞視窗)會增加,是以,RTT較小的,CWND就大,發送視窗也相應變大。

2.3 高延時

TCP的高延時主要是由隊頭阻塞引起的。

基于TCP的HTTP協定,有更多的隊頭阻塞問題,參見名詞解釋中的“1.5 隊頭阻塞”。

二、QUIC是什麼

1.發展過程

QUIC發展過程如圖所示:

QUIC協定設計(一)-QUIC的特點前言一、TCP的缺點二、QUIC是什麼總結

重點是分為了2個分支:gQUIC和iQUIC,

兩者的差別主要在于安全傳輸層的差異,gQUIC使用了自定義安全機制,iQUIC使用了TLS協定。

下面的介紹,都是特指iQUIC。

2.協定模型

協定模型如下圖所示:

QUIC協定設計(一)-QUIC的特點前言一、TCP的缺點二、QUIC是什麼總結

QUIC基于UDP協定,

一對用戶端和服務端可以有多個連接配接Connection,

每個連接配接Connection都有各自的Connection ID,

一個Connection中包含多個stream流,

stream有各自的stream ID。

3.特點

QUIC是由Google首先提出的基于UDP的傳輸協定,

它是一個安全通用的應用層協定,它面向連接配接,在用戶端及服務端之間建立有狀态的互動。有如下特點:

3.1 0-RTT(或1-RTT)建立連接配接

QUIC基于TLS1.3建立連接配接,實作了0-RTT(1-RTT),

而TCP+TLS1.2建立連接配接需要3.5RTT。

3.2 改進的擁塞控制(解決TCP低效、不公)

QUIC預設使用Cubic擁塞控制算法,并支援換算法。

單調遞增的封包号解決了TCP重傳歧義,算法中的RTT度量更準确。

3.3 無隊頭阻塞的多路複用(解決TCP高延時)

QUIC為單個連接配接提供了可複用的多stream(流),

stream本身各自保證有序性,stream之間不存在依賴關系,

解決了單個TCP連接配接由于嚴格按序傳遞引發的隊頭阻塞。

3.4 連接配接遷移

QUIC用Connection ID代替了TCP的五元組辨別一個連接配接,

變更IP(切換網絡、NAT重綁等)時可以使用Connection ID避免重建立立連接配接。

3.5 支援可靠和不可靠傳輸

QUIC的可靠傳輸使用stream幀,

在擴充協定中(RFC9221),

還支援了不可靠傳輸的DATAGRAM幀。

3.6 精細的流量控制

流量控制是指,接收方需要限制流量以防發送方速度太快造成沖擊或被惡意發送方消耗大量記憶體。

QUIC在stream和connection這2個層次都支援類似TCP的流量控制。

總結

這一章初步認識了QUIC協定,下一章介紹QUIC握手的巧妙設計。

繼續閱讀