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

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

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

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

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

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

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

介紹

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

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

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

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

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

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

QUIC 允許更容易地進(jìn)行未來更改，因?yàn)樗恍枰膬?nèi)核就可以進(jìn)行更新。 QUIC 的長期目標(biāo)之一是添加前向糾錯和改進(jìn)的擁塞控制。

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

gGUIC 與 iQUIC

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

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