? ? ? ?QUIC（快速UDP互聯(lián)網(wǎng)連接）協(xié)議是一種新的默認(rèn)加密的互聯(lián)網(wǎng)通信協(xié)議赡磅，它提供了許多改進，旨在加速HTTP通信宝与，同時使其變得更加安全焚廊，其最終目的是在web上代替TCP和TLS協(xié)議。在這篇博客中习劫，我們將對QUIC協(xié)議的一些內(nèi)容進行概述节值，這些內(nèi)容包括該協(xié)議的一些關(guān)鍵特性以及這些特性會如何使web受益，還包括支持這種激進的新協(xié)議過程中遇到的一些挑戰(zhàn)榜聂。

事實上，有兩種協(xié)議共用這個名稱嗓蘑，一種是“Google QUIC”（簡稱gQUIC）须肆，它是幾年前由谷歌公司的工程師設(shè)計的原始協(xié)議，經(jīng)過多年的試驗桩皿，該協(xié)議現(xiàn)在已經(jīng)被IETF（互聯(lián)網(wǎng)工程任務(wù)組）采納為標(biāo)準(zhǔn)協(xié)議豌汇。 另一種是“IETF QUIC”（從現(xiàn)在開始叫作“QUIC”），它已經(jīng)與gQUIC有了很大的不同泄隔，以至于它可以被認(rèn)為是一個單獨的協(xié)議拒贱。從數(shù)據(jù)包的有線格式，到握手機制和HTTP的映射佛嬉，通過許多機構(gòu)和個人的開放的合作逻澳，QUIC協(xié)議改進了最初的gQUIC設(shè)計，實現(xiàn)了讓互聯(lián)網(wǎng)更快暖呕、更安全的共同目標(biāo)斜做。

QUIC有一個更徹底的背離現(xiàn)在脆弱的TCP協(xié)議的特點，即它所聲稱的設(shè)計目的是提供一個默認(rèn)安全的傳輸協(xié)議湾揽。通過提供一些安全方面的特性瓤逼，比如身份驗證和加密等笼吟，QUIC協(xié)議自身實現(xiàn)了這一目的。而這些工作通常本應(yīng)是由更高層次的協(xié)議（如TLS協(xié)議）來完成的霸旗。

最初的QUIC握手機制將TCP協(xié)議使用的典型的三次握手方式贷帮，與TLS1.3協(xié)議的握手機制結(jié)合起來，它提供了端點的身份驗證以及加密參數(shù)的協(xié)商等機制诱告。對于那些熟悉TLS協(xié)議的人們來說撵枢，QUIC用它自己的框架格式代替了TLS協(xié)議的記錄層，同時保留了與原來相同的TLS握手消息蔬啡。

這不僅能夠確保連接總能實現(xiàn)身份驗證和加密诲侮，而且，由此使得初始連接的建立速度更快了：相比于TCP和TLS1.3相結(jié)合的握手機制需要客戶端和服務(wù)器之間兩次消息往返來說箱蟆，典型的QUIC握手只需要一次往返就可以完成沟绪。

基于TCP+TLS的HTTP請求:

基于QUIC的HTTP請求:

但是QUIC走得更遠(yuǎn)，它還對額外連接的元數(shù)據(jù)進行加密空猜，這些元數(shù)據(jù)可能被一些中間件所利用绽慈，從而對連接產(chǎn)生干擾。例如辈毯，當(dāng)連接遷移的漏洞被利用時坝疼，路途中的被動攻擊者可以利用數(shù)據(jù)包編號來發(fā)現(xiàn)多條網(wǎng)絡(luò)路徑上的用戶活動之間的聯(lián)系（詳見下文）。通過加密數(shù)據(jù)包編號谆沃，QUIC可以確保钝凶，除了通信連接的端點之外，沒有任何實體能夠使用數(shù)據(jù)包編號來發(fā)現(xiàn)用戶活動之間的聯(lián)系唁影。

加密也可以是一種有效的避免僵化的補救措施耕陷。所謂僵化是指，由于在部署時作出了錯誤的假設(shè)据沈，導(dǎo)致某種協(xié)議原本內(nèi)置的調(diào)節(jié)機制（例如哟沫，原本該協(xié)議與其自身的幾個版本之間都可以進行協(xié)商）實際上無法奏效（僵化正是這么長時間以來TLS1.3的部署仍然被拖延的原因，TLS1.3旨在防止僵化的中間件錯誤地阻止該協(xié)議的修正锌介，而只有當(dāng)該協(xié)議做出幾項重要變更后嗜诀，才可能被廣泛部署）。

HTTP/2所帶來的主要改進之一是孔祸，它能夠?qū)⒉煌腍TTP請求多路傳輸?shù)酵粋€TCP連接上隆敢。這使得HTTP/2應(yīng)用程序能夠并發(fā)地處理請求，并更好地利用它們可用的網(wǎng)絡(luò)帶寬崔慧。

這比原來的情況有了很大的改進筑公，當(dāng)時的要求是，如果應(yīng)用程序想要并發(fā)地處理多個HTTP/1.1請求（例如尊浪，當(dāng)瀏覽器需要同時獲取CSS和Javascript資源以呈現(xiàn)web頁面時）匣屡，就需要初始化多個TCP+TLS連接封救。創(chuàng)建新的連接需要多次重復(fù)最初的握手，同時還要經(jīng)歷最初的擁塞窗口緩慢增大的過程捣作，這意味著web頁面的呈現(xiàn)速度被減慢了誉结。多路復(fù)用HTTP交換則避免了所有這些問題。

然而券躁，這有一個缺點：由于多個請求/響應(yīng)通過同一個TCP連接傳輸惩坑，它們都同樣受到數(shù)據(jù)包丟失（例如，由于網(wǎng)絡(luò)擁塞所造成的）的影響也拜，即使丟失的數(shù)據(jù)只涉及單個請求以舒。這被稱為“隊首阻塞”。

QUIC走得更遠(yuǎn)一些慢哈，它為多路復(fù)用提供一流的支持蔓钟，這樣，不同的HTTP流反過來可以映射到不同的QUIC通信流卵贱，然而滥沫，盡管它們?nèi)匀还蚕硗籕UIC連接因而不需要額外的握手，而且擁塞狀態(tài)也是共享的键俱，但QUIC流的傳輸卻是獨立的兰绣，因此在大多數(shù)情況下，數(shù)據(jù)包丟失只影響一個通信流编振，而不會影響其他人缀辩。

這可以極大地減少所需的時間，例如踪央，呈現(xiàn)完整的web頁面（帶有CSS臀玄、Javascript、圖片以及其它類型的資源）的時間杯瞻，特別是在通信需要跨越高度擁擠的網(wǎng)絡(luò)并伴隨著很高的丟包率的情況下。

為了實現(xiàn)它的承諾炫掐，QUIC協(xié)議需要打破許多網(wǎng)絡(luò)應(yīng)用程序認(rèn)為理所當(dāng)然的一些假設(shè)魁莉，這可能會使QUIC的實現(xiàn)和部署變得更加困難。

QUIC被設(shè)計為在UDP數(shù)據(jù)報的頂端進行傳輸募胃，這樣可以簡化部署旗唁，并避免來自網(wǎng)絡(luò)設(shè)備的一些問題（一些網(wǎng)絡(luò)設(shè)備會自動丟棄來自未知協(xié)議的數(shù)據(jù)包），這是因為大多數(shù)設(shè)備已經(jīng)支持UDP協(xié)議痹束。這也使得QUIC可以在用戶那一端進行部署检疫，例如，瀏覽器將能夠?qū)崿F(xiàn)新的協(xié)議功能祷嘶，并將它們發(fā)送給用戶屎媳，而不必等待操作系統(tǒng)的更新夺溢。

然而，盡管目標(biāo)是避免連接受損烛谊，但它也給防范入侵以及如何正確地將數(shù)據(jù)包路由到正確的端點帶來了更多的挑戰(zhàn)风响。

典型的NAT路由器能夠?qū)νㄟ^自身的TCP連接進行追蹤，這可以使用傳統(tǒng)的四元組（源IP地址丹禀、源端口状勤、目標(biāo)IP地址、目標(biāo)端口）來實現(xiàn)双泪，而通過觀察在網(wǎng)絡(luò)中傳輸?shù)腡CP數(shù)據(jù)包中的SYN持搜、ACK和FIN標(biāo)記位，這些路由器可以檢測到新連接的建立和終止焙矛。這使得它們能夠精確地管理NAT綁定的生命周期葫盼、

內(nèi)部IP地址和端口之間的聯(lián)系以及外部IP地址。

而對于QUIC來說薄扁，這現(xiàn)在還是不可能的剪返，因為目前部署在外部網(wǎng)絡(luò)的NAT路由器還并不了解QUIC，所以它們通常會退回到默認(rèn)的和不太精確的UDP流處理機制邓梅，這通常涉及到使用任意長度（有時非常短）的超時脱盲，而這可能會影響那些長時間運行的連接。

當(dāng)一個NAT重新綁定發(fā)生時（例如由于超時）日缨，位于NAT邊界之外的通信端點會看到來自另一個源端口的數(shù)據(jù)包钱反，該端口與連接最初建立時被觀察到的源端口并不相同，這樣匣距，就不可能通過使用傳統(tǒng)的四元組來追蹤連接面哥。

而且不僅僅是NAT！QUIC想要帶來的特性之一是“連接遷移”毅待，它將允許QUIC端點將連接任意地遷移到不同的IP地址和網(wǎng)絡(luò)路徑尚卫。例如，當(dāng)一個已知的WiFi網(wǎng)絡(luò)變得可用時（比如尸红，當(dāng)用戶進入他們最喜歡的咖啡廳時）吱涉，移動客戶端將能夠在蜂窩數(shù)據(jù)網(wǎng)絡(luò)和WiFi網(wǎng)絡(luò)之間遷移QUIC連接。

QUIC試圖通過引入連接ID的概念來解決這個問題外里，連接ID是指怎爵，一個由QUIC數(shù)據(jù)包攜帶的，任意的盅蝗，不透明的鳖链，可變長度的blob對象，它可以用來標(biāo)識網(wǎng)絡(luò)連接墩莫。終端可以使用這個ID來追蹤它們所負(fù)責(zé)的連接芙委，而不需要檢查四元組（實際上逞敷，可能會有多個ID來標(biāo)識相同的連接，例如题山，可以用來避免在連接遷移時連接到不同的路徑兰粉，但這種行為是由終端而不是中間件來控制的）。

然而顶瞳，這也給使用任意播尋址方式和ECMP路由的網(wǎng)絡(luò)運營商帶來了問題玖姑，在ECMP路由中，單個目標(biāo)IP地址可能會指向數(shù)百臺甚至數(shù)千臺服務(wù)器慨菱。因為這些網(wǎng)絡(luò)所使用的邊緣路由器也還不知道如何處理QUIC通信焰络，可能會發(fā)生這樣的情況，屬于同一QUIC連接（這指的是具有同一連接ID的QUIC連接）但卻具有不同的四元組（這是由于NAT重新綁定或連接遷移所造成的）的UDP數(shù)據(jù)包可能會被路由到不同的服務(wù)器符喝，從而最終導(dǎo)致連接斷開闪彼。

為了解決這個問題，網(wǎng)絡(luò)運營商可能需要使用更加智能的第四層負(fù)載均衡解決方案协饲，這種解決方案可以在軟件中實現(xiàn)畏腕，并且在不需要接觸邊緣路由器的情況下部署（例如，F(xiàn)acebook的Katran項目）茉稠。

HTTP/2所帶來的另一個好處就是頭部壓縮（或叫作HPACK）描馅，它使得HTTP/2端點可以通過刪除HTTP請求和響應(yīng)的冗余來減少通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。

特別是而线，相比其他各項技術(shù)铭污，HPACK所使用的充滿了從此前的HTTP請求（或響應(yīng)）發(fā)送（或接收）的報頭的動態(tài)表，使得端點可以在新的請求（或響應(yīng)）中引用以前遇到過的頭部信息膀篮，而不必再一次傳輸它們嘹狞。

HPACK的動態(tài)表需要在編碼器（發(fā)送HTTP請求或響應(yīng)的一方）和解碼器（接收它們的一方）之間進行同步，否則解碼器將無法解碼它接收到的內(nèi)容誓竿。

基于TCP的HTTP/2的這種同步是透明的磅网，因為傳輸層（TCP）負(fù)責(zé)以與報文被發(fā)送到該層時相同的順序來傳輸HTTP請求和響應(yīng)，對表進行更新的指令可以直接作為請求（或響應(yīng)）本身的一部分筷屡，由解碼器進行發(fā)送习绢，這使編碼變得非常簡單跋炕。但對于QUIC來說虽画，情況則更為復(fù)雜屿良。

QUIC可以在不同的流中獨立地傳遞多個HTTP請求（或響應(yīng)）惊奇，這意味著牲芋，雖然對于單個流而言耍共，它可以按順序傳輸數(shù)據(jù)乃沙，但在多個流當(dāng)中诽表，卻無法保證正確的傳輸順序唉锌。

例如隅肥，如果一個客戶端在QUIC流A中發(fā)送HTTP請求A，然后在QUIC流B中發(fā)送請求B袄简，那么腥放，由于在網(wǎng)絡(luò)中數(shù)據(jù)包會重新排序或丟失，因此可能會發(fā)生服務(wù)器在收到請求A之前就收到請求B的情況绿语，而如果請求B被編碼了因而需要參考請求A的頭部信息秃症，那么由于服務(wù)器還未收到請求A，它將無法解碼請求B吕粹。

在gQUIC協(xié)議中种柑，這個問題通過在gQUIC流中簡單地對所有HTTP請求和響應(yīng)的頭部（而不是主體）進行序列化而得到了解決，這意味著無論如何都要按順序傳輸頭部匹耕。這是一個非常簡單的方案聚请，它使得程序可以重復(fù)使用大量現(xiàn)有的HTTP/2代碼，但另一方面稳其，它也增加了隊首阻塞的情況驶赏，而這本來是QUIC設(shè)計時想要減少的。因此既鞠，IETF QUIC工作組設(shè)計了一個在HTTP和QUIC（“HTTP/QUIC”）之間的新映射關(guān)系煤傍，同時還設(shè)計出一個名為“QPACK”的新頭部壓縮方案。

在最新的HTTP/QUIC映射和QPACK規(guī)范草案中损趋，每個HTTP請求/響應(yīng)交換都使用它自己的雙向QUIC流患久，因此就沒有隊首阻塞的情況。此外浑槽，為了支持QPACK蒋失，每個對等節(jié)點會創(chuàng)建兩個額外的單向QUIC流，一個用于向另一個對等節(jié)點發(fā)送QPACK表更新桐玻，而另一個則用于確認(rèn)另一方收到的更新篙挽。通過這種方式，一個QPACK編碼器只能在被解碼器明確地承認(rèn)后才能使用動態(tài)表引用镊靴。

在基于UDP的一些協(xié)議中铣卡，一個常見的問題是，它們?nèi)菀资艿椒瓷涔羝埂＿@種攻擊是這樣進行的煮落，為了對目標(biāo)主機進行攻擊，攻擊者假冒發(fā)往服務(wù)器的數(shù)據(jù)包的源IP地址踊谋，使得這些數(shù)據(jù)包看起來像是由目標(biāo)主機發(fā)過來的蝉仇，從而欺騙了服務(wù)器，這樣，服務(wù)器就會誤認(rèn)為目標(biāo)主機請求了大量數(shù)據(jù)轿衔，于是就會將這些數(shù)據(jù)發(fā)送過去沉迹。

當(dāng)服務(wù)器發(fā)出的響應(yīng)比它接收到的請求更大時，這種攻擊可能是非常有效的害驹，在這種情況下鞭呕，我們討論的是“放大”。

這種攻擊通常不使用TCP連接宛官，因為在握手過程中傳輸?shù)某跏紨?shù)據(jù)包（SYN葫松、SYN+ACK、……）具有相同的長度底洗，因此它們不會有任何被放大的可能进宝。

QUIC的握手方式則是非常不對稱的：就像對于TLS一樣，在它的第一次旅程中枷恕，QUIC服務(wù)器通常會發(fā)送自己的證書鏈党晋，它可能非常大，而客戶端則只需要發(fā)送幾個字節(jié)（將TLS的客戶端問候消息嵌入到QUIC包中）徐块∥床＃基于這個原因，客戶端發(fā)送的初始QUIC包必須被填充到特定的最小長度（即使包的實際內(nèi)容要小得多）胡控。然而扳剿，這種緩和措施仍然是不夠的，因為典型的服務(wù)器響應(yīng)會跨越多個數(shù)據(jù)包昼激，因此仍然比填充的客戶端數(shù)據(jù)包大得多庇绽。

QUIC協(xié)議還定義了一個顯式的源地址驗證機制，在這種機制中橙困，服務(wù)器只發(fā)送一個小得多的“重試”數(shù)據(jù)包瞧掺，而不會發(fā)送較長的響應(yīng)。這個小的數(shù)據(jù)包包含一個唯一的加密令牌凡傅，然后辟狈，客戶端將必須在一個新的初始數(shù)據(jù)包中對服務(wù)器進行響應(yīng)。通過這種方式夏跷，服務(wù)器將會更加信任客戶端哼转，相信客戶端并未使用假冒的源IP地址（這是因為客戶端收到了重試數(shù)據(jù)包），這樣就可以完成握手了槽华。這種緩和措施的缺點是壹蔓，它增加了最初的握手時間，從一次往返變成了兩次往返猫态。

另一種可選的解決方案是佣蓉，減少服務(wù)器的響應(yīng)煮纵，使得反射攻擊變得不那么高效，例如偏螺，使用ECDSA證書（這種證書通常比使用RSA算法的證書要小得多）。我們也一直在試驗一種使用現(xiàn)成的壓縮算法（如zlib和brotli）來壓縮TLS證書的機制匆光，這種機制最初是由gQUIC引入的一種功能套像，但目前還沒有在TLS中使用。

QUIC的一個反復(fù)出現(xiàn)的問題在于终息，部署在外部網(wǎng)絡(luò)的現(xiàn)有硬件和軟件無法理解它夺巩。我們已經(jīng)研究了QUIC如何試圖解決像路由器這樣的網(wǎng)絡(luò)中間件的問題，但是周崭，另一個潛在的問題是柳譬，在QUIC端點上使用UDP協(xié)議發(fā)送和接收數(shù)據(jù)的性能如何。多年以來续镇，人們做了很多工作來盡可能地優(yōu)化TCP應(yīng)用美澳，包括在軟件（如操作系統(tǒng)）和硬件（如網(wǎng)絡(luò)接口）上建立卸載功能，但是目前UDP協(xié)議還不支持這些功能摸航。

然而制跟，QUIC應(yīng)用可以使用這些功能將只是個時間問題。例如酱虎，最近人們致力于在Linux系統(tǒng)中為UDP協(xié)議實現(xiàn)通用分段卸載（Generic Segmentation Offloading）功能雨膨，這將使應(yīng)用程序可以在用戶空間和內(nèi)核空間的網(wǎng)絡(luò)協(xié)議棧之間以一個UDP段（或非常接近）的開銷捆綁傳輸多個UDP段，以及為Linux加入零復(fù)制套接字支持的UDP段读串，這可以使應(yīng)用程序免去從用戶空間向內(nèi)核空間復(fù)制信息的開銷聊记。

與HTTP/2和TLS1.3一樣，QUIC將提供許多新的特性恢暖，以提高web站點的性能和安全性排监，它也會提供許多其它的基于互聯(lián)網(wǎng)的屬性。IETF工作組計劃于今年年底前交付QUIC規(guī)范的第一個版本杰捂，讓我們拭目以待社露！