季明辰，任勇毛，張運棟，周慧娟，周旭＊，周艷芳

1.北方工業(yè)大學(xué)，北京 100144

2.中國科學(xué)院計算機網(wǎng)絡(luò)信息中心，北京 100083

3.中國科學(xué)院大學(xué)，北京 100049

4.交通運輸部公路科學(xué)研究院，北京 100088

引 言

隨著科技的不斷發(fā)展，互聯(lián)網(wǎng)時代的崛起促進通信業(yè)快速發(fā)展，數(shù)據(jù)通信已進入大數(shù)據(jù)時代。大數(shù)據(jù)指大量數(shù)據(jù)信息，具有數(shù)據(jù)種類繁多、數(shù)據(jù)處理速度快以及數(shù)據(jù)信息存儲量大等諸多特點。相較于以往的交通數(shù)據(jù)信息，交通大數(shù)據(jù)具有以下幾個方面的特點[1]：第一，交通數(shù)據(jù)信息量大，如道路監(jiān)控高清視頻數(shù)據(jù)、城市出租車行車軌跡數(shù)據(jù)等，且信息可以長時間保存；第二，交通數(shù)據(jù)信息具有極強的時效性，對數(shù)據(jù)信息的處理速度要求很高；第三，交通數(shù)據(jù)來源途徑廣泛，具有多種不同的信息類型。

云計算、大數(shù)據(jù)、移動計算和物聯(lián)網(wǎng)的興起，給各行各業(yè)注入發(fā)展的新鮮血液。作為物聯(lián)網(wǎng)分支在汽車領(lǐng)域的發(fā)展，車聯(lián)網(wǎng)（Internet of Vehicle，IoV）應(yīng)運而生。車聯(lián)網(wǎng)是以行駛中的車輛為信息感知對象，借助新一代信息通信技術(shù)，實現(xiàn)車與X（即車與人、車、路、環(huán)境）之間的網(wǎng)絡(luò)連接[2]，提升車輛整體的智能駕駛水平。車聯(lián)網(wǎng)為用戶提供安全、舒適、智能、高效的駕駛感受與交通服務(wù)，同時提高交通運行效率，提升社會交通服務(wù)的智能化水平。車聯(lián)網(wǎng)利用傳感技術(shù)感知車輛狀態(tài)信息，借助無線通信網(wǎng)絡(luò)與現(xiàn)代智能信息處理技術(shù)實現(xiàn)交通智能化管理，以及交通信息服務(wù)的智能決策和車輛的智能化控制[3]，由于此過程產(chǎn)生大量交通通信數(shù)據(jù)，并且由于其對時效性的高要求，導(dǎo)致交通大數(shù)據(jù)傳輸面臨很大挑戰(zhàn)。應(yīng)對交通大數(shù)據(jù)帶來的挑戰(zhàn)，如何設(shè)計高速的網(wǎng)絡(luò)傳輸系統(tǒng)，實現(xiàn)交通數(shù)據(jù)高時效性、高可靠性的傳輸，是個亟待解決的問題。

1 相關(guān)工作

1.1 交通大數(shù)據(jù)傳輸

交通大數(shù)據(jù)指通過快速通信網(wǎng)絡(luò)、各類傳感器等將交通系統(tǒng)中的人、車、路等信息發(fā)送至控制端，并將控制端反饋傳遞至相應(yīng)控制設(shè)備，這類傳感器主要有攝像頭、車票識別裝置、人臉識別裝置、地質(zhì)監(jiān)控裝置等[4]。

交通大數(shù)據(jù)具有數(shù)據(jù)量大，數(shù)據(jù)來源廣泛的特點，車聯(lián)網(wǎng)通信技術(shù)的發(fā)展使這一特點不斷加深與強化。目前，主流的車聯(lián)網(wǎng)通信技術(shù)路線有兩種，一是專門用于短距離通信的DSRC，二是基于蜂窩網(wǎng)的C-V2X通信[5]。其中，C-V2X 通信屬于我國主導(dǎo)的車聯(lián)網(wǎng)通信技術(shù)路線[6]，由于國家長久以來的支持，C-V2X 通信技術(shù)不斷完善，解決了DSRC 存在的通信空間范圍小、可擴展性差以及缺乏進一步發(fā)展空間等問題[7]，但仍產(chǎn)生了數(shù)據(jù)量大、類型繁雜的交通數(shù)據(jù)。

交通大數(shù)據(jù)相較于其他數(shù)據(jù)，對傳輸時間更為敏感，對傳輸速率要求更高。張婷在車聯(lián)網(wǎng)環(huán)境感知方面，提出一種面向城市空氣質(zhì)量采集的車聯(lián)網(wǎng)監(jiān)測數(shù)據(jù)的傳輸方法[8]。該方法基于Crowd-Sensing（群智感知），通過編碼機制設(shè)計冗余策略，保證了數(shù)據(jù)傳輸?shù)目煽啃?；根?jù)路由切換思想，將編碼機制和路由設(shè)計結(jié)合，以最小化延遲為目標(biāo)進行基于概率的路由決策，降低了信息傳輸時延，提高了數(shù)據(jù)傳輸?shù)乃俾省?/p>

交通大數(shù)據(jù)由于直接面向交通現(xiàn)實環(huán)境，需要在保證傳輸速率的基礎(chǔ)上提高傳輸可靠性。馬小婷等[9]采用MEC（Mobile Edge Computing，移動邊緣計算 ）車聯(lián)網(wǎng)協(xié)作傳輸，在5G 車聯(lián)網(wǎng)中車輛編隊以及基于UAV（Unmanned Aerial Vehicle，無人機）輔助的兩個典型協(xié)作應(yīng)用場景下，實現(xiàn)了低時延和高可靠性的車聯(lián)網(wǎng)數(shù)據(jù)通信，解決了車輛高速移動過程中，網(wǎng)絡(luò)傳輸?shù)目煽啃院托氏陆档膯栴}。

總之，車聯(lián)網(wǎng)等交通大數(shù)據(jù)傳輸對網(wǎng)絡(luò)性能提出了高吞吐、低時延、高可靠等很高的要求。針對這一需求，本文探索將新型網(wǎng)絡(luò)傳輸協(xié)議應(yīng)用于交通大數(shù)據(jù)傳輸，以提高交通大數(shù)據(jù)傳輸效率，滿足交通大數(shù)據(jù)傳輸高速、實時、可靠等傳輸要求。

1.2 QUIC（Quick UDP Internet Connection）傳輸協(xié)議

近年來，傳統(tǒng)的FTP（文件傳輸協(xié)議）已經(jīng)不能滿足人們?nèi)找嬖鰪姷膶W(wǎng)絡(luò)傳輸性能的要求。傳統(tǒng)的FTP 主要基于TCP 傳輸協(xié)議，TCP 協(xié)議面向連接，通信時會先建立穩(wěn)定的連接，為數(shù)據(jù)傳輸提供可靠的服務(wù)，成為當(dāng)前文件傳輸應(yīng)用最為廣泛的協(xié)議之一。TCP 協(xié)議雖然可靠性高，但傳輸速率慢、占用系統(tǒng)資源較多，因此通常音頻、視頻和普通數(shù)據(jù)在傳送時多使用資源占用小、傳輸速度快、實時性高的UDP 傳輸協(xié)議。UDP 協(xié)議與TCP 協(xié)議同為Internet 傳輸層的主要協(xié)議，兩者互為補充，但UDP協(xié)議無連接，并不能保證數(shù)據(jù)的可靠交付，因此使用UDP 協(xié)議會導(dǎo)致文件傳輸時可能產(chǎn)生較多丟包，且不能保證數(shù)據(jù)順序。

在Google 提出QUIC（Quick UDP Internet Connection）傳輸協(xié)議后[10]，國外有關(guān)數(shù)據(jù)傳輸?shù)难芯恐?，學(xué)術(shù)領(lǐng)域?qū)UIC 這一新型傳輸協(xié)議的研究一直是一個熱點。QUIC 協(xié)議具有低握手延遲、多路復(fù)用、鏈接遷移等傳輸機制。低握手延遲指QUIC協(xié)議較傳統(tǒng)TCP 協(xié)議具有更少的握手RTT（Round-Trip Time，往返時延），即服務(wù)器與客戶端首次建立QUIC 連接只需要客戶端發(fā)送連接請求，服務(wù)器回復(fù)連接配置一次RTT，且后續(xù)連接可通過歷史連接配置實現(xiàn)0RTT 握手；多路復(fù)用指QUIC 連接建立后，同一域名的多條數(shù)據(jù)能夠在一個連接內(nèi)傳輸，這些傳輸相互獨立、互不依賴，避免了某一數(shù)據(jù)包的丟失導(dǎo)致后續(xù)數(shù)據(jù)包等待其重傳而造成的隊頭阻塞現(xiàn)象；鏈接遷移指QUIC 上層鏈路使用Connection id作為唯一標(biāo)識，客戶端IP 或端口的改變，不會影響Connection id，故不會導(dǎo)致重新握手而增加時延。

相較于TCP，QUIC 協(xié)議具有更快的傳輸速率以及更安全穩(wěn)定的傳輸過程。同時，QUIC 協(xié)議基于UDP 協(xié)議部署，在全球范圍內(nèi)可實現(xiàn)快速普及。在SIGCOMM，IMC，WWW，CoNEXT，CCS 等國際頂尖的網(wǎng)絡(luò)、安全領(lǐng)域會議上，已經(jīng)發(fā)表了一系列關(guān)于QUIC 的傳輸性能、安全性等方面的研究成果[11-14]。在工業(yè)界，QUIC 也已經(jīng)得到了廣泛的應(yīng)用與部署。Google 在它的產(chǎn)品（Chrome 瀏覽器、Google Cloud 等）中最早提供了對QUIC 的支持。此外，一些內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）服務(wù)商，例如Akamai 和 Cloudflare，也已經(jīng)對QUIC 提供了支持。

QUIC 的提出最初主要針對WEB 應(yīng)用。目前，由于具有高吞吐率、低時延與高可靠性等優(yōu)勢，QUIC 已成為一大研究熱點，并已被應(yīng)用到視頻傳輸?shù)榷喾N應(yīng)用。但是，國內(nèi)外尚未有將QUIC 應(yīng)用于文件傳輸?shù)难芯亢彤a(chǎn)品報道。而QUIC 的高吞吐率、低時延和高可靠性等優(yōu)勢有望解決車聯(lián)網(wǎng)等交通大數(shù)據(jù)傳輸?shù)母咚?、實時、可靠等傳輸要求，因此，本文提出將QUIC 應(yīng)用于面向交通大數(shù)據(jù)等領(lǐng)域的文件傳輸，利用QUIC 的快速、可靠與易部署性等優(yōu)勢，設(shè)計基于QUIC 的高速文件傳輸系統(tǒng)。相較于傳統(tǒng)文件傳輸系統(tǒng)，該系統(tǒng)能夠應(yīng)對交通大數(shù)據(jù)傳輸?shù)奶魬?zhàn)，試圖實現(xiàn)交通大數(shù)據(jù)快速、低時延、高可靠性傳輸。

2 高速文件傳輸系統(tǒng)設(shè)計與實現(xiàn)

2.1 系統(tǒng)結(jié)構(gòu)設(shè)計

高速文件傳輸系統(tǒng)分為前端的UI 界面和后端的連接建立、數(shù)據(jù)處理與數(shù)據(jù)傳輸，如圖1所示。

圖1 系統(tǒng)架構(gòu)圖Fig.1 System architecture diagram

系統(tǒng)主要對網(wǎng)絡(luò)上層，即應(yīng)用層、表示層、會話層與傳輸層進行設(shè)計，并適配網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層與物理層。具體設(shè)計情況如下：

（1）系統(tǒng)操作界面是系統(tǒng)前端部分，分為客戶端操作界面和服務(wù)器操作界面?？蛻舳瞬僮鹘缑嬷?，用戶通過配置網(wǎng)絡(luò)參數(shù)與服務(wù)器進行連接，成功連接服務(wù)器后，能夠按照需求進行單個或多個不同大小、不同類型文件的上傳、下載，且整個過程的操作均可得到反饋信息；服務(wù)器操作界面中，用戶可以配置網(wǎng)絡(luò)連接參數(shù)，開啟服務(wù)器進行監(jiān)聽，同時可以查看服務(wù)器內(nèi)現(xiàn)有的文件，對于客戶端的上傳和下載請求及相應(yīng)的內(nèi)部文件操作，服務(wù)器均進行實時顯示。

（2）系統(tǒng)表示層包括單文件傳輸、多文件傳輸、文件分塊并行傳輸三個模塊。單文件傳輸模塊是簡單的基于QUIC 協(xié)議的文件上傳或下載，只用到QUIC 連接的單個stream 傳輸；多文件傳輸模塊是基于QUIC 多流的多個文件的上傳或下載，對需要傳輸?shù)亩鄠€文件內(nèi)容轉(zhuǎn)換為二進制切片，并將各個文件內(nèi)容的切片分別放入stream 模塊創(chuàng)建的各個stream 中進行傳輸；文件分塊并行傳輸模塊將拆分模塊處理后的各個小文件與其他需要傳輸?shù)男∮陂撝荡笮〉奈募?，按照多文件傳輸模塊的方式并行傳輸，保證文件聚合模塊的執(zhí)行。

（3）數(shù)據(jù)會話層包括文件壓縮模塊、文件拆分模塊和文件聚合模塊。文件壓縮模塊在發(fā)送端將需要傳輸?shù)奈募M行g(shù)zip 壓縮，并在接收端將壓縮文件解壓還原；文件拆分模塊作用于發(fā)送端，對需要傳輸?shù)奈募M行簡要篩選，略過小于閾值的文件，將篩選出的大于閾值的文件拆分為多個閾值大小的小文件，并逐一編號；文件聚合模塊作用于接收端，對接收到的文件按照編號進行篩選，略過無編號的小文件，將有編號的拆分后的文件依序進行整合，形成傳輸需求的大文件。

（4）系統(tǒng)傳輸層包括建立客戶端與服務(wù)器的QUIC 連接和stream（傳輸數(shù)據(jù)流）模塊兩個部分。其中stream 模塊執(zhí)行stream 流的創(chuàng)建、傳輸與關(guān)閉，且多個文件傳輸或大文件分塊并行傳輸將對多個stream 進行操作。

2.2 文件傳輸機制

系統(tǒng)文件傳輸機制分為文件上傳流程與文件下載兩個流程，由服務(wù)器、傳輸層、客戶端三個對象交互執(zhí)行。

文件上傳流程如圖2所示，分別從服務(wù)器、客戶端和傳輸層三個方面執(zhí)行。傳輸層方面，在QUIC連接內(nèi)，通過系統(tǒng)stream 模塊建立數(shù)據(jù)流，其中連接狀態(tài)和接收信號建立單數(shù)據(jù)流傳輸，文件內(nèi)容數(shù)據(jù)建立多數(shù)據(jù)流并行傳輸，下文流程說明內(nèi)將不再闡述。服務(wù)器與客戶端交互方面，有如下執(zhí)行流程：

圖2 文件上傳流程圖Fig.2 File upload flowchart

（1）服務(wù)器開啟后持續(xù)監(jiān)聽；

（2）客戶端發(fā)送連接狀態(tài)進行QUIC 連接；

（3）服務(wù)器判斷連接狀態(tài)為上傳后，讀取連接信息內(nèi)上傳文件屬性，并創(chuàng)建文件，發(fā)送接收信號；

（4）客戶端收到服務(wù)器接收信號后，分別執(zhí)行文件壓縮模塊、文件拆分模塊，并將文件內(nèi)容數(shù)據(jù)并行發(fā)送；

（5）服務(wù)器接收到文件內(nèi)容數(shù)據(jù)后，執(zhí)行文件聚合模塊，完成文件聚合，執(zhí)行文件解壓縮模塊，解壓文件，實現(xiàn)文件上傳。

文件下載流程如圖3所示，同樣分別從服務(wù)器、客戶端和傳輸層三個方面執(zhí)行。傳輸層與文件上傳流程執(zhí)行內(nèi)容一致，這里不作贅述。服務(wù)器與客戶端交互方面，有如下執(zhí)行流程：

圖3 文件下載流程圖Fig.3 File download flow chart

（1）服務(wù)器開啟后持續(xù)監(jiān)聽；

（2）客戶端發(fā)送連接狀態(tài)進行QUIC 連接；

（3）服務(wù)器判斷連接狀態(tài)為下載后，讀取連接信息內(nèi)文件名，并查詢相應(yīng)文件，如查詢未果，則向客戶端反饋無此文件；如查詢成功，則執(zhí)行文件壓縮模塊壓縮文件，執(zhí)行文件拆分模塊拆分文件后并行傳輸；

（4）客戶端接收到文件內(nèi)容數(shù)據(jù)后，執(zhí)行文件聚合模塊聚合文件，執(zhí)行文件解壓縮模塊解壓文件，實現(xiàn)文件下載。

2.3 系統(tǒng)功能模塊實現(xiàn)

2.3.1 QUIC 連接的實現(xiàn)

系統(tǒng)調(diào)用github 上的quic-go 庫實現(xiàn)基于QUIC協(xié)議的連接。1.3 中提到，QUIC 協(xié)議具有多路復(fù)用機制，即QUIC 連接包含Stream 和Connection 兩種級別的流量控制，一個Connection 連接內(nèi)可以進行多條獨立Stream 傳輸，數(shù)據(jù)流依托Stream 控制，故握手后建立的Connection 連接并不能保證數(shù)據(jù)流傳輸，故系統(tǒng)設(shè)計stream 模塊進行流量控制，即：服務(wù)器開啟連接監(jiān)聽，監(jiān)聽到客戶端連接后，與之建立Connection 連接；Connection 連接建立后不會立即傳輸數(shù)據(jù)，此時服務(wù)器會持續(xù)監(jiān)聽stream；客戶端在Connection 連接后，建立stream，并通過連接鏈路進行發(fā)送；服務(wù)器監(jiān)聽到stream 后，進行數(shù)據(jù)的接收。

2.3.2 傳輸模塊的實現(xiàn)

系統(tǒng)傳輸模塊是系統(tǒng)傳輸層的核心。通過該模塊，系統(tǒng)可以在QUIC 連接的基礎(chǔ)上，對QUIC 傳輸流stream 進行操作，實現(xiàn)單文件傳輸、多文件傳輸以及文件分塊并行傳輸。

單文件與多文件傳輸算法如圖4所示?？蛻舳瞬糠郑嚎蛻舳伺c服務(wù)器進行QUIC 連接，并為每條上傳或下載請求創(chuàng)建文件流；若請求為上傳，則分別發(fā)送上傳連接狀態(tài)、上傳文件名以及文件內(nèi)容；若請求為下載，則發(fā)送下載連接狀態(tài)、文件名，創(chuàng)建文件，并將后續(xù)接收的文件內(nèi)容寫入。

圖4 單文件與多文件傳輸算法Fig.4 Single file and multiple file transfer algorithms

服務(wù)器部分：服務(wù)器實時監(jiān)聽，接收到文件流后，若判斷客戶端連接為上傳，則根據(jù)文件名創(chuàng)建文件，并將文件內(nèi)容寫入；若判斷客戶端連接為下載，則檢索文件名，找到目標(biāo)文件后發(fā)送文件內(nèi)容。

文件分塊并行傳輸算法如圖5所示。客戶端部分：客戶端與服務(wù)器進行QUIC 連接；若請求為上傳，則發(fā)送上傳連接狀態(tài)、文件名；判斷文件大小，若小于閾值，則調(diào)用單文件與多文件傳輸模塊，若大于閾值，則調(diào)用拆分模塊拆分文件，并分別發(fā)送文件分塊數(shù)、文件大小、塊文件名以及文件內(nèi)容；若請求為下載，判斷出文件大小大于閾值，則發(fā)送下載連接狀態(tài)、文件名，并調(diào)用聚合模塊，將后續(xù)接收到的各塊文件整合出主文件。

圖5 文件分塊并行傳輸算法Fig.5 File block parallel transmission algorithm

服務(wù)器部分：服務(wù)器實時監(jiān)聽，接收到文件流后，若判斷客戶端連接為上傳，則調(diào)用聚合模塊，將接收到的各塊文件整合為主文件；若判斷客戶端連接為下載，則檢索文件名，找到目標(biāo)文件后，調(diào)用拆分模塊將其拆分，并發(fā)送文件分塊數(shù)、文件大小、塊文件名以及文件內(nèi)容。

2.3.3 文件處理模塊的實現(xiàn)

文件處理模塊包括壓縮/ 解壓縮模塊和拆分/ 聚合模塊。其中，系統(tǒng)壓縮/ 解壓縮模塊通過compress/gzip 包對文件進行傳輸前壓縮，傳輸后解壓，以提升文件傳輸效率；拆分/聚合模塊包括拆分子模塊與聚合子模塊，二者分別作用在文件的發(fā)送端和接收端，對大文件進行拆分與聚合，實現(xiàn)拆分后的各文件并行傳輸與整合效果，提高傳輸速率。

拆分與聚合子模塊算法如圖6和圖7所示。拆分算法為：通過文件大小和閾值計算出文件拆分塊數(shù)，將對應(yīng)文件內(nèi)容讀取至閾值大小緩沖區(qū)，并寫入對應(yīng)的塊文件中。聚合算法為：通過文件大小和閾值計算出文件拆分塊數(shù)，創(chuàng)建等同數(shù)量的文件數(shù)并將接收到的文件內(nèi)容按照編號循環(huán)寫入各塊文件，判斷完全寫入后，將各塊文件內(nèi)容寫入主文件并刪除各塊文件。

圖6 拆分子模塊算法Fig.6 Split module algorithm

圖7 聚合子模塊算法Fig.7 Aggregation module algorithm

2.3.4 界面設(shè)計與實現(xiàn)

系統(tǒng)在Github 上調(diào)用andlabs/ui 開源庫，使用Go 語言開發(fā)了Windows 桌面GUI 程序，實現(xiàn)服務(wù)器和客戶端操作界面的設(shè)計。服務(wù)器界面用于實現(xiàn)網(wǎng)絡(luò)連接、文件查看與傳輸過程顯示，客戶端網(wǎng)絡(luò)配置子界面用于網(wǎng)絡(luò)配置與連接，服務(wù)器界面和客戶端界面如圖8和圖9所示。

圖8 服務(wù)器界面Fig.8 Server interface

圖9 客戶端界面Fig.9 Client interface

客戶端文件下載子界面和客戶端文件上傳子界面用于進行文件的上傳和下載以及傳輸過程顯示。

3 實驗及結(jié)果分析

為了對系統(tǒng)傳輸進行性能評估，搭建了廣域網(wǎng)環(huán)境下實驗平臺模擬復(fù)雜交通大數(shù)據(jù)傳輸環(huán)境，并將車聯(lián)網(wǎng)數(shù)據(jù)文件作為交通大數(shù)據(jù)文件的體現(xiàn)進行傳輸，測試了基于QUIC 協(xié)議的本系統(tǒng)傳輸速率和傳統(tǒng)的基于TCP 協(xié)議的文件傳輸速率，通過二者對比，得出系統(tǒng)性能測試結(jié)果。

3.1 實驗環(huán)境

系統(tǒng)客戶端設(shè)置在位于北京的PC 上，服務(wù)器設(shè)置在位于上海的騰訊云服務(wù)器上。實驗采用iperf3工具測試系統(tǒng)環(huán)境的網(wǎng)絡(luò)鏈路最大可用帶寬約為40.9Mbps，鏈路往返時延RTT 約為30ms，并采用clumsy 工具仿真復(fù)雜廣域網(wǎng)環(huán)境，額外增加時延和丟包。實驗分別測試了不同時延、丟包及不同時延與丟包組合時兩種協(xié)議的傳輸性能，梯度時延和梯度丟包率的測試文件大小為2G，時延與丟包率組合的測試文件大小為500M。

3.2 實驗內(nèi)容與結(jié)論

（1）保持帶寬和丟包率不變，使用clumsy 設(shè)置0ms、30ms、50ms、100ms、150ms、200ms 的典型時延，測試丟包率對于TCP 與QUIC 的文件傳輸速率影響。測試每次傳輸?shù)膫鬏斔俾嗜鐖D10所示。

圖10 梯度時延下兩種協(xié)議傳輸速率Fig.10 Transmission rate of two protocols under different delays

從測試結(jié)果可以看出，低網(wǎng)絡(luò)時延的情況下，QUIC 協(xié)議與TCP 協(xié)議傳輸效率相當(dāng)。隨著時延的增加，QUIC 協(xié)議傳輸速率受影響較小，TCP 協(xié)議傳輸速率則開始降低，此時QUIC 協(xié)議傳輸速率高于TCP 傳輸協(xié)議。

（2）保持帶寬和時延不變，設(shè)置0%、1%、3%、5%、8%、10%的典型丟包率，測試丟包率對于TCP與QUIC 的文件傳輸速率影響。測試每次傳輸?shù)膫鬏斔俾式Y(jié)果如圖11所示。

圖11 梯度丟包率下兩種協(xié)議傳輸速率Fig.11 Two protocol transmission rates under different packet loss rates

從測試結(jié)果可以看出，隨著丟包率的增加，QUIC 協(xié)議傳輸速率受到的影響小于TCP 傳輸速率受到的影響。QUIC 協(xié)議在丟包率增加時，傳輸速率高于TCP 傳輸協(xié)議。

（3）保持帶寬、丟包率和時延不變，使用clumsy 設(shè)置50ms、1%丟包率，100ms、1%丟包率，50ms、5%丟包率，100ms、5%丟包率，50ms、8%丟包率，100ms、8%丟包率的組合，測試時延與丟包率組合對TCP 與QUIC 的文件傳輸速率影響。測試每次傳輸?shù)膫鬏斔俾嗜鐖D12所示。

圖12 梯度時延丟包率組合下兩種協(xié)議傳輸速率Fig.12 Transmission rate of two protocols under different combinations of delay and packet loss rate

從測試結(jié)果可以看出，在梯度時延與丟包率組合環(huán)境下，QUIC 協(xié)議的文件傳輸速率高于TCP 協(xié)議的文件傳輸速率，且該情況在高丟包率情況下尤為明顯。

4 結(jié)論與展望

面對交通大數(shù)據(jù)文件傳輸對網(wǎng)絡(luò)傳輸性能的挑戰(zhàn)，本文設(shè)計與實現(xiàn)了一個基于QUIC 傳輸協(xié)議的高速文件傳輸系統(tǒng)。針對大文件傳輸問題，本文利用QUIC 傳輸?shù)亩鄠€傳輸流互相獨立的特點，提出了文件分塊后于QUIC 多流內(nèi)并行傳輸?shù)膫鬏敊C制，有效提升了文件傳輸效率，解決了車聯(lián)網(wǎng)數(shù)據(jù)文件難以大量、高速、可靠傳輸?shù)膯栴}，緩解了當(dāng)前大數(shù)據(jù)帶來的網(wǎng)絡(luò)傳輸壓力。最后，在分塊傳輸?shù)幕A(chǔ)上，還開發(fā)了文件壓縮、文件聚合等功能，進一步提高了文件傳輸速率。

課題創(chuàng)新之處在于采用QUIC 協(xié)議進行交通大數(shù)據(jù)文件傳輸，利用QUIC 多流復(fù)用的特性，提出了數(shù)據(jù)分塊后于多個互相獨立的傳輸流內(nèi)并行傳輸?shù)姆椒?，相較于傳統(tǒng)的采用TCP 的傳輸，提升了數(shù)據(jù)的傳輸速度，同時保證了傳輸數(shù)據(jù)的獨立性，避免了高丟包率環(huán)境下，TCP 出現(xiàn)的隊頭阻塞問題。本系統(tǒng)一定程度上提高了交通大數(shù)據(jù)傳輸效率，但系統(tǒng)測試環(huán)節(jié)還沒有聚焦到具體的車聯(lián)網(wǎng)應(yīng)用，下一步的工作應(yīng)針對某一類車聯(lián)網(wǎng)應(yīng)用進行實驗分析。同時，車聯(lián)網(wǎng)是移動網(wǎng)絡(luò)，組網(wǎng)方式異構(gòu)多源，接下來還應(yīng)在文件傳輸系統(tǒng)中考慮車聯(lián)網(wǎng)的移動性與多源性。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。