面向交通大數(shù)據(jù)的高速文件傳輸系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

季明辰，任勇毛，張運(yùn)棟，周慧娟，周旭＊，周艷芳

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

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

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

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

引 言

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

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

1 相關(guān)工作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 文件傳輸機(jī)制

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

文件上傳流程如圖2所示，分別從服務(wù)器、客戶端和傳輸層三個(gè)方面執(zhí)行。傳輸層方面，在QUIC連接內(nèi)，通過系統(tǒng)stream 模塊建立數(shù)據(jù)流，其中連接狀態(tài)和接收信號(hào)建立單數(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)進(jìn)行QUIC 連接；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

系統(tǒng)在Github 上調(diào)用andlabs/ui 開源庫，使用Go 語言開發(fā)了Windows 桌面GUI 程序，實(shí)現(xiàn)服務(wù)器和客戶端操作界面的設(shè)計(jì)。服務(wù)器界面用于實(shí)現(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

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

3 實(shí)驗(yàn)及結(jié)果分析

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

3.1 實(shí)驗(yàn)環(huán)境

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

3.2 實(shí)驗(yàn)內(nèi)容與結(jié)論

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

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

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

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

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

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

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

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

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

4 結(jié)論與展望

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

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

利益沖突聲明

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