QUIC（讀作 ）是一個通用的傳輸層網路協議，最初由 Google 的 Jim Roskind 設計。該協議於 2012 年實現並部署，2013 年隨著實驗範圍的擴大而公開發布，並向 IETF 描述。雖然長期處於階段，但從 Chrome 瀏覽器至 Google 伺服器的連線中超過一半的連線都使用了 QUIC。Microsoft Edge、Firefox 都已支援此協議；Safari 實現了 QUIC，但預設情況下沒有啟用。QUIC 於 RFC9000 中被正式標準化。 QUIC 最初是 快速 UDP 網際網路連線的首字母縮寫，但在 IETF 標準中，QUIC 不是任何內容的縮寫。QUIC 提高了目前使用 TCP 的面向連線的網路應用的效能。QUIC 透過 UDP 協議在兩個端點之間建立若干個多路連線，以達到在網路層淘汰 TCP 的目標。因為其設計目標在於取代 TCP 協議，該協議偶爾也被暱稱為 TCP2。 QUIC 與 HTTP2 的多路複用連線協同工作，允許多個數據流獨立到達所有端點，因此不受涉及其他資料流的丟包影響。與之相比，HTTP2 建立在傳輸控制協議（TCP）上，如果任何一個 TCP 資料包延遲或丟失，所有多路資料流都會遭受隊頭阻塞延遲。 QUIC 的次要目標包括降低連線和傳輸時延，以及每個方向的頻寬估計以避免擁塞。它還將擁塞控制演算法移到了兩個端點的使用者空間，而不是核心空間，據稱這將使這些演算法得到更快的改進。此外，該協議還可以擴充套件前向糾錯（FEC），以進一步提高預期錯誤時的效能，這被視為協議演進的下一步。 2015 年 6 月，QUIC 規範的提交給 IETF 進行標準化。2016 年，成立了 QUIC 工作組。2018 年 10 月，IETF 的 HTTP 工作組和 QUIC 工作組共同決定將 QUIC 上的 HTTP 對映稱為 HTTP3，以提前使其成為全球標準。2021 年 5 月 IETF 公佈 RFC9000，QUIC 規範推出了標準化版本。 背景 傳輸控制協議 TCP 旨在為兩個端點之間傳送資料流提供一個介面。資料交給 TCP 系統，TCP 系統確保資料以完全相同的形式傳到另一端，否則連線將提示存在錯誤。 為此，TCP 將資料分解成網路封包，並在每個資料包中新增少量資料。這些附加資料包括一個序列號，用於檢測丟失或到達順序不正確的資料包，以及一個校驗和，可以檢測資料包資料內的錯誤。當其中任何一個問題發生時，TCP 使用自動重傳請求（ARQ）告訴傳送方重新發送丟失或損壞的資料包。 在大多數實現中，TCP 會將連線上的任何錯誤視為阻塞，停止進一步傳輸，直到錯誤得到解決或連線被視為失敗。如果使用單個連線來發送多個數據流，就像在 HTTP2 協議中那樣，所有這些資料流都會被阻止，儘管其中只有一個可能有問題。例如，如果在下載用於收藏夾圖示的 GIF 影像時出現一個錯誤，頁面的其餘部分將等待問題得到解決。 由於 TCP 系統被設計成類似 資料管道 或流，TCP 刻意被設計成並不知曉其傳輸的資料之細節。如果對傳輸的資料存在額外需求，如需要使用 TLS 加密，那麼此類協議必須建立在 TCP 的上層。每種協議都需要自己的握手過程，結果會導致在建立連線前需要大量交換資料，加之長距離通訊的固有延遲，從而給整個傳輸過程增加大量開銷。 介紹 QUIC 旨在提供幾乎等同於 TCP 連線的可靠性，但延遲大大減少。它主要透過兩個理解 HTTP 流量的行為來實現這一點。 第一個變化是在連線建立期間大大減少。由於大多數 HTTP 連線都需要 TLS，因此 QUIC 使協商金鑰和支援的協議成為初始握手過程的一部分。 當客戶端開啟連線時，伺服器響應的資料包包括將來的資料包加密所需的資料。這消除了 TCP 上的先連線並透過附加資料包協商安全協議的需要。其他協議可以以相同的方式進行服務，並將多個步驟組合到一個請求中。 然後，這些資料既可用於初始設定中的後續請求，也可用於未來的請求。 QUIC 使用 UDP 協議作為其基礎，不包括丟失恢復。相反，每個 QUIC 流是單獨控制的，並且在 QUIC 級別而不是 UDP 級別重傳丟失的資料。這意味著如果在一個流中發生錯誤，協議棧仍然可以獨立地繼續為其他流提供服務。 這在提高易出錯鏈路的效能方面非常有用，因為在大多數情況下 TCP 協議通知資料包丟失或損壞之前可能會收到大量的正常資料，但是在糾正錯誤之前其他的正常請求都會等待甚至重發。 QUIC 在修復單個流時可以自由處理其他資料，也就是說即使一個請求發生了錯誤也不會影響到其他的請求。 QUIC 包括許多其他更普通的更改，這些更改也可以最佳化整體延遲和吞吐量。例如，每個資料包是單獨加密的，因此加密資料時不需要等待部分資料包。 在 TCP 下通常不可能這樣做，其中加密記錄在位元組流中，並且協議棧不知道該流中的更高層邊界。這些可以由執行在更上層的協議進行協商，但 QUIC 旨在透過單個握手過程完成這些。 QUIC 的另一個目標是提高網路切換期間的效能，例如當移動裝置的使用者從 WiFi 熱點切換到行動網路時發生的情況。 當這發生在 TCP 上時，一個冗長的過程開始了：每個現有連線一個接一個地，然後根據需要重新建立。期間存在較高延遲，因為新連線需要等待舊連線超時後才會建立。 為解決此問題，QUIC 包含一個連線識別符號，該識別符號唯一地標識客戶端與伺服器之間的連線，而無論源 IP 地址是什麼。這樣只需傳送一個包含此 ID 的資料包即可重新建立連線，因為即使使用者的 IP 地址發生變化，原始連線 ID 仍然有效。 FileHTTP11 vs HTTP2 vs HTTP3 Protocol StacksvgframeHTTP3 與 HTTP11 和 HTTP2 的之間的協議棧比較 rect 0 44 85 94 HTTP1 rect 0 95 85 137 Transport Layer Security rect 0 138 85 189 Transmission Control Protocol rect 126 44 210 94 HTTP2 rect 126 95 210 137 TLS 12 rect 126 138 210 189 Transmission Control Protocol rect 251 44 336 74 HTTP3 rect 255 90 328 121 TLS 13 rect 251 125 336 158 QUIC rect 251 159 336 189 User Datagram Protocol rect 0 189 336 231 Internet Protocol QUIC 在中實現，而不是在作業系統核心中實現。當資料在應用程式之間移動時，這通常會由於上下文切換而呼叫額外的開銷。 但是在 QUIC 下協議棧旨在由單個應用程式使用，每個應用程式使用 QUIC 在 UDP 上託管自己的連線。最終差異可能非常小，因為整個 HTTP2 堆疊的大部分已經存在於應用程式（或更常見的庫）中。 將剩餘部分放在這些庫中，基本上是糾錯，對 HTTP2 堆疊的大小或整體複雜性幾乎沒有影響。 QUIC 允許更容易地進行未來更改，因為它不需要更改核心就可以進行更新。 QUIC 的長期目標之一是新增前向糾錯和改進的擁塞控制。 關於從 TCP 遷移到 UDP 的一個問題是 TCP 被廣泛採用，並且網際網路基礎設施中的許多中間裝置被調整為 UDP 速率限制甚至阻止 UDP。 Google 進行了一些探索性實驗來描述這一點，發現只有少數連線存在此問題。所以 Chromium 的網路堆疊同時開啟 QUIC 和傳統 TCP 連線，並在 QUIC 連線失敗時以零延遲迴退到 TCP 連線。 gQUIC 與 iQUIC 由 Google 建立並以 QUIC 的名稱提交給 IETF 的協議與隨後在 IETF 中建立的 QUIC 完全不同（儘管名稱相同）。 最初的 Google QUIC（也稱為 gQUIC）嚴格來說是透過加密 UDP 傳送 HTTP2 幀的協議，而 IETF 建立的 QUIC 是通用傳輸協議，也就是說 HTTP 以外的其他協議（如 SMTP、DNS、SSH、Telnet、NTP）也可以使用它。重要的是要注意並記住其差異。 自 2012 年以來，Google 在其服務及 Chrome 中使用的 QUIC 版本（直到 2019 年 2 月）為 Google QUIC。隨著時間的推移，它正在逐漸變得類似於 IETF QUIC（也稱為 iQUIC）。 流量控制 與大多數傳輸協議一樣，QUIC 具有流量控制以保護接收端免受緩衝區 overflow 的影響。QUIC 是基於 UDP 傳輸，而 UDP 沒有流量控制，因此 QUIC 實現了自己的流量控制機制。與 TCP 不同，QUIC 並非透過 ACK 回應目前接收到第幾筆資料，而是透過 control frame 實現類似於 HTTP2 的基於信用的方案。 實現 客戶端 Google Chrome 於 2012 年開始開發 QUIC 協議並且於 Chromium 版本 29（2013 年 8 月 20 日釋出）釋出。QUIC 協議在當前 Chrome 版本中被預設開啟，活躍的會話列表在 chromenetinternalsquic 中可見。 服務端 截至 2017 年，有三種活躍維護中的實現。谷歌的伺服器及谷歌釋出的原型伺服器 使用 Go 語言編寫的 quicgo 及 Caddy 的試驗性 QUIC 支援。在 2017 年 7 月 11 日，LiteSpeed 科技正式在他們的負載均衡（WebADC ）及 LiteSpeed 伺服器中支援 QUIC。截止 17 年 12 月， 975 的使用 QUIC 協議的網站在 LiteSpeed 伺服器中執行。 另有幾種不再維護的社群產品，基於 Chromium 實現並且減少使用依賴的 libquic 、提供 libquic 的 Go 語言繫結的 goquic 、打包為 Docker 映象的用來轉換為普通 HTTP 請求的反向代理 quicreverseproxy 。 2020 年 12 月，支援 DNSoverQUIC 協議的公共 DNS 解析器，由 AdGuard 首次公開推出服務。 參見 HTTP3 HTTP2 SPDY zhtw 串流控制傳輸協定；zhcn 流控制傳輸協議； UDT TLS DTLS 三方交握 參考資料 外部連結 Chromium QUIC a multiplexed stream transport over UDP QUIC Design Document and Specification Rationale Jim Roskinds original document 20122013 Daniel Stenberg HTTP3 explained Linux Weekly News Connecting on the QUIC 2013 QUIC IETF88 TSV Area Presentation 20131107 Chromium Blog Experimenting with QUIC 2013 QUIC next generation multiplexed transport over UDP Google Developers 2014 HTTP over UDP an Experimental Investigation of QUIC Multipath QUIC extension to QUIC Innovating Transport with QUIC Design Approaches and Research Challenges 2017 Category 傳輸層協議 Category 網際協議 CategoryGoogle 軟體