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

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

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

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

在設(shè)計(jì)之初，QUIC 希望能夠提供等同于 SSL/TLS 層級(jí)的網(wǎng)絡(luò)安全保護(hù)，減少數(shù)據(jù)傳輸及創(chuàng)建連線時(shí)的延遲時(shí)間，雙向控制帶寬，以避免網(wǎng)絡(luò)擁塞。Google 希望使用這個(gè)協(xié)議來(lái)取代 TCP 協(xié)議，使網(wǎng)頁(yè)傳輸速度加快，計(jì)劃將 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 (英語(yǔ)：HTTP over QUIC) 重命名為 HTTP/3 以為確立下一代規(guī)范做準(zhǔn)備。

介紹

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

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

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

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

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

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

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

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

gGUIC 與 iQUIC

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

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