互聯網數據傳輸協議QUIC研究綜述

李學兵 陳 陽 周孟瑩 王 新

1(復旦大學計算機科學技術學院 上海 201203) 2(上海市智能信息處理重點實驗室(復旦大學) 上海 201203) 3(鵬城實驗室 廣東深圳 518066)xbli16@fudan.edu.cn)

QUIC是一個由Google提出的、用于替代TCP(Transmission Control Protocol)的數據傳輸協議[1].近幾年來，在學術領域，對QUIC這一新型傳輸層協議的研究一直是一個熱點.在SIGCOMM，IMC，WWW，CoNEXT，CCS等國際頂尖的網絡、安全領域會議上[2-9]已經發表了一系列關于QUIC的傳輸性能、安全性等方面的研究成果.在工業界，QUIC也已經得到了廣泛的應用與部署.Google在它的產品(Chrome瀏覽器[10]、Google Cloud[11]等)中最早提供了對QUIC的支持.此外，一些內容分發網絡(content delivery network, CDN)服務商，例如Akamai[12]和Cloudflare[13]，也已經對QUIC提供了支持.截至2018年，互聯網近7.8%的流量使用QUIC進行網絡通信[14].

與目前使用最為廣泛的傳輸層協議TCP相比，QUIC引入了許多新的特性.例如，它支持一條傳輸層連接上的多路傳輸和延時更低的握手.這些新特性使得QUIC在大部分場景下表現出比TCP更好的性能.例如更短的網頁加載時間、更低的握手延時等.在安全性方面，QUIC使用了比現有的TLS1.2[15]更加安全的加密傳輸協議TLS1.3[16]，從而更好地保障通信安全以及用戶隱私.然而，也有研究表明，QUIC在特定場景下的表現不如預期，甚至不如TCP.例如，QUIC無法很好地適應高丟包率的網絡[3,17]基于此，本文從安全性和傳輸性能2方面對現有的QUIC相關研究工作進行分類和總結，并對基于QUIC的優化方案進行介紹.

1 QUIC概述

QUIC最早由Google開發，正式發布于2013年，被稱為gQUIC[18].gQUIC是一套相對獨立的傳輸層協議，它同時保障了數據傳輸的可靠性和安全性，因此從功能性的角度出發，gQUIC類似于TCP+TLS.目前，gQUIC已經得到了廣泛的應用，包括Chrome，IE，Safari，Firefox在內的主流瀏覽器都支持gQUIC.同時，Google的網站服務器與云服務中也提供了gQUIC的支持.在2013年末，QUIC的設計工作被互聯網工程任務組(Internet Engineering Task Force， IETF)接管[19]，并發布了正式的QUIC標準，我們稱之為IETF版本的QUIC.IETF版本的QUIC與gQUIC最大的區別在于，它僅負責保障數據傳輸的穩定性，而將安全性的保障交由TLS1.3.目前IETF版本QUIC的開源實現有ngtcp2,aioquic等.但是與gQUIC不同，IETF版本的QUIC尚沒有在互聯網中大規模部署的例子.為了配合QUIC協議的標準化，Google表示，將會在自己的服務器與瀏覽器中逐漸放棄gQUIC并使用IETF版本的QUIC，gQUIC的設計也正在逐步向IETF版本的QUIC靠攏.

1.1 QUIC協議模型

QUIC協議模型如圖1所示.它向下使用了操作系統提供的UDP(User Datagram Protocol)套接字，向上為應用層協議(例如HTTP2)提供了可靠且安全的傳輸通道.雖然QUIC在實現上基于傳輸層協議UDP，但是它在協議設計上并沒有依賴于UDP的特性，即沒有使用UDP端口來標識一條傳輸層連接.QUIC使用UDP的目的僅僅是為了保持和現有網絡的兼容性，因為目前互聯網上的某些防火墻會屏蔽TCP和UDP之外的傳輸層協議.因此，盡管QUIC工作于傳輸層協議UDP之上，研究人員仍然普遍將它歸類為傳輸層協議[1,5].

Fig. 1 QUIC protocol architecture圖1 QUIC協議模型

1.2 QUIC的協議特性

與傳統的傳輸層協議如TCP相比，QUIC引入了許多新的特性，其中最主要的是支持一條連接上的多路傳輸和更低的握手延時.

1.2.1 多路傳輸

QUIC通過對多路傳輸的支持，解決了TCP中的隊頭阻塞問題[22].

如圖2所示，在TCP連接中，它維護的是一條先進先出的通道，也就是說接收端必須嚴格按照發送端的順序處理收到的數據，這樣的設計導致了隊頭阻塞的問題.在圖2的例子中，客戶端先后向服務端發送了邏輯上沒有相關性的數據包2和數據包3.在接收端，即使數據包3先于數據包2到達，TCP也不會先將數據包3中的數據交給上層應用處理，而是必須等待數據包2的接收完成才能進行后續處理.正是因為TCP通道的先進先出特性，導致對數據包3的處理被數據包2拖延，造成了不必要的延時.這是隊頭阻塞的一種情況，關于隊頭阻塞的更詳細的研究見文獻[23-24].

Fig. 2 Multiplexing vs singleplexing圖2 多路傳輸與單路傳輸的對比

為了解決隊頭阻塞的問題，QUIC增加了在一條傳輸層連接上的多路傳輸的支持.它在傳輸層連接下引入了流(stream)的概念.一條QUIC連接可以包含多個流，這些流各自保證了先進先出的有序性，但相互之間又不存在依賴關系.從這點來說，QUIC中“流”的概念更接近于TCP中“連接”的概念，因為它們都是為上層應用提供了一條先進先出的通道.但是，QUIC中不同流之間共享連接信息，所有的流共同參與擁塞控制、丟包檢測以及數據加密.這樣，和使用多條TCP連接相比，使用多個流的單條QUIC連接既達到了多路傳輸的目的，又節省了系統資源.

1.2.2 握手協議

QUIC設計了自己的握手協議，并達到了比TCP+TLS更低的握手延時.

TLS使用了對稱加密和非對稱加密相結合的方式為數據的安全性提供保障.其運行機制可以簡單分為2步：1)客戶端與服務端通過握手協議生成共享密鑰；2)雙方分別使用共享密鑰進行數據的加密和解密.更詳細的關于TLS介紹見文獻[16-17].在TLS1.2中，握手協議通過RSA算法或者迪菲-赫爾曼算法完成.其中RSA要求通信雙方首先交換各自的RSA公鑰，再通過RSA加密傳輸一個新生成的共享密鑰，因此完成握手需要2個往返時間(round trip time， RTT).而到了TLS1.3，迪菲-赫爾曼成為唯一的密鑰交換協議，通信雙方可以直接通過對方的公鑰和自己的私鑰生成共享密鑰，握手延時也從原來的2個RTT降為了1個RTT.

Fig. 3 Handshake latency of different protocols圖3 不同協議握手延時的對比

圖3列舉了QUIC和TCP握手延時的區別.目前使用最為廣泛的協議組是TCP+TLS1.2，在該情況下，客戶端與服務端之間的握手至少需要消耗3個RTT，包括1個RTT的TCP握手延時和2個RTT的TLS握手延時.在最新的TCP+TLS1.3協議組中，因為TLS的握手延時由原來的2個RTT減小到了1個RTT，所以總的握手延時降為了2個RTT.QUIC在此基礎上更進一步地進行了優化，它允許在建立傳輸層連接的同時進行TLS握手.也就是說，QUIC的握手請求數據包中也包含了TLS1.3的握手請求數據，從而使整體的握手延時降為了1個RTT.我們稱QUIC的這種握手方式為1-RTT握手.

Fig. 4 Category of QUIC-related studies圖4 QUIC相關工作的分類

如果客戶端在之前已經連接過服務端，客戶端和服務端之間則會保留上次會話的相關加密信息，重用共享密鑰.在這種情況下，客戶端可以直接使用上次通信的共享密鑰進行數據加密，而新的密鑰交換過程會與數據傳輸同步進行.也就是說，數據傳輸不需要等待握手的完成，從而實現沒有任何延時的握手.我們稱QUICTLS1.3的這種握手方式為0-RTT握手.0-RTT握手極大地降低了客戶端的握手延時從而可以顯著減少用戶訪問網絡的延遲感，提升用戶體驗.

2 研究現狀分析

圖4對現有的QUIC相關研究工作進行了分類與總結.主要包括3個方面：QUIC網絡傳輸性能的測量、QUIC性能的優化以及QUIC安全性的分析與改進.

在傳輸性能方面，研究人員最關心的是QUIC和TCP+TLS相比會有多大的性能提升，包括在不同網絡環境和不同傳輸內容下的表現.在QUIC的性能優化方面，研究者一方面為QUIC協議帶來了諸如多路徑等新特性，另一方面在系統實現中使用內核旁路等新技術達到了比現有系統更高的IO吞吐率.在安全性方面，研究人員使用多種方法對QUIC的安全性進行了建模分析，同時也指出了QUIC存在的一些安全隱患，并給出了相應的改進建議.

2.1 QUIC的傳輸性能

自Google第1次發布QUIC以來，研究人員便對QUIC的網絡傳輸性能產生了濃厚的興趣.本節列舉了近年學術界在QUIC性能分析上的工作.考慮到網絡協議性能的分析離不開具體的應用場景，我們根據不同的應用場景對相關工作分為了2類，分別是網頁瀏覽和視頻傳輸.表1對QUIC性能分析的相關工作進行了總結.

Table 1 Related Work on QUIC Performance Analysis表1 QUIC性能分析的相關工作

2.1.1 網頁瀏覽

網頁瀏覽是互聯網中使用最為廣泛的應用.瀏覽器在進行網頁訪問時會先下載網站資源，包括HTML，CSS，JavaScript等類型的文件，再渲染在界面上，最終呈現給用戶.一個好的網絡協議應該保證瀏覽器花費最少的時間完成網站資源的下載，也就是最小化網頁加載時間(page load time， PLT)[33].

Das[17]在他的碩士論文中最早進行了對QUIC網絡傳輸性能的系統性分析.他在可控網絡下模擬了不同的網絡參數，包括帶寬和端到端延時.他選擇了500個網站，測量了使用TCP和QUIC在不同的網絡環境下訪問這些網站的網頁加載時間.他根據實驗結果總結并分析了QUIC的主要優勢為：1)當帶寬很低時，擁塞控制窗口會很小，導致丟包的發生更容易阻塞住后面的數據包，這時沒有隊頭阻塞問題的QUIC更不容易受到影響.2)當端到端延時較高時，因為QUIC在握手過程比TCP消耗更少的RTT，所以能夠有效降低初始數據包的延時.然而，作者在實驗過程中也發現了QUIC存在的問題.一方面，因為QUIC協議實現仍然處于迭代式開發中，所以代碼沒有很好地進行優化，在與TCP的對比中處于劣勢.另一方面，QUIC強制要求進行數據加密，而數據加密在TCP是可選項(即TLS協議)，由加密解密帶來的額外計算開銷會降低QUIC的數據包處理速度.即便同時啟用加密，因為QUIC的安全性更強，仍然導致其加密解密過程比TCP慢12%.當網絡帶寬變大，尤其是大于25 Mbs時，QUIC的網絡傳輸速度甚至會比TCPTLS慢80%.這是因為高吞吐率使得CPU因無法及時完成加密解密操作，最終成為網絡傳輸的瓶頸.

Google在2017年SIGCOMM的論文中總結了他們在大規模部署實驗中使用QUIC的經驗[5].從2014年開始，Google在Chrome瀏覽器以及手機上的YouTube應用和Google搜索應用上對部分用戶啟用了QUIC，并與TCP進行了對比.到2017年，幾乎所有的Chrome和YouTube應用都已啟用QUIC.他們發現，在搜索服務中，有88%來自桌面電腦的連接使用了0-RTT握手，在握手延時方面與原來的TCPTLS相比至少減少了2個RTT.另外，QUIC使用了更多的信號用于網絡擁塞及丟包的檢測，這也使得QUIC對高丟包率有更好的容忍性.這些因素導致搜索服務的整體延時降低了3%～8%.而QUIC在移動設備上的優勢則沒有桌面端的優勢那么明顯.這是因為移動端的0-RTT握手概率更低，只有68%.0-RTT握手概率降低的原因是，一方面，移動設備會頻繁更換網絡，使得服務端強制要求驗證客戶端新的IP地址并退回到1-RTT握手.另一方面，在切換網絡后，客戶端可能會選擇與之前不一樣的數據中心獲得服務，從而無法利用之前的連接信息，只能使用1-RTT握手與新的服務器建立新的連接.與Das一樣，Google也發現，當傳輸速率過快時(高于100 Mbs)，CPU會成為系統的瓶頸從而限制網絡吞吐率.

Kakhki等人[3]在可控環境下完成了更為詳細的對比實驗.他們使用軟件模擬了不同的網絡環境，包括帶寬、延時以及丟包率，并在這些網絡下對比了QUIC與TCP的網頁加載延時.這些網頁根據包含資源的數量和大小的不同被分為了很多組.實驗表明，QUIC幾乎在所有場景下都獲得了比TCP更短的網頁加載時間.作者發現，0-RTT握手是造成該場景下QUIC性能優越的主要原因.在所有情況下，只有當網頁中存在大量的小資源時QUIC才表現出比TCP更差的性能.其原因是，QUIC發送端會因為觀測到傳輸過程中最小RTT的增大而錯誤地認為網絡中發生了擁塞，從而過早地結束了擁塞窗口的快啟動階段，導致發送速率無法快速增長.這一點在傳輸數據流大時沒有顯著的影響，因為比較長的傳輸時間讓QUIC有充足的時間增長傳輸速率.然而，當傳輸數據量較小時，往往在QUIC的傳輸速率增長到物理帶寬限制之前，傳輸就已經完成了.此外，作者發現，QUIC在數據包亂序嚴重的場景下，比如3G網絡，性能會嚴重下降，甚至低于TCP.其原因在于QUIC在丟包檢測算法的參數選擇上過于嚴苛，導致算法錯誤地將亂序到達的數據包判斷為丟包，造成不必要的重傳，最終浪費帶寬資源.

Kharat等人[25]在WiFi網絡下對QUIC和TCP的公平性進行了分析.他們發現，在只有一條連接時，QUIC能比TCP更有效地利用帶寬.但是當同時使用2條TCP連接和2條QUIC連接時，TCP能夠搶占更多的帶寬.原因是某些瀏覽器(例如Opera和Firefox)會為TCP連接保留部分帶寬用于小文件的傳輸，造成了對QUIC的不公平.

Yang等人[26]分析了QUIC在衛星網絡下的表現.相較于傳統網絡，用于空間通信的衛星網絡擁有高延時、高丟包率的特征.他們基于仿真的衛星網絡，比較了QUIC和TCP在地球同步軌道衛星和低地軌道衛星2種情況下的性能差異.比較結果顯示，在所有的情況下，QUIC都能表現出更好的性能.通過對傳輸過程更細化的分析，他們總結出QUIC的優勢主要在于通過0-RTT握手減少了握手延時以及通過更大的擁塞窗口減少了接收端的丟包.張晗[27]更進一步地在基于QUIC的衛星網絡中使用BBR算法[34]替代QUIC中默認的NewReno算法[35]用于擁塞控制，進一步提升了QUIC在高延時和高丟包率網絡下的傳輸性能.

與以上在仿真網絡下進行的測量工作不同，Rajiullah等人[9]在真實的蜂窩網絡下對支持QUIC的網站進行了測量.他們發現，使用QUIC訪問這些網站往往比直接使用TCP會耗費更長的網頁加載時間.其原因在于，支持QUIC的網站通常需要引用其他網站的資源，而這些資源所在的服務器通常不支持QUIC，因此瀏覽器需要花費一定的延時從QUIC退回到TCP，從而導致總的加載延時被延長.這一發現為后續從事互聯網上QUIC測量工作的研究者提供了新的思路，即互聯網對QUIC的支持情況也會對我們所觀察到的QUIC的性能產生不小的影響.

對于以上測量工作，我們注意到，所有這些對QUIC的測量工作都是基于gQUIC完成的.主要原因是Google目前在Chrome上實現的是gQUIC而不是IETF版本的QUIC.Chrome作為一個主流瀏覽器，gQUIC為它帶來的性能改變更受研究人員關心.同時，Google在全球部署的大量服務器也為gQUIC的測量提供了可靠的實驗平臺.但是這也導致了科研人員過分專注于gQUIC在互聯網上的表現，而忽視了對IETF版本QUIC性能的分析.雖然這2個版本的QUIC有著相同的設計思想，但是在很多細節上仍有不同，這些差異可能會導致一些gQUIC上的測量結果在IETF版本QUIC上不再適用.此外，QUIC的安全性更接近于TLS1.3，但是在上述的對比實驗中，大部分研究人員選擇將QUIC與TCP+TLS1.2進行對比，這樣的比較并不合理，因為TLS1.3的安全復雜程度遠高于TLS1.2，性能必然會有明顯地下降.隨著TLS1.3標準的正式完成，相信以后會有更多測量是基于TLS1.3進行的.

2.1.2 視頻傳輸

視頻傳輸是互聯網中另一個重要的應用.Cisco的報告表明，在2014年，視頻流量占整個移動網絡流量的55%.并且這一數據有望在2019年達到72%[36].在視頻領域，研究人員普遍使用緩存等待率來衡量視頻的服務質量，也就是用戶等待視頻緩存的時間占總播放時間的比例.

Google在YouTube應用上的測量數據表明，與搜索服務的場景下類似，QUIC能夠在桌面端和移動端分別使得85%和65%的連接實現0-RTT握手[5].但與網頁訪問不同的是，YouTube會在用戶打開視頻前提前與服務端建立連接，從而導致QUIC的0-RTT握手的優勢不再明顯.盡管如此，實驗表明，QUIC仍然能在很大程度上優化視頻播放的質量，它在移動端和桌面端分別降低了13.5%和18.0%的緩存等待率.這是因為，相較于更低的握手延時，及時的丟包重傳對視頻傳輸來說更重要.一個視頻或者音頻幀的丟失往往會阻塞住后面的內容，導致播放器暫停并進行緩沖.YouTube在視頻傳輸時同時使用2條TCP連接，一條連接無法得知另一條連接的數據包是否丟失，從而導致每條連接對數據包的敏感性降低.而QUIC只使用了一條連接，可以最大限度地使用已有信息作為判斷依據，增加對數據包的敏感性.此外，QUIC支持更多的傳輸層信號，可以幫助發送方判斷數據包是否已經丟失，從而能更精確地檢測網絡中的丟包行為，避免因為錯誤檢測而造成的不必要的數據包重傳.

然而Kakhki等人[3]卻得出了與Google不完全相同的結論.他們在丟包率為1%，帶寬為10 Mbs，50 Mbs，100 Mbs的網絡下對比了使用TCP和QUIC播放YouTube視頻的效果.實驗發現，在低幀率時，QUIC和TCP的性能基本一致.只有在高幀率的場景下，QUIC才能提高視頻傳輸的性能，減小緩存等待時間.

2.2 QUIC的性能優化

目前對QUIC的優化工作主要有2方面，分別是對協議本身的優化以及對其實現方法的優化.在協議方面，De Coninck等人[8]以及Viernickel等人[28]分別將多路徑的概念引入QUIC，使得一條QUIC連接可以同時使用多條底層網絡鏈路，增加帶寬.在系統實現方面，Wang等人[29]在系統內核態實現了QUIC協議，而Duan等人[30]則使用了用戶態的UDP實現，他們均在一定程度上提高了QUIC的處理數據包的速度.

2.2.1 多路徑QUIC

多路徑是指允許一條傳輸層連接同時使用多條物理網絡鏈路的技術.其優勢在于，可以同時使用多個物理網絡從而增加有效網絡帶寬.例如，手機用戶可以同時使用蜂窩網絡和WiFi，電腦用戶可以同時使用以太網和WiFi.多路徑在TCP上已有大量研究[37-38]，其中MPTCP[39]已經作為網絡協議標準被IETF收錄，并且被Linux內核所支持.

De Coninck等人[8]最早提出了多路徑QUIC的設計：MPQUIC.他們在流之下定義了路徑(path)，用于描述數據傳輸所使用的物理網絡路徑.在每個Stream幀中會包含一個Path ID，根據不同的Path ID，QUIC可以在發送和接收時將數據包對應到不同的物理網絡.在握手階段，客戶端與服務端會先在一條網絡鏈路上建立QUIC連接.之后每有一個網絡鏈路需要使用，便添加一個新的Path.由此，客戶端可以以多個IP地址為源地址，向服務端發送數據包.在發送端，擁塞控制是對每個物理網絡連接分別進行的.也就是說，每個Path都會維護自己的擁塞窗口、ACK計數、RTT估計等信息，從而實現對每條物理網絡分別進行流量控制的目的.在接收端，來自不同Path的數據包會被合并從而得到完整的Stream幀，并進行下一步處理.在多路徑的擁塞控制算法上，MPQUIC使用了在MPTCP上表現良好的OLIA算法[40].De Coninck等人[8]的實驗表明，在下載大文件的場景下，大部分時候，MPQUIC能夠比MPTCP更快地完成傳輸.這是因為MPTCP缺乏一個有效的對物理連接延時的判斷機制，從而會使得某些數據包被阻塞在較慢的連接上，影響了整體的速度.而MPQUIC則不存在這些問題，因為它對每個物理連接都進行了精確的控制.

Viernickel等人[28]提出了另一套多路徑QUIC的設計方案.與MPQUIC不同的是，他們通過不同的UDP套接字直接區分不同的物理網絡路徑，從而避免了引入Path ID的需要.但是，添加一個新的物理網絡路徑需要連接的一方主動發送announcement數據包通知對方新的物理網絡連接即將被加到當前QUIC連接中，這樣導致添加新物理網絡連接需要耗費1個RTT的延時.

為了對比多路徑QUIC與MPTCP在實際互聯網下性能的差異，De Coninck等人設計了一個iOS應用：MultipathTester[41].該應用支持在不同網絡環境下對多路徑QUIC和MPTCP進行基準測試.實驗結果表明，多路徑QUIC與MPTCP在數據傳輸性能方面沒有顯著的差異[42].唯一的區別在于，多路徑QUIC會在客戶端主動檢測每條物理鏈路的可用性并向服務端告知其物理網絡的變化.例如，當手機的WiFi連接斷開時，客戶端會通過移動網絡告知服務端放棄該網絡連接，從而避免服務端繼續使用其WiFi連接而造成不必要的丟包與重傳.而iOS內核中實現的MPTCP并不具備這樣的功能.由此可見，盡管多路徑QUIC在協議設計上已經取得了一定的進展，但是正如MPTCP所面臨的挑戰一樣[34-44]，如何設計出性能更好的擁塞控制算法并將其應用在QUIC上才是讓多路徑QUIC普及的關鍵因素.

2.2.2 用戶態與內核態

在操作系統中，出于安全性的考慮，地址空間被分為用戶空間和內核空間.一般來說，用戶程序，例如應用程序，運行在用戶空間；而系統程序，例如操作系統，運行在內核空間.用戶程序可以使用系統函數調用的方式進入內核空間.傳統意義上，傳輸層協議(例如TCP和UDP)均在Linux內核中實現，并且運行在內核空間.但是近年來的研究發現基于內核旁路[45]的用戶空間TCP可以達到比內核空間TCP更高的性能[46].因為應用程序工作于用戶空間，所以用戶空間TCP可以避免應用程序進行系統調用時的空間切換開銷，同時也能夠避免數據在內核空間和用戶空間之間的復制，最終達到加速應用程序運行速度的目的.另外，實現于用戶空間的網絡協議不受系統內核更新周期的限制，可以實現更快速的更新.

目前使用的最為廣泛的QUIC實現是在Chrome中的gQUIC，它工作于用戶空間并且仍處于迭代開發中.這樣的設計雖然可以允許協議的快速修改但是卻不能提供最好的性能，因為它的下層網絡使用了系統內核的UDP套接字，這樣既不能利用內核態程序的高優先級又不能像用戶空間TCP一樣避免空間切換的開銷.

Wang等人[29]在內核空間實現了gQUIC，用于在公平的環境下進行QUIC和TCP的性能對比.Duan等人[30]在用戶空間實現了包括UDP在內的gQUIC協議棧.他們測試了客戶端和服務端在短時間內進行快速握手的性能，發現使用內核旁路的QUIC能夠比Chrome多處理100倍以上的握手.

此外，也有研究者致力于加速QUIC數據包的處理.因為QUIC性能最大的瓶頸在于加密與解密算法的開銷，YouTube服務器在使用QUIC時的CPU開銷是TCP+TLS的2倍[5].所以對該過程的優化也是未來的一個研究方向.一種可能的方式是PixelVault[47]一樣，將加密解密相關的操作移到GPU上進行執行,從而降低CPU負載并加速數據包的處理.

2.3 QUIC的安全性

gQUIC的安全性與其傳輸層協議相綁定，這導致早期對QUIC安全性的研究主要針對QUIC整體進行.隨著IETF版本QUIC的推出，安全性相關的設計被從QUIC中剝離出來，并形成了TLS1.3.于是后續關于QUIC安全性的研究更傾向于對TLS1.3的安全性分析.在本節，我們首先列舉研究者對QUIC和TLS1.3安全性的建模分析，然后對已發現的安全漏洞進行介紹與總結.表2對QUIC安全性的相關工作進行了總結.

Table 2 Related Work on QUIC Security表2 QUIC安全性的相關工作

2.3.1 安全模型

Fischlin等人[2]提出了多階段公鑰交換(multi-stage key exchange)模型，用于描述QUIC的握手機制.利用這個模型，他們證明了QUIC握手機制的安全性，然而該模型無法很好地涵蓋握手之后的數據傳輸過程.也就是說，即便通信雙方使用了安全的包含身份驗證機制的加密協議用于數據加密，QUIC協議作為整體的安全性也無法得到保證.為了解決這個問題，他們提出了一種可以符合其安全模型的QUIC設計：QUICi.QUICi采用了更為復雜的密鑰生成機制，從而使得用于不同目的的密鑰之間相關性降低，增加了QUIC的安全性.

與Fischlin等人不同，Lychev等人[31]對未經修改的QUIC的安全性進行了更進一步的分析.針對QUIC和TLS1.3的0-RTT握手機制，他們提出了快速通信協議(quick communication protocols)的概念，用于描述在最終會話密鑰(final session key)生成之前先使用初始會話密鑰(initial session key)的做法,QUIC和TLS1.3均屬于快速通信協議.同時，他們提出了QACCE(quick authenticated and confidential channel establishment)模型，并使用該模型證明了QUIC連接建立過程和數據加密傳輸過程的安全性.

同時，Lychev等人[31]指出，基于最終會話密鑰的1-RTT握手和基于初始會話密鑰的0-RTT握手擁有不同的安全級別.前者可以確保通信雙方在攻擊者存在的情況下能夠生成一致的共享密鑰進行數據加密，并且提供前向安全性的保障.而后者可能因為攻擊者的存在而使通信雙方產生不一致的共享密鑰，導致數據的加密解密過程失敗.并且，0-RTT握手也不能保證前向安全性.關于0-RTT的安全問題我們會在2.3.2節進行更為詳細的介紹.

在此基礎上，Jager等人[4]從攻擊者的角度分別對QUIC和TLS1.3的安全性給出了分析.在TLS1.2中，Bleichenbacher攻擊及其變形能夠快速猜測出服務端的密鑰，從而破壞其安全性[49-50].在QUIC和TLS1.3中，因為移除了TLS1.2中導致安全性漏洞的PKCS#1 v1.5標準的支持，從而理論上不再受該類攻擊威脅.Jager等人的模擬攻擊結果表明，TLS1.3和QUIC極大地增加了攻擊者在進行攻擊過程中所消耗的時間，從而使得該種攻擊不再具有可行性.

2.3.2 前向安全性與0-RTT握手的安全問題

前向安全性是通信協議的一種安全屬性，它指的是長期使用的主密鑰泄露不會導致過去的會話密鑰泄露[32].其意義在于，前向安全性能夠保護過去進行的通訊不受密碼或密鑰在未來暴露的威脅.TLS1.2與QUICTLS1.3的1-RTT握手均很好地支持了前向安全性.但是QUICTLS1.3的0-RTT握手卻無法為通信雙方提供前向安全性[31].這是因為，0-RTT通信過程中使用的是初始會話密鑰，而這個密鑰是根據服務端的靜態配置生成的，未來如果該配置泄露，亦會導致0-RTT的密鑰也隨之泄露.

為了解決這個問題，Günther等人[48]通過在服務端的修改使得QUIC的0-RTT握手支持前向安全性.他們使用了一種特殊的密鑰設計：每當服務端用當前密鑰解密一個密文后，就將當前密鑰進行修改，新的密鑰可以像原來的密鑰一樣進行密文解析，唯一不同的是不能對已經解析過的密文再次進行解密，從而保證了前向安全性.

同時，該設計也會使得QUIC不再遭受重放攻擊的威脅.但是它帶來了性能上的挑戰，因為服務端的密鑰的復雜度會隨著時間的推移逐漸增加.為此，他們又提供了新的協議機制使得服務端可以每過一段時間將當前密鑰重置一次，從而降低密鑰的復雜度.

2.3.3 易遭受的攻擊

雖然許多研究工作證明了QUIC可以保證其傳輸的數據無法被惡意攻擊者所獲取，但是攻擊者仍然有能力對通信雙方的正常通信進行干擾，甚至影響客戶端或者服務端的正常運行.Lychev等人[31]列舉了QUIC易遭受的幾種安全攻擊.根據攻擊者是否處于客戶端和服務端之間的網絡路徑上，這些攻擊被分為了離線攻擊和在線攻擊.

1) Server Config重復攻擊，離線.類似于TCP的reset攻擊[51]，攻擊者可以通過嗅探獲得服務端的基本配置信息，然后利用這些配置信息并偽裝成服務端的IP地址向客戶端發送reset數據包，終止QUIC連接.

2) Crypto Stream Offset攻擊，離線.因為QUIC的握手數據包的大小也會被統計入Stream的偏移量(offset)，攻擊者可以在握手數據包后面附加一些字符串，導致接受方獲得錯誤的Stream偏移量數值，從而無法正確解析之后的數據包.

3) 連接ID篡改攻擊，在線.通過篡改握手過程中Client使用的連接ID，攻擊者可以使得通信雙方在很長的一段時間內(10 s)都認為連接已經成功，卻無法正常解析接收到的數據，并導致連接中斷.

4) Source-Address Token篡改攻擊，在線.與連接ID篡改攻擊相似，攻擊者可以通過篡改Source-Address Token的方式導致通信雙方無法正常解析對方收到的數據包.但是雙方在很長的一段時間內(10 s)都認為連接已經成功，直到主動中斷連接.

可以看出，QUIC在特定情況下無法提供有效的手段阻止在線和離線的攻擊者中斷一條QUIC連接.對于在線的攻擊者，它能夠讓通信雙方的連接處于閑置狀態一段時間，并且該行為無法立刻被通信雙方檢測到.而對于離線的攻擊者，它只需要獲取極少的連接相關信息便可以讓一條QUIC連接被迫中斷.

此外，McMillan等人[6]使用Ivy[52]對QUIC協議進行了詳細的定義，并通過自動生成的隨機攻擊者對QUIC各版本的安全漏洞進行探測.經過實驗，他們一共發現了QUIC運行過程中可能產生的27個錯誤.出于安全性的考慮，McMillan等人只公布了QUIC歷史版本中所發現的并且已經被解決的問題，并沒有對現存問題進行詳細介紹.

3 未來研究方向

盡管研究人員已經對QUIC在網絡傳輸性能測量、系統性能優化以及安全性分析等方面進行了大量工作.但是，目前已有的科研工作仍有進一步提高的地方：

1) 缺乏對IETF版本QUIC的分析.gQUIC只是QUIC的早期設計，屬于過渡期的協議.IETF作為一個負責開發和推廣互聯網標準的組織，它制定的QUIC協議才是未來QUIC的標準版本.盡管有許多開源組織致力于跟進IETF QUIC的每一個草稿并提供實現.但是目前IETF版本QUIC的許多設計細節并沒有確定，而且也沒有一個被廣泛使用的代碼實現.反之，gQUIC借助于Chrome的影響力已經被數十億人使用.因此，大部分的測量工作都是基于gQUIC進行的，學術界仍然缺少對IETF版本QUIC的性能的有效認識.

2) 軟件實現對分析結果的影響過大.盡管目前對QUIC的性能分析工作很多，但是大多局限于特定的實現，導致學術界對QUIC性能沒有一個統一的認識.在分析方法上，研究人員也普遍根據測量結果猜測造成差異的原因，沒有進行嚴格的控制變量法的對比.如果可以通過禁用QUIC某些特性的方法進行對比，就能更加深入地了解QUIC在不同網絡環境下表現好壞的根本原因.

3) CPU成為QUIC的性能瓶頸，導致無法充分利用帶寬.與現有的安全性協議相比，QUIC借用TLS1.3達到了更高的安全性.但是隨之而來的是加密解密復雜度的提高以及CPU負載的增加.這一點在手機等CPU性能相對薄弱的設備上尤為明顯.如何讓QUIC在現有的CPU性能下達到更高的帶寬是一個亟待解決的問題.

基于現有對QUIC的研究工作，我們分別從網絡傳輸性能、系統性能以及安全性3個方面預測了在未來可能有意義的QUIC的研究方向.

1) 現有的網絡測量結果表明，QUIC在大部分情況下表現出了比TCP+TLS更低的延時.同時，測量結果也顯示QUIC為了降低延時而進行的設計達到了預期效果.我們發現很多QUIC表現不如TCP的場景是由其不合適甚至錯誤的算法選擇造成的，而并非其協議本身的缺陷.造成這一問題的原因正是QUIC在算法選擇上的靈活性.因此，如果研究人員能夠歸納并總結QUIC在擁塞控制、丟包檢測等方面的可行算法，并對不同算法的適用環境進行分析，定能幫助QUIC更好地適應復雜的互聯網環境.

2) 雖然研究人員已經為提高QUIC的系統性能和降低數據包處理的延時提出了很多設計，但是目前并沒有一個真正有效且通用的策略.無論是內核旁路還是GPU都對硬件及其驅動有額外的要求，并且難以在移動設備上實現.一種可行的提高QUIC系統性能的思路是將QUIC的實現進行并行化.因為QUIC本身就是一個多路傳輸協議，如果能夠有效利用現代處理器的多個核心，必然能為QUIC的處理速度帶來進一步提升.但如何對QUIC協議進行解耦以使得它能夠將原本單線程的工作分配到不同的CPU核心上還有待研究人員解決.

3) QUIC的0-RTT握手無法保證前向安全性，而Günther等人[48]所提出的前向安全的0-RTT握手卻對系統性能有更大的消耗.另一方面，TLS1.3帶來的加密解密負荷使得QUIC對CPU的運算需求已經大大提高.所以，如何在安全性與計算開銷之間進行權衡是一個值得研究與討論的話題.另外，現有的研究發現QUIC連接容易被在線或者離線的攻擊者所打斷.研究人員應當為QUIC連接增加更多的保障機制從而幫助它更好地鑒別攻擊者的惡意行為，增加連接的安全性.

除了以上的研究方向外，我們注意到，已經有科研工作者將QUIC應用于HTTP以外的其他應用層協議，并且為系統性能帶來了不錯的提升[53].未來，如果能夠將QUIC應用于更多的應用層協議，例如WebRTC，FTP，DNS等，很有可能會讓它們在網絡傳輸性能、系統性能以及安全性方面獲得提升.

在5G領域，QUIC也有著不錯的應用前景.3GPP在5G標準中規定了其核心網將使用虛擬化技術實現其各組件的功能.不同組件之間將使用基于HTTP2的RESTful接口進行通信[54].但是鑒于QUIC在傳輸性能方面的提升，3GPP正在考慮使用QUIC替代HTTP2用于核心網各組件之間的數據通信[55].除此之外，因為5G相較于上一代無線技術(4G)提供了更低的無線通信延時[56]，所以它使得通過蜂窩網絡為用戶提供極低延時的網絡服務成為了可能.而QUIC在握手延時方面的優勢，尤其是0-RTT握手，將有助于網絡服務更進一步地降低網絡延時，提升用戶體驗.在我們的前期工作中，我們提出了一個基于QUIC的域名解析系統：Artemis[57].Artemis借助于QUIC在移動性上的優勢，實現了比傳統DNS更低的域名解析延時.我們相信，未來將會有更多的基于5G以及QUIC實現的低延時服務出現在云計算、邊緣計算以及物聯網等領域.

4 結 論

QUIC作為一個新的傳輸層協議，它在設計上針對TCP的不足進行了很多優化.它提供的多路傳輸、快速握手等新特性使得它和TCP相比在理論上可以獲得更低的數據傳輸延時.現有測量工作表明，QUIC在大部分情況下的確能比TCP達到更低的傳輸延時，但是仍然有部分情況下QUIC的表現不如TCP.這些QUIC性能表現較差的場景往往是擁塞算法的選擇、服務器部署等外部因素造成的，而非QUIC本身的設計缺陷.因此，QUIC的軟件實現仍然有很大的進步空間.在安全性方面，基于TLS1.3的QUIC一方面犧牲了一定的計算資源為用戶提供了比TLS1.2更高的安全性，另一方面以犧牲前向安全性為代價換來了更低的握手延時.但總體來說，TLS1.3還是很好地保障了數據傳輸的安全性.此外，許多在TCP上未被解決的問題在QUIC上也依然存在，仍然有很多后續工作等待著科研工作者們繼續探索.

在QUIC的應用上，隨著5G等新興應用場景的出現以及HTTP3標準的制定，相信將來會有越來越多的基于QUIC的網絡服務的出現.如何充分利用QUIC的特性提升網絡服務的服務質量有待工業界和學術界的共同探索.