網(wǎng)絡資訊：QUIC 是什么

今天來說一下QUIC 是什么這方面的一些訊息，不少朋友對QUIC 是什么這方面的一些訊息頗感興趣的，小編今天就整理了一些信息，希望對有需要的朋友有所幫助。

QUIC(快速 UDP 網(wǎng)絡連接)是一種實驗性的網(wǎng)絡傳輸協(xié)議，位于 OSI 模型的傳輸層。由 Google 開發(fā)，在 2013 年實現(xiàn)。QUIC 使用 UDP 協(xié)議，它在兩個端點間創(chuàng)建連線，且支持多路復用連線。

QUIC(快速 UDP 網(wǎng)絡連接，Quick UDP Internet Connections)是一種實驗性的網(wǎng)絡傳輸協(xié)議，位于 OSI 模型的傳輸層。由 Google 開發(fā)，在 2013 年實現(xiàn)。QUIC 使用 UDP 協(xié)議，它在兩個端點間創(chuàng)建連線，且支持多路復用連線。

在設計之初，QUIC 希望能夠提供等同于 SSL/TLS 層級的網(wǎng)絡安全保護，減少數(shù)據(jù)傳輸及創(chuàng)建連線時的延遲時間，雙向控制帶寬，以避免網(wǎng)絡擁塞。Google 希望使用這個協(xié)議來取代 TCP 協(xié)議，使網(wǎng)頁傳輸速度加快，計劃將 QUIC 提交至互聯(lián)網(wǎng)工程任務小組(IETF)，讓它成為下一代的正式網(wǎng)絡規(guī)范。

2015 年 6 月，QUIC 的網(wǎng)絡草案被正式提交至互聯(lián)網(wǎng)工程任務組。

2018 年 10 月，互聯(lián)網(wǎng)工程任務組 HTTP 及 QUIC 工作小組正式將基于 QUIC 協(xié)議的 HTTP (英語：HTTP over QUIC) 重命名為 HTTP/3 以為確立下一代規(guī)范做準備。

介紹

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

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

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

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

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

QUIC 在應用程序空間中實現(xiàn)，而不是在操作系統(tǒng)內(nèi)核中實現(xiàn)。當數(shù)據(jù)在應用程序之間移動時，這通常會由于上下文切換而調(diào)用額外的開銷。 但是在 QUIC 下協(xié)議棧旨在由單個應用程序使用，每個應用程序使用 QUIC 在 UDP 上托管自己的連接。最終差異可能非常小，因為整個 HTTP/2 堆棧的大部分已經(jīng)存在于應用程序(或更常見的庫)中。 將剩余部分放在這些庫中，基本上是糾錯，對 HTTP/2 堆棧的大小或整體復雜性幾乎沒有影響。

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

關(guān)于從 TCP 遷移到 UDP 的一個問題是 TCP 被廣泛采用，并且互聯(lián)網(wǎng)基礎(chǔ)設施中的許多中間設備被調(diào)整為 UDP 速率限制甚至阻止 UDP。 Google 進行了一些探索性實驗來描述這一點，發(fā)現(xiàn)只有少數(shù)連接存在此問題。所以 Chromium 的網(wǎng)絡堆棧同時打開 QUIC 和傳統(tǒng) TCP 連接，并在 QUIC 連接失敗時以零延遲回退到 TCP 連接。

gGUIC 與 iQUIC

由 Google 創(chuàng)建并以 QUIC 的名稱提交給 IETF 的協(xié)議與隨后在 IETF 中創(chuàng)建的 QUIC 完全不同(盡管名稱相同)。 最初的 Google QUIC(也稱為 gQUIC)嚴格來說是通過加密 UDP 發(fā)送 HTTP/2 幀的協(xié)議，而 IETF 創(chuàng)建的 QUIC 是通用傳輸協(xié)議，也就是說 HTTP 以外的其他協(xié)議(如 SMTP、DNS、SSH、Telnet、NTP)也可以使用它。重要的是要注意并記住其差異。 自 2012 年以來，Google 在其服務及 Chrome 中使用的 QUIC 版本(直到 2019 年 2 月)為 Google QUIC。隨著時間的推移，它正在逐漸變得類似于 IETF QUIC(也稱為 iQUIC)。

以上就是關(guān)于QUIC 是什么對比這方面的一些信息了 小編整理的這些訊息希望對童鞋們有所幫助。