QUIC

一种计算机网络传输层协议

QUIC(讀作「quick」)是一個通用[1]傳輸層[2]網絡協議,最初由GoogleJim Roskind設計[3]。該協議於2012年實現並部署[4],2013年隨着實驗範圍的擴大而公開發布[5][6][7],並向IETF描述[8]。雖然長期處於互聯網草案英語Internet Draft階段,但從Chrome瀏覽器至Google服務器的連接中超過一半的連接都使用了QUIC[9]Microsoft Edge[10]Firefox[11]都已支持此協議;Safari[12]實現了QUIC,但默認情況下沒有啟用。QUIC於RFC9000中被正式標準化[13]

QUIC最初是「快速UDP互聯網連接」(Quick UDP Internet Connection)的首字母縮寫[3][8],但在IETF標準中,QUIC不是任何內容的縮寫[1]。QUIC提高了目前使用TCP的面向連接的網絡應用的性能[2][9]。QUIC通過UDP協議在兩個端點之間建立若干個多路連接,以達到在網絡層淘汰TCP的目標。因為其設計目標在於取代TCP協議,該協議偶爾也被暱稱為「TCP/2」[14]

QUIC與HTTP/2的多路復用連接協同工作,允許多個數據流獨立到達所有端點,因此不受涉及其他數據流的丟包影響。與之相比,HTTP/2建立在傳輸控制協議(TCP)上,如果任何一個TCP數據包延遲或丟失,所有多路數據流都會遭受隊頭阻塞延遲。

QUIC的次要目標包括降低連接和傳輸時延,以及每個方向的帶寬估計以避免擁塞。它還將擁塞控制算法移到了兩個端點的使用者空間,而不是內核空間,據稱這將使這些算法得到更快的改進。此外,該協議還可以擴展前向糾錯(FEC),以進一步提高預期錯誤時的性能,這被視為協議演進的下一步。

2015年6月,QUIC規範的互聯網草案英語Internet Draft提交給IETF進行標準化[15][16]。2016年,成立了QUIC工作組[17]。2018年10月,IETF的HTTP工作組和QUIC工作組共同決定將QUIC上的HTTP映射稱為 "HTTP/3",以提前使其成為全球標準[18]。2021年5月IETF公布RFC9000,QUIC規範推出了標準化版本[13]

背景

傳輸控制協議 (TCP) 旨在為兩個端點之間發送數據流提供一個接口。數據交給TCP系統,TCP系統確保數據以完全相同的形式傳到另一端,否則連接將提示存在錯誤[19]

為此,TCP將數據分解成網路封包,並在每個數據包中添加少量數據。這些附加數據包括一個序列號,用於檢測丟失或到達順序不正確的數據包,以及一個校驗和,可以檢測數據包數據內的錯誤。當其中任何一個問題發生時,TCP使用自動重傳請求(ARQ)告訴發送方重新發送丟失或損壞的數據包[19]

在大多數實現中,TCP會將連接上的任何錯誤視為阻塞,停止進一步傳輸,直到錯誤得到解決或連接被視為失敗。如果使用單個連接來發送多個數據流,就像在HTTP/2協議中那樣,所有這些數據流都會被阻止,儘管其中只有一個可能有問題。例如,如果在下載用於收藏夾圖標的GIF圖像時出現一個錯誤,頁面的其餘部分將等待問題得到解決[19]

由於TCP系統被設計成類似「數據管道」或流,TCP刻意被設計成並不知曉其傳輸的數據之細節。如果對傳輸的數據存在額外需求,如需要使用TLS加密,那麼此類協議必須建立在TCP的上層。每種協議都需要自己的握手過程,結果會導致在建立連接前需要大量交換數據,加之長距離通信的固有延遲,從而給整個傳輸過程增加大量開銷[19]

介紹

 
QUIC與帶有TLS1.2的TCP握手比較

QUIC旨在提供幾乎等同於TCP連接的可靠性,但延遲大大減少。它主要通過兩個理解HTTP流量的行為來實現這一點[19]

第一個變化是在連接建立期間大大減少開銷英語Overhead (computing)。由於大多數HTTP連接都需要TLS,因此QUIC使協商密鑰和支持的協議成為初始握手過程的一部分。 當客戶端打開連接時,服務器響應的數據包包括將來的數據包加密所需的數據。這消除了TCP上的先連接並通過附加數據包協商安全協議的需要。其他協議可以以相同的方式進行服務,並將多個步驟組合到一個請求中。 然後,這些數據既可用於初始設置中的後續請求,也可用於未來的請求。[19]

QUIC使用UDP協議作為其基礎,不包括丟失恢復。相反,每個QUIC流是單獨控制的,並且在QUIC級別而不是UDP級別重傳丟失的數據。這意味着如果在一個流中發生錯誤,協議棧仍然可以獨立地繼續為其他流提供服務。 這在提高易出錯鏈路的性能方面非常有用,因為在大多數情況下TCP協議通知數據包丟失或損壞之前可能會收到大量的正常數據,但是在糾正錯誤之前其他的正常請求都會等待甚至重發。 QUIC在修復單個流時可以自由處理其他數據,也就是說即使一個請求發生了錯誤也不會影響到其他的請求。[20]

QUIC包括許多其他更普通的更改,這些更改也可以優化整體延遲和吞吐量。例如,每個數據包是單獨加密的,因此加密數據時不需要等待部分數據包。 在TCP下通常不可能這樣做,其中加密記錄在字節流中,並且協議棧不知道該流中的更高層邊界。這些可以由運行在更上層的協議進行協商,但QUIC旨在通過單個握手過程完成這些。[8]

QUIC的另一個目標是提高網絡切換期間的性能,例如當移動設備的用戶從WiFi熱點切換到移動網絡時發生的情況。 當這發生在TCP上時,一個冗長的過程開始了:每個現有連接一個接一個地超時英語Timeout (computing),然後根據需要重新建立。期間存在較高延遲,因為新連接需要等待舊連接超時後才會建立。 為解決此問題,QUIC包含一個連接標識符,該標識符唯一地標識客戶端與服務器之間的連接,而無論源IP地址是什麼。這樣只需發送一個包含此ID的數據包即可重新建立連接,因為即使用戶的IP地址發生變化,原始連接ID仍然有效。[21]

 HTTP/1Transport Layer SecurityTransmission Control ProtocolHTTP/2TLS 1.2Transmission Control ProtocolHTTP/3TLS 1.3QUICUser Datagram ProtocolInternet Protocol
HTTP/3與HTTP/1.1和HTTP/2的之間的協議棧比較

QUIC在應用程序空間英語Application domain中實現,而不是在操作系統內核中實現。當數據在應用程序之間移動時,這通常會由於上下文切換而調用額外的開銷。 但是在QUIC下協議棧旨在由單個應用程序使用,每個應用程序使用QUIC在UDP上託管自己的連接。最終差異可能非常小,因為整個HTTP/2堆棧的大部分已經存在於應用程序(或更常見的庫)中。 將剩餘部分放在這些庫中,基本上是糾錯,對HTTP/2堆棧的大小或整體複雜性幾乎沒有影響。[8]

QUIC允許更容易地進行未來更改,因為它不需要更改內核就可以進行更新。 QUIC的長期目標之一是添加前向糾錯和改進的擁塞控制[21]

關於從TCP遷移到UDP的一個問題是TCP被廣泛採用,並且互聯網基礎設施中的許多中間設備被調整為UDP速率限制甚至阻止UDP。 Google進行了一些探索性實驗來描述這一點,發現只有少數連接存在此問題。[3]所以Chromium的網絡堆棧同時打開QUIC和傳統TCP連接,並在QUIC連接失敗時以零延遲回退到TCP連接。[22]

gQUIC與iQUIC

由Google創建並以QUIC的名稱提交給IETF的協議與隨後在IETF中創建的QUIC完全不同(儘管名稱相同)。 最初的Google QUIC(也稱為gQUIC)嚴格來說是通過加密UDP發送HTTP/2幀的協議,而IETF創建的QUIC是通用傳輸協議,也就是說HTTP以外的其他協議(如SMTPDNSSSHTelnetNTP)也可以使用它。重要的是要注意並記住其差異。 自2012年以來,Google在其服務及Chrome中使用的QUIC版本(直到2019年2月)為Google QUIC。隨着時間的推移,它正在逐漸變得類似於IETF QUIC(也稱為iQUIC)。

流量控制

與大多數傳輸協議一樣,QUIC 具有流量控制以保護接收端免受緩衝區overflow的影響。QUIC 是基於 UDP 傳輸,而 UDP 沒有流量控制,因此 QUIC 實現了自己的流量控制機制。與TCP不同,QUIC並非透過ACK回應目前接收到第幾筆資料,而是透過control frame實現類似於 HTTP/2 的基於信用的方案。

實現

客戶端

Google Chrome於2012年開始開發QUIC協議並且於Chromium版本 29(2013年8月20日釋出)發布。QUIC協議在當前Chrome版本中被默認開啟,活躍的會話列表在chrome://net-internals/#quic中可見。

服務端

截至2017年,有三種活躍維護中的實現。谷歌的服務器及谷歌發布的原型服務器頁面存檔備份,存於網際網路檔案館)使用Go語言編寫的quic-go頁面存檔備份,存於網際網路檔案館)及Caddy的試驗性QUIC支持。在2017年7月11日,LiteSpeed科技正式在他們的負載均衡WebADC頁面存檔備份,存於網際網路檔案館))及 LiteSpeed 服務器中支持QUIC。截止 17 年 12 月, 97.5%的使用 QUIC 協議的網站在 LiteSpeed 服務器中運行[23]

另有幾種不再維護的社區產品,基於Chromium實現並且減少使用依賴的libquic頁面存檔備份,存於網際網路檔案館)、提供libquic的Go語言綁定的goquic頁面存檔備份,存於網際網路檔案館)、打包為Docker鏡像的用來轉換為普通HTTP請求的反向代理quic-reverse-proxy頁面存檔備份,存於網際網路檔案館)。

2020年12月,支持DNS-over-QUIC協議的公共DNS解析器,由AdGuard首次公開推出服務[24]

參見

參考資料

  1. ^ 1.0 1.1 QUIC: A UDP-Based Multiplexed and Secure Transport. IETF: sec. 1. I-D draft-ietf-quic-transport-22. 
  2. ^ 2.0 2.1 Nathan Willis. Connecting on the QUIC. Linux Weekly News. [2013-07-16]. (原始內容存檔於2020-10-16). 
  3. ^ 3.0 3.1 3.2 QUIC: Design Document and Specification Rationale. Jim Roskind, Chromium Contributor. [2015-04-29]. (原始內容存檔於2014-11-10). 
  4. ^ First Chromium Code Landing: CL 11125002: Add QuicFramer and friends.. [2012-10-16]. (原始內容存檔於2020-04-13). 
  5. ^ Experimenting with QUIC. Chromium Official Blog. [2013-07-16]. (原始內容存檔於2021-02-05). 
  6. ^ QUIC, Google wants to make the web faster. François Beaufort, Chromium Evangelist. 
  7. ^ QUIC: next generation multiplexed transport over UDP. YouTube. [2014-04-04]. (原始內容存檔於2020-11-18). 
  8. ^ 8.0 8.1 8.2 8.3 QUIC: IETF-88 TSV Area Presentation (PDF). Jim Roskind, Google. [2013-11-07]. (原始內容存檔 (PDF)於2014-02-11). 
  9. ^ 9.0 9.1 Lardinois, Frederic. Google Wants To Speed Up The Web With Its QUIC Protocol. TechCrunch. [2016-10-25]. (原始內容存檔於2020-12-14). 
  10. ^ Christopher Fernandes. Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5. April 3, 2018 [2020-05-08]. (原始內容存檔於2020-11-23). 
  11. ^ How to enable HTTP3 in Chrome / Firefox / Safari. bram.us. April 8, 2020 [2021-02-02]. (原始內容存檔於2021-01-28). 
  12. ^ The state of QUIC and HTTP/3 2020. www.fastly.com. [2020-10-21]. (原始內容存檔於2020-11-13). 
  13. ^ 13.0 13.1 rfc9000. tools.ietf.org. [2021-06-01] (英語). 
  14. ^ Tatsuhiro Tsujikawa. ngtcp2. GitHub. [2020-10-17]. (原始內容存檔於2021-01-22). 
  15. ^ Google Will Propose QUIC As IETF Standard. InfoQ. [2016-10-25]. (原始內容存檔於2020-10-24). 
  16. ^ I-D Action: draft-tsvwg-quic-protocol-00.txt. i-d-announce (郵件列表). 17 Jun 2015 [2018-12-10]. (原始內容存檔於2016-05-26). 
  17. ^ QUIC - IETF Working Group. datatracker.ietf.org. [2016-10-25]. (原始內容存檔於2021-02-05). 
  18. ^ Cimpanu, Catalin. HTTP-over-QUIC to be renamed HTTP/3. ZDNet. 12 November 2018 [2018-12-10]. (原始內容存檔於2018-11-13). 
  19. ^ 19.0 19.1 19.2 19.3 19.4 19.5 Bright, Peter. The next version of HTTP won't be using TCP. Arstechnica. 12 November 2018 [2019-04-10]. (原始內容存檔於2019-04-10). 
  20. ^ Behr, Michael; Swett, Ian. Introducing QUIC support for HTTPS load balancing. Google Cloud Platform Blog. Google. [16 June 2018]. (原始內容存檔於2019-04-10). 
  21. ^ 21.0 21.1 QUIC at 10,000 feet. Chromium. [2019-04-10]. (原始內容存檔於2019-04-10). 
  22. ^ Applicability of the QUIC Transport Protocol. IETF Network Working Group. 22 October 2018 [2019-04-10]. (原始內容存檔於2019-06-07). 
  23. ^ Distribution of Web Servers among websites that use QUIC. w3techs.com. [2018-12-10]. 
  24. ^ Darya Bugayova. AdGuard 成为世界第一个 DNS-over-QUIC 解析器 (html). AdGuard. 2020-12-16 [2020-12-18]. (原始內容存檔於2020-12-17) (中文(中國大陸)). 

外部連結