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