text: QUIC的首字母縮寫，但IETF指定的標準中QUIC並不是任何內容的縮寫。QUIC提高了目前使用TCP的面向連線的網路應用的效能。它透過使用使用者資料報協議在兩個端點之間建立若干個多路連線來實現這一目標，其目的是為了在網路層淘汰TCP，以滿足許多應用的需求，因此該協議偶爾也會獲得 “TCP/2”的暱稱。QUIC與HTTP/2的多路複用連線協同工作，允許多個數據流獨立到達所有端點，因此不受涉及其他資料流的丟包影響。相反，HTTP/2建立在傳輸控制協議上，如果任何一個TCP資料包延遲或丟失，所有多路資料流都會遭受隊頭阻塞延遲。QUIC的次要目標包括降低連線和傳輸時延，以及每個方向的頻寬估計以避免擁塞。它還將擁塞控制演算法移到了兩個端點的使用者空間，而不是核心空間，據稱這將使這些演算法得到更快的改進。此外，該協議還可以擴充套件前向糾錯，以進一步提高預期錯誤時的效能，這被視為協議演進的下一步。2015年6月，QUIC規範的提交給IETF進行標準化。2016年，成立了QUIC工作組。2018年10月，IETF的HTTP工作組和QUIC工作組共同決定將QUIC上的HTTP對映稱為 "HTTP/3"，以提前使其成為全球標準。2021年5月IETF公佈RFC9000，QUIC規範推出了標準化版本。背景.傳輸控制協議 (TCP) 旨在為兩個端點之間傳送資料流提供一個介面。資料交給TCP系統，TCP系統確保資料以完全相同的形式傳到另一端，否則連線將提示存在錯誤。為此，TCP將資料分解成網路封包，並在每個資料包中新增少量資料。這些附加資料包括一個序列號，用於檢測丟失或到達順序不正確的資料包，以及一個校驗和，可以檢測資料包資料內的錯誤。當其中任何一個問題發生時，TCP使用自動重傳請求告訴傳送方重新發送丟失或損壞的資料包。在大多數實現中，TCP會將連線上的任何錯誤視為阻塞，停止進一步傳輸，直到錯誤得到解決或連線被視為失敗。如果使用單個連線來發送多個數據流，就像在HTTP/2協議中那樣，所有這些資料流都會被阻止，儘管其中只有一個可能有問題。例如，如果在下載用於收藏夾圖示的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仍然有效。QUIC在中實現，而不是在作業系統核心中實現。當資料在應用程式之間移動時，這通常會由於上下文切換而呼叫額外的開銷。但是在QUIC下協議棧旨在由單個應用程式使用，每個應用程式使用QUIC在UDP上託管自己的連線。最終差異可能非常小，因為整個HTTP/2堆疊的大部分已經存在於應用程式中。將剩餘部分放在這些庫中，基本上是糾錯，對HTTP/2堆疊的大小或整體複雜性幾乎沒有影響。QUIC允許更容易地進行未來更改，因為它不需要更改核心就可以進行更新。QUIC的長期目標之一是新增前向糾錯和改進的擁塞控制。關於從TCP遷移到UDP的一個問題是TCP被廣泛採用，並且網際網路基礎設施中的許多中間裝置被調整為UDP速率限制甚至阻止UDP。Google進行了一些探索性實驗來描述這一點，發現只有少數連線存在此問題。所以Chromium的網路堆疊同時開啟QUIC和傳統TCP連線，並在QUIC連線失敗時以零延遲迴退到TCP連線。gQUIC與iQUIC.由Google建立並以QUIC的名稱提交給IETF的協議與隨後在IETF中建立的QUIC完全不同。最初的Google QUIC也可以使用它。重要的是要注意並記住其差異。自2012年以來，Google在其服務及Chrome中使用的QUIC版本。流量控制.與大多數傳輸協議一樣，QUIC 具有流量控制以保護接收端免受緩衝區overflow的影響。QUIC 是基於 UDP 傳輸，而 UDP 沒有流量控制，因此 QUIC 實現了自己的流量控制機制。與TCP不同，QUIC並非透過ACK回應目前接收到第幾筆資料，而是透過control frame實現類似於 HTTP/2 的基於信用的方案。實現.客戶端.Google Chrome於2012年開始開發QUIC協議並且於Chromium版本 29釋出。QUIC協議在當前Chrome版本中被預設開啟，活躍的會話列表在codice_1中可見。服務端.截至2017年，有三種活躍維護中的實現。谷歌的伺服器及谷歌釋出的原型伺服器 及 LiteSpeed 伺服器中支援QUIC。截止 17 年 12 月， 97.5%的使用 QUIC 協議的網站在 LiteSpeed 伺服器中執行。另有幾種不再維護的社群產品，基於Chromium實現並且減少使用依賴的libquic 。2020年12月，支援DNS-over-QUIC協議的公共DNS解析器，由AdGuard首次公開推出服務。
metadata.dataset: erhwenkuo/wikipedia-zhtw
metadata.title: QUIC
metadata.url: https://zh.wikipedia.org/wiki?curid=4719598