介紹QUIC的背景與使用情形

快速UDP網路連結(Quick UDP Internet Connection,QUIC)在2021年5月於網際網路工程工作小組(IETF)的 RFC 9000  中標準化。然而QUIC並不完全是一個最近才出現的協定,最初是在2012 年由 Google所開發與部署的網路協議,且該協議的初始公開版本在 2013 年 8 月發布的 Chromium 29版本中已出現。QUIC 是一種以使用者封包通訊協定(User Datagram Protocol,UDP)來取代傳輸控制通訊協定(Transmission Control Protocol,TCP),並不是從根本上改變流控制過程(flow control procedures),而是通過改變傳輸功能在終端主機內實現的位置,從而改變可控制該功能的對象。

目前IP的TCP協議已經實現操作系統功能,應用程式通過一個介面與TCP交換,如此一來該介面實現開/關和讀/寫的基本I/O功能。資料流程完整性和流程控制的細節基本上對應用程式是隱藏的,此得應用程序變為簡單,但這種簡單也伴隨著一些問題。

在基於 Web 的服務方面TCP 有其問題,如今,大多數網頁都不是簡單的一項整體,通常包含許多單獨的物件,包括圖像、自定義框架、樣式表等,每一個物件都是單獨的,如果使用的是原始的HTTP瀏覽器,則每個物件都將在新的 TCP 會話中讀取,即使是從相同的 IP 位址所提供的服務。因此為組合 Web 資源中對每個不同 Web 物件設置新的 TCP 會話和新的傳輸層安全性協定 (Transport Layer Security,TLS) 標頭,所需資源成本可能變得相當大,重新利用已建立的 TLS 會話,藉由同一服務器多次提取資料的作法幾乎是壓倒的誘人。

在已發起的單一TCP會話中使用多工傳輸(multiplexing)傳輸數據的方法會產生問題。跨單獨會話進行多工傳輸多重邏輯資料,可能會造成串流處理器之間相互依賴,並造成多路數據流隊頭阻塞(head of line blocking)延遲,整列的封包會阻塞在同一TCP會話中。使用多工傳輸來傳輸多重邏輯資料,能達到端到端傳輸,在安全和控制速率方面是有意義,但TCP實現的方式卻不理想。如果想透過在網路協定中引入平行行為達到一致性,藉此提高效率,就必須超越目前TCP的處理方式。

不過,有些應用程式或服務平台雖然希望改變TCP傳輸方式,但考量成本和收益的問題後就會卻步。對於這些需要轉換傳輸方式的平台來說,這樣大費周章的變動沒有吸引力。

如果能直接透過應用程式控制傳輸服務,就可以直接看到成果。用戶資料包協定(User Datagram Protocol,UDP)這時就發揮了作用,UDP是一種夾層(shim)協定,將應用程式資料放在IP封包傳送出去,實現端到端傳輸,搭配本身擁有的酬載並加載資料擁塞控制結合為UDP酬載。如此,應用程式就完全控制了傳輸協定,並且可以根據需要,自定義傳輸協定的行為,不需等待第三方。

QUIC摘要

QUIC是端到端傳輸協定的實現,使用UDP協定作為基礎(圖一),結合TCP的可靠性和控制功能,將其與TLS的會話加密功能相結合,增加了多重串流更彈性的版本,還增加了對位址的敏捷性支援,以承受多種網路位址轉換(Network Address Translation,NAT)行為。

圖 1 – HTTP 架構中TCP和QUIC的比較

未來將持續探討「認識QUIC」系列,本系列共五篇。(1/5)

相關連結:

Geoff Huston(2022). A look at QUIC use. APNIC.

檢自:

https://blog.apnic.net/2022/07/11/a-look-at-quic-use/ (Aug. 08, 2022)

Leave a Comment

發佈留言必須填寫的電子郵件地址不會公開。

回到頂端