在過去幾年中，QUIC已經(jīng)成為谷歌服務(wù)網(wǎng)絡(luò)通信的默認(rèn)協(xié)議。正如這里所說的，QUIC現(xiàn)在被從Chrome瀏覽器到谷歌服務(wù)器的所有連接中的一半以上使用。它還得到了Microsoft Edge、Firefox和Opera的官方支持。
谷歌開發(fā)它時(shí)考慮到了網(wǎng)絡(luò)安全，并用更先進(jìn)和最新的技術(shù)取代了一些過時(shí)的標(biāo)準(zhǔn)。換句話說，QUIC可能代表著互聯(lián)網(wǎng)的未來，這就是為什么理解它如此重要。
因此，讓我們深入了解谷歌的QUIC協(xié)議，并介紹您需要了解的一切。
QUIC的歷史
QUIC最初代表“快速UDP Internet連接”，盡管該術(shù)語不再用作首字母縮略詞?，F(xiàn)在，“QUIC”被用來描述谷歌設(shè)計(jì)的通用傳輸層網(wǎng)絡(luò)協(xié)議。 2012年，最初開始實(shí)施和部署。 2013年，在IETF會(huì)議上，隨著實(shí)驗(yàn)范圍的擴(kuò)大，它被公開宣布。 2015年6月，針對(duì)其規(guī)范的互聯(lián)網(wǎng)草案提交給IETF進(jìn)行標(biāo)準(zhǔn)化。 2016年，QUIC工作組成立。 2018年10月，QUIC上的HTTP映射開始被稱為“HTTP/3”，使QUIC必然成為全球標(biāo)準(zhǔn)。 2021 5月，IETF最終在RFC 9000中對(duì)其進(jìn)行了標(biāo)準(zhǔn)化。
什么是QUIC？
谷歌的QUIC是一種基于UDP的低延遲互聯(lián)網(wǎng)傳輸協(xié)議，該協(xié)議通常用于游戲、流媒體和VoIP服務(wù)。 UDP比TCP輕得多，但反過來，它的糾錯(cuò)服務(wù)比TCP少得多。 通過QUIC，谷歌的目標(biāo)是將UDP和TCP的一些最佳功能與現(xiàn)代安全工具相結(jié)合。-谷歌希望通過其QUIC協(xié)議加速網(wǎng)絡(luò)
首先我們先來看看http協(xié)議，再帶入到tcp，udp，quic，逐步探索。
HTTP 1：
我們從HTTP/1.0開始，其中每個(gè)請(qǐng)求-響應(yīng)對(duì)前面都是打開一個(gè)tcp連接，然后關(guān)閉同一個(gè)連接。這引入了大量延遲，并導(dǎo)致人們想出了一個(gè)名為keep-alive的解決方案，該解決方案在HTTP請(qǐng)求之間重用TCP連接，基本上延遲了連接的關(guān)閉。下面是有和沒有keep alive的兩個(gè)圖表。
此示例還演示了在發(fā)出HTTP請(qǐng)求之前需要建立的TCP 3路握手。基本上，雙方都使用序列號(hào)（SYN數(shù)據(jù)包）跟蹤他們發(fā)送的內(nèi)容。這樣，如果他們丟失了任何數(shù)據(jù)包，就可以從最后一個(gè)序列號(hào)重新發(fā)送。請(qǐng)注意，作為每個(gè)連接建立的一部分，需要進(jìn)行3路握手（SYN、SYN-ACK、ACK）。由于TCP是雙向通信模式，因此需要在每個(gè)方向上發(fā)送ACK。FIN用于關(guān)閉TCP連接。
顯而易見借助Keep-alive是一個(gè)很好的手段來保持連接。
仔細(xì)看，每個(gè)資源請(qǐng)求仍然需要在激發(fā)之前完成其先前的資源請(qǐng)求。例如，我不能發(fā)出索引請(qǐng)求。css在索引之前。html已返回。
嗯。他們是怎么解決的？
他們?cè)贖TTP/1.1中引入了一個(gè)名為pipeline流水線的特性。通過該特性，可以立即通過TCP連接發(fā)出每個(gè)HTTP請(qǐng)求，而無需等待前一個(gè)請(qǐng)求的響應(yīng)返回。該圖顯示了HTTP/1.1.和pipeline。
相關(guān)視頻推薦
通過10道經(jīng)典網(wǎng)絡(luò)面試題，搞懂tcp/ip協(xié)議棧所有知識(shí)點(diǎn)
100行代碼實(shí)現(xiàn)tcp/ip協(xié)議棧，自行準(zhǔn)備好Linux系統(tǒng)
C++網(wǎng)絡(luò)面試題：TCP/UDP應(yīng)用場(chǎng)景分析，UDP如何實(shí)現(xiàn)可靠性設(shè)計(jì)
需要C/C++ Linux服務(wù)器架構(gòu)師學(xué)習(xí)資料加qun812855908獲取（資料包括C/C++，Linux，golang技術(shù)，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，ffmpeg等），免費(fèi)分享
報(bào)文的回復(fù)將以相同的順序返回。這引入了一個(gè)稱為HTTP線路頭（HOL）阻塞的問題
什么是HOL？
假設(shè)您正在請(qǐng)求一個(gè)貓的圖像和一個(gè)javascript文件。如果貓的圖像太大，服務(wù)器在完成發(fā)送圖像之前不會(huì)開始發(fā)送javascript文件。
是不是聽起來很可怕，那么如何解決這一問題？
最初的方法是讓瀏覽器打開最多6個(gè)到同一服務(wù)器的連接，作為性能優(yōu)化，開發(fā)人員開始在多個(gè)域之間共享資源，以支持服務(wù)器上超過6個(gè)資源的情況。此外，這并沒有解決為每個(gè)單獨(dú)的連接設(shè)置TCP（和TLS）握手的開銷。在第2部分之前，我不會(huì)討論TLS。
這也引入了一些創(chuàng)新，如css ，減少了要通過網(wǎng)絡(luò)傳輸?shù)膯蝹€(gè)資源的數(shù)量。
很快人們意識(shí)到這是不可擴(kuò)展的，于是引入了一種新的方法，即HTTP/2和多路復(fù)用。
本質(zhì)上，它聲明TCP連接上的每個(gè)HTTP請(qǐng)求都可以立即發(fā)出，而無需等待上一個(gè)響應(yīng)返回。響應(yīng)可以按任何順序返回。下圖再次說明了使用流的HTTP/1.1流水線和HTTP/2復(fù)用。注意在HTTP/2中使用多路復(fù)用流的視圖。css在cat.png之前返回
此外，與HTTP/1.1不同，在HTTP/1.1中，作為HTTP頭的一部分的資源標(biāo)識(shí)僅在一組tcp包的第一個(gè)tcp包中，在HTTP/2中，每個(gè)tcp包都包含資源的標(biāo)識(shí)。這使得被拆分為多個(gè)TCP數(shù)據(jù)包的HTTP響應(yīng)可以很容易地重新組合，消除了HTTP/1.1的串行性
是的，看起來我們已經(jīng)最大限度地改進(jìn)了HTTP/2多路復(fù)用
不完全是這樣，這里還有一個(gè)缺陷，但您必須更深入地研究TCP堆棧。
噢，現(xiàn)在有什么缺陷？
TCP是一種面向連接的協(xié)議。它會(huì)跟蹤客戶端和服務(wù)器之間傳輸?shù)乃袛?shù)據(jù)包，如果數(shù)據(jù)包在從服務(wù)器傳輸過程中丟失，它會(huì)將所有數(shù)據(jù)包保存在該數(shù)據(jù)包的序列號(hào)之后，直到丟失的數(shù)據(jù)包被重新發(fā)送，才將其傳遞給應(yīng)用層。這里有一個(gè)圖表來說明這一點(diǎn)。
例如，在圖中，如果數(shù)據(jù)包2來自視圖。css丟失時(shí)，它會(huì)導(dǎo)致所有從3到20的數(shù)據(jù)包存儲(chǔ)在接收緩沖區(qū)中，直到數(shù)據(jù)包2被重新發(fā)送后才傳遞到應(yīng)用程序堆棧。盡管所有的包裹都來自貓。png將被接收，但底層TCP協(xié)議無法知道這一點(diǎn)，因此它強(qiáng)制重傳。
（注意：這個(gè)圖不是一個(gè)非常準(zhǔn)確的表示，因?yàn)槲乙呀?jīng)從HTTP響應(yīng)切換到了TCP響應(yīng)來說明這個(gè)問題）。
如果你仔細(xì)觀察它，潛在的問題是因?yàn)門CP的面向連接的本質(zhì)。例如，如果TCP知道數(shù)據(jù)包1和數(shù)據(jù)包2是view.css的一部分，則只會(huì)導(dǎo)致數(shù)據(jù)包2重新傳輸，而不會(huì)阻止數(shù)據(jù)包3–20。標(biāo)識(shí)HTTP/2層中底層多路復(fù)用流的流ID與底層TCP數(shù)據(jù)包ID斷開連接。
QUIC與TCP
與TCP不同，QUIC協(xié)議只允許以加密形式進(jìn)行通信。由于QUIC中未加密的通信形式被設(shè)計(jì)為禁止，因此隱私和安全是QUIC數(shù)據(jù)傳輸?shù)墓逃胁糠?。在網(wǎng)絡(luò)安全方面，這無疑是一個(gè)優(yōu)勢(shì)，但在不嚴(yán)格要求加密的情況下，這也可能是一個(gè)無用的開銷。
但與TCP+TLS相比，QUIC建立安全連接所需的時(shí)間代表了真正的突破。換句話說，QUIC的主要目標(biāo)是大大減少連接設(shè)置期間的開銷。
這得益于QUIC的設(shè)計(jì)。事實(shí)上，QUIC使交換配置密鑰和支持的協(xié)議成為初始握手過程的一部分更快。具體而言，當(dāng)發(fā)送方打開連接時(shí)，響應(yīng)包還包括使用加密所需的未來數(shù)據(jù)包所需的數(shù)據(jù)。這一步驟不需要建立TCP連接，然后通過其他數(shù)據(jù)包協(xié)商安全協(xié)議。這會(huì)導(dǎo)致更高的連接速度和顯著的響應(yīng)降低，甚至在主機(jī)間重新連接期間降低到0ms，這被稱為“零RTT連接建立”。
正如您所看到的，典型的安全TCP連接需要兩到三次往返，發(fā)送方才能真正開始接收數(shù)據(jù)。這可能需要300毫秒。而通過使用QUIC，發(fā)送者可以立即開始與之前已經(jīng)交互過的接收者進(jìn)行交互。
與UDP相比，QUIC是贏家，因?yàn)樗哂蠻DP所不具備的擁塞控制和自動(dòng)重傳等TCP功能。這使得它本質(zhì)上比純UDP更可靠。詳細(xì)地說，雖然QUIC使用UDP作為基礎(chǔ)，但它涉及丟失恢復(fù)。這是因?yàn)镼UIC的行為類似于TCP，它分別檢查每個(gè)流，并在數(shù)據(jù)丟失時(shí)重新傳輸數(shù)據(jù)。
此外，如果一個(gè)流中發(fā)生錯(cuò)誤，QUIC可以繼續(xù)獨(dú)立地為其他流提供服務(wù)。這一特性對(duì)于提高易出錯(cuò)鏈路的性能非常有用，因?yàn)樵赥CP注意到丟失或丟失的數(shù)據(jù)包之前，可能會(huì)收到大量額外的數(shù)據(jù)。在QUIC中，在修復(fù)流時(shí)，可以自由處理這些數(shù)據(jù)。
QUIC還提高了網(wǎng)絡(luò)切換事件期間的性能，例如當(dāng)移動(dòng)設(shè)備用戶從Wi-Fi網(wǎng)絡(luò)移動(dòng)到移動(dòng)網(wǎng)絡(luò)時(shí)。當(dāng)在TCP上發(fā)生同樣的事情時(shí)，將執(zhí)行一個(gè)長(zhǎng)過程，其中每個(gè)現(xiàn)有連接一次斷開一個(gè)，然后按需重新建立。為了解決這個(gè)問題及其在性能方面的后果，QUIC包括到接收器的連接ID，而不考慮源。這允許簡(jiǎn)單地通過重新發(fā)送單個(gè)數(shù)據(jù)包來重新建立連接，該數(shù)據(jù)包始終包含該ID，即使發(fā)送方的IP地址發(fā)生了更改，接收方也會(huì)認(rèn)為該ID有效。
那么，這是否足以讓QUIC取代TCP？
我知道一種叫做UDP的替代方案，它是無連接的。
但我們?nèi)匀恍枰?lián)系，不是嗎？我們?nèi)绾卧跊]有連接的情況下以可靠的方式請(qǐng)求資源（重新傳輸、確認(rèn)、排序和整個(gè)沙邦）。我們需要一種方法來識(shí)別跨多個(gè)TCP數(shù)據(jù)包的資源。
如果我們刪除TCP并使用IP上的流協(xié)議并將其與HTTP分層，該怎么辦？該協(xié)議將像以前一樣保持單個(gè)連接，但流將有自己的重傳。實(shí)際上，每個(gè)流在一個(gè)更大的連接上都具有tcp特性。
這正是HTTP/3 到 QUIC所做的。QUIC作為TCP的替代品，在底層UDP數(shù)據(jù)包本身和HTTP/3之上維護(hù)流，而HTTP/2對(duì)流一無所知。將流視為小型TCP連接，但處于資源級(jí)別。換句話說，與HTTP相比，QUIC保留了單個(gè)資源流中的排序，但不再跨越單個(gè)流。這也意味著QUIC不再按照請(qǐng)求的順序向應(yīng)用程序?qū)觽鬟f資源。
QUIC系統(tǒng)的另一個(gè)目標(biāo)是提高網(wǎng)絡(luò)切換事件期間的性能，例如當(dāng)移動(dòng)設(shè)備的用戶從本地wifi熱點(diǎn)移動(dòng)到移動(dòng)網(wǎng)絡(luò)時(shí)發(fā)生的情況。當(dāng)這種情況發(fā)生在TCP上時(shí)，會(huì)開始一個(gè)漫長(zhǎng)的過程，每個(gè)現(xiàn)有連接都會(huì)逐一超時(shí)，然后根據(jù)需要重新建立。為了解決這個(gè)問題，QUIC包括一個(gè)連接標(biāo)識(shí)符，該標(biāo)識(shí)符唯一地標(biāo)識(shí)到服務(wù)器的連接，而不考慮源。這允許通過發(fā)送始終包含此ID的數(shù)據(jù)包來重新建立連接，因?yàn)榧词褂脩舻腎P地址發(fā)生更改，原始連接ID仍然有效。
指示客戶端和服務(wù)器的速度的流控制保持在流級(jí)別。這是通過發(fā)布/訂閱一個(gè)窗口來實(shí)現(xiàn)的，該窗口指示每一方可以發(fā)送多少數(shù)據(jù)，并在每次成功傳輸后更新該窗口。
為了在不等待重傳的情況下從丟失的數(shù)據(jù)包中恢復(fù)，QUIC可以用FEC數(shù)據(jù)包補(bǔ)充一組數(shù)據(jù)包。與RAID-4非常類似，F(xiàn)EC數(shù)據(jù)包包含F(xiàn)EC組中數(shù)據(jù)包的奇偶校驗(yàn)。如果組中的一個(gè)分組丟失，則可以從FEC分組和組中的剩余分組中恢復(fù)該分組的內(nèi)容。發(fā)送者可以決定是否發(fā)送FEC分組以優(yōu)化特定場(chǎng)景（例如，請(qǐng)求的開始和結(jié)束）。
嗯。為什么我們需要UDP？為什么不通過IP實(shí)現(xiàn)QUIC？
這是因?yàn)槠髽I(yè)和互聯(lián)網(wǎng)上的大多數(shù)防火墻仍然支持UDP協(xié)議。如果我們要在IP上分層QUIC，我們必須重新配置所有這些。UDP無論如何都是一個(gè)小開銷（8字節(jié)報(bào)頭）。
QUIC的安全性問題呢？下次我們?cè)賮碛懻?/span>
聯(lián)系客服
