李學(xué)兵 陳 陽 周孟瑩 王 新

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

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

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

1 QUIC概述

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

1.1 QUIC協(xié)議模型

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

Fig. 1 QUIC protocol architecture圖1 QUIC協(xié)議模型

1.2 QUIC的協(xié)議特性

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

1.2.1 多路傳輸

QUIC通過對多路傳輸?shù)闹С?，解決了TCP中的隊頭阻塞問題[22].

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

Fig. 2 Multiplexing vs singleplexing圖2 多路傳輸與單路傳輸?shù)膶Ρ?/p>

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

1.2.2 握手協(xié)議

QUIC設(shè)計了自己的握手協(xié)議，并達(dá)到了比TCP+TLS更低的握手延時.

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

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

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

Fig. 4 Category of QUIC-related studies圖4 QUIC相關(guān)工作的分類

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

2 研究現(xiàn)狀分析

圖4對現(xiàn)有的QUIC相關(guān)研究工作進(jìn)行了分類與總結(jié).主要包括3個方面：QUIC網(wǎng)絡(luò)傳輸性能的測量、QUIC性能的優(yōu)化以及QUIC安全性的分析與改進(jìn).

在傳輸性能方面，研究人員最關(guān)心的是QUIC和TCP+TLS相比會有多大的性能提升，包括在不同網(wǎng)絡(luò)環(huán)境和不同傳輸內(nèi)容下的表現(xiàn).在QUIC的性能優(yōu)化方面，研究者一方面為QUIC協(xié)議帶來了諸如多路徑等新特性，另一方面在系統(tǒng)實現(xiàn)中使用內(nèi)核旁路等新技術(shù)達(dá)到了比現(xiàn)有系統(tǒng)更高的IO吞吐率.在安全性方面，研究人員使用多種方法對QUIC的安全性進(jìn)行了建模分析，同時也指出了QUIC存在的一些安全隱患，并給出了相應(yīng)的改進(jìn)建議.

2.1 QUIC的傳輸性能

自Google第1次發(fā)布QUIC以來，研究人員便對QUIC的網(wǎng)絡(luò)傳輸性能產(chǎn)生了濃厚的興趣.本節(jié)列舉了近年學(xué)術(shù)界在QUIC性能分析上的工作.考慮到網(wǎng)絡(luò)協(xié)議性能的分析離不開具體的應(yīng)用場景，我們根據(jù)不同的應(yīng)用場景對相關(guān)工作分為了2類，分別是網(wǎng)頁瀏覽和視頻傳輸.表1對QUIC性能分析的相關(guān)工作進(jìn)行了總結(jié).

Table 1 Related Work on QUIC Performance Analysis表1 QUIC性能分析的相關(guān)工作

2.1.1 網(wǎng)頁瀏覽

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

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

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

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

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

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

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

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

2.1.2 視頻傳輸

視頻傳輸是互聯(lián)網(wǎng)中另一個重要的應(yīng)用.Cisco的報告表明，在2014年，視頻流量占整個移動網(wǎng)絡(luò)流量的55%.并且這一數(shù)據(jù)有望在2019年達(dá)到72%[36].在視頻領(lǐng)域，研究人員普遍使用緩存等待率來衡量視頻的服務(wù)質(zhì)量，也就是用戶等待視頻緩存的時間占總播放時間的比例.

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

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

2.2 QUIC的性能優(yōu)化

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

2.2.1 多路徑QUIC

多路徑是指允許一條傳輸層連接同時使用多條物理網(wǎng)絡(luò)鏈路的技術(shù).其優(yōu)勢在于，可以同時使用多個物理網(wǎng)絡(luò)從而增加有效網(wǎng)絡(luò)帶寬.例如，手機用戶可以同時使用蜂窩網(wǎng)絡(luò)和WiFi，電腦用戶可以同時使用以太網(wǎng)和WiFi.多路徑在TCP上已有大量研究[37-38]，其中MPTCP[39]已經(jīng)作為網(wǎng)絡(luò)協(xié)議標(biāo)準(zhǔn)被IETF收錄，并且被Linux內(nèi)核所支持.

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

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

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

2.2.2 用戶態(tài)與內(nèi)核態(tài)

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

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

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

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

2.3 QUIC的安全性

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

Table 2 Related Work on QUIC Security表2 QUIC安全性的相關(guān)工作

2.3.1 安全模型

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

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

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

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

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

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

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

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

2.3.3 易遭受的攻擊

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

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

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

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

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

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

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

3 未來研究方向

盡管研究人員已經(jīng)對QUIC在網(wǎng)絡(luò)傳輸性能測量、系統(tǒng)性能優(yōu)化以及安全性分析等方面進(jìn)行了大量工作.但是，目前已有的科研工作仍有進(jìn)一步提高的地方：

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

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

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

基于現(xiàn)有對QUIC的研究工作，我們分別從網(wǎng)絡(luò)傳輸性能、系統(tǒng)性能以及安全性3個方面預(yù)測了在未來可能有意義的QUIC的研究方向.

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

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

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

除了以上的研究方向外，我們注意到，已經(jīng)有科研工作者將QUIC應(yīng)用于HTTP以外的其他應(yīng)用層協(xié)議，并且為系統(tǒng)性能帶來了不錯的提升[53].未來，如果能夠?qū)UIC應(yīng)用于更多的應(yīng)用層協(xié)議，例如WebRTC，F(xiàn)TP，DNS等，很有可能會讓它們在網(wǎng)絡(luò)傳輸性能、系統(tǒng)性能以及安全性方面獲得提升.

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

4 結(jié) 論

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

在QUIC的應(yīng)用上，隨著5G等新興應(yīng)用場景的出現(xiàn)以及HTTP3標(biāo)準(zhǔn)的制定，相信將來會有越來越多的基于QUIC的網(wǎng)絡(luò)服務(wù)的出現(xiàn).如何充分利用QUIC的特性提升網(wǎng)絡(luò)服務(wù)的服務(wù)質(zhì)量有待工業(yè)界和學(xué)術(shù)界的共同探索.