基于Web的大文件高效上傳方法①

阮曉龍,李朋楠

1(河南中醫(yī)藥大學(xué) 信息技術(shù)學(xué)院,鄭州 450046)

2(鄭州祺石信息技術(shù)有限公司,鄭州 450008)

1 現(xiàn)狀分析

1.1 應(yīng)用價(jià)值

大文件上傳是Web 應(yīng)用系統(tǒng)中常見的問題[1],盡管HTTP 是TCP 上層的協(xié)議,但是HTTP 協(xié)議本身并不適合處理超大的請(qǐng)求體,文件上傳的穩(wěn)定性存在著很大的問題.如果傳輸過程中因某種異常而中斷,將前功盡棄,同時(shí),若沒有斷點(diǎn)續(xù)傳功能,那文件只能重新上傳,這樣不僅造成帶寬資源的浪費(fèi),而且不能保證再次上傳文件就能成功[2].

目前基于HTTP 協(xié)議的斷點(diǎn)續(xù)傳方案雖然保證大文件上傳過程中的穩(wěn)定性,但是在傳輸效率和安全性方面仍有不足,滿足不了當(dāng)前互聯(lián)網(wǎng)Web 應(yīng)用系統(tǒng)的需求,因此基于Web 的大文件高效上傳方法的研究和實(shí)現(xiàn)是Web 應(yīng)用中的重要基礎(chǔ)[3,4].

1.2 常用技術(shù)

目前互聯(lián)網(wǎng)中,已經(jīng)存在許多基于Web 上傳文件的方法,文獻(xiàn)[5]中介紹了常用3 種方法如下所示:

(1)HTML Form

該方法主要利用HTML 中Form 表單實(shí)現(xiàn)簡(jiǎn)單的文件上傳.其中表單的提交方式為POST,編碼類型enctype 為“multipart/form-data”.同時(shí)Form 表單里還需要包含一個(gè)文件框Input,文件框類型(type)應(yīng)為file.通過結(jié)合Javascript、Ajax 等腳本技術(shù),從而實(shí)現(xiàn)文件異步上傳、交互等操作.

(2)RIA 技術(shù)

RIA 技術(shù)主要是包括Flex、Silverlight、JavaFX等技術(shù),該技術(shù)中最常用的文件上傳插件為SWFUpload.

RIA 技術(shù)的倡導(dǎo)者為Adobe,其提供了Flex 技術(shù)來使程序員可以用編程的方式生成Flash 內(nèi)容,因此一般常用Flex 技術(shù)開發(fā)文件上傳的客戶端程序.

同時(shí),與Silverlight、JavaFX 等技術(shù)在運(yùn)行庫方面比較,Flex 也最是輕量級(jí)的.

(3)插件技術(shù)

在瀏覽器中也可以使用插件實(shí)現(xiàn)文件上傳.雖然可能由于客戶瀏覽器的安全性設(shè)置,導(dǎo)致插件無法運(yùn)行,但是在學(xué)校內(nèi)網(wǎng)、企業(yè)內(nèi)網(wǎng)等內(nèi)部環(huán)境還是可以考慮使用的.插件技術(shù)主要包括Activex、Applet 等.例如ActiveX 控件,該控件利用Winsock 技術(shù)建立與Web 服務(wù)之間的通信,并讀取上傳文件數(shù)據(jù),再通過Socket 技術(shù)把數(shù)據(jù)以HTTP POST 方式發(fā)送給服務(wù)器.

此外,文獻(xiàn)[6]中提出了一種文件分塊上傳的方法,使用單線程傳輸,通過固定大小分片可計(jì)算得到上傳文件的偏移量,進(jìn)而較好的實(shí)現(xiàn)了大文件的斷點(diǎn)續(xù)傳.文獻(xiàn)[2,7]中指出了一種雙線程傳輸方法,即一個(gè)線程傳輸文件內(nèi)容,另一個(gè)線程記錄文件內(nèi)容的偏移量,同樣可實(shí)現(xiàn)斷點(diǎn)續(xù)傳.這兩種方法雖然可實(shí)現(xiàn)斷點(diǎn)續(xù)傳,但是其傳輸效率還有待提高.文獻(xiàn)[8]中通過多線程方式,按線程數(shù)對(duì)文件進(jìn)行分塊,傳輸效率雖然有所提高,但是其每個(gè)線程同樣是通過記錄分塊文件的偏移量,來實(shí)現(xiàn)斷點(diǎn)續(xù)傳.以上方法均為時(shí)序傳輸,一旦中斷再傳,只是從斷點(diǎn)位置繼續(xù)上傳,不能保證已上傳文件內(nèi)容的完整性與正確性.

1.3 存在問題

目前大文件上傳常用方法中主要存在以下4 個(gè)方面問題.

(1)單線程上傳

常用的大文件上傳方法一般采用單一線程進(jìn)行文件的傳輸,對(duì)帶寬的利用率較低、穩(wěn)定性較差,不能較好實(shí)現(xiàn)文件傳輸過程中的交互操作.

(2)斷點(diǎn)不續(xù)傳

當(dāng)使用簡(jiǎn)單上傳功能來進(jìn)行大文件上傳,如果上傳的過程中出現(xiàn)了異常造成中斷,那么此次上傳失敗,重試必須從文件起始位置上傳.

(3)安全性不足

常用的大文件上傳方法在文件上傳前后不做完整性和正確性驗(yàn)證,或只是簡(jiǎn)單的進(jìn)行文件大小方面的完整性驗(yàn)證,無法保證文件上傳后還是原來的文件.

(4)文件重復(fù)上傳

當(dāng)已成功上傳的文件再次被上傳時(shí),如不能夠有效識(shí)別該文件,會(huì)使文件再次進(jìn)行上傳操作,從而造成帶寬、時(shí)間資源的浪費(fèi).

2 關(guān)鍵技術(shù)

本文提出基于Web 的大文件高效上傳方法的研究與實(shí)現(xiàn),其中包含7 個(gè)關(guān)鍵技術(shù),具體如下.

2.1 無客戶端值守

用戶在上傳一個(gè)幾百兆、甚至是上千兆的大文件到服務(wù)器上時(shí),通常采用的是FTP 協(xié)議和某些客戶端軟件,從而能較好地支持大文件的上傳以及實(shí)現(xiàn)文件斷點(diǎn)續(xù)傳功能.由于HTTP 協(xié)議的超大范圍使用和Web 技術(shù)的本身特點(diǎn),也涌現(xiàn)了一批Web 上傳大文件的插件[9,10].

本文提出的方法是基于HTML5 技術(shù)可以采用化整為零的文件上傳方法,可將單個(gè)大文件轉(zhuǎn)化為多個(gè)小分片文件進(jìn)行上傳,有效地解決了HTTP 協(xié)議本身并不適合處理超大請(qǐng)求文件問題.

2.2 多并發(fā)上傳

在實(shí)際工作中,單一的Web 請(qǐng)求往往無法讓網(wǎng)絡(luò)傳輸速率達(dá)到飽和狀態(tài)[8],因此采用多并發(fā)的方式進(jìn)行文件上傳,可以充分利于網(wǎng)絡(luò)帶寬、提高文件傳輸速度[7,11].

本文采用構(gòu)建線程池的方法,使并發(fā)線程保持在一個(gè)合理值,實(shí)現(xiàn)了多并發(fā)可控上傳,避免了并發(fā)線程過多且無序控制造成的線程排隊(duì)長(zhǎng)時(shí)等待現(xiàn)象,造成資源空耗的浪費(fèi).

2.3 文件傳輸校驗(yàn)

傳統(tǒng)方式下,文件識(shí)別校驗(yàn)方法主要是對(duì)文件傳輸前后的MD5 值進(jìn)行比對(duì)[12,13],該方法在針對(duì)小文件時(shí)可行,但對(duì)大文件或超大文件來說,采用該方法在計(jì)算MD5 值時(shí)就會(huì)非常耗費(fèi)時(shí)間,且有可能造成服務(wù)器計(jì)算處理失敗而崩潰.

針對(duì)此問題,本文提出同樣可采用化整為零的MD5 計(jì)算方法,將單個(gè)大文件的MD5 計(jì)算,轉(zhuǎn)化為多個(gè)小分片文件的MD5 計(jì)算,這樣只要確保每個(gè)分片的MD5 在上傳前后一致,即可確定在分片有序合并后的文件和原來保持一致[14,15].

2.4 斷點(diǎn)續(xù)傳

斷點(diǎn)續(xù)傳是指文件在上傳過程中,如果碰到網(wǎng)絡(luò)故障或其他一些因素,導(dǎo)致文件傳輸中斷.待故障恢復(fù)后,可以接著未上傳部分繼續(xù)上傳,從而節(jié)省上傳文件時(shí)間[16].

本文斷點(diǎn)續(xù)傳不同于其他時(shí)序傳輸?shù)臄帱c(diǎn)續(xù)傳,在某一分片首次上傳時(shí),遇到網(wǎng)絡(luò)抖動(dòng)、高延時(shí)等短時(shí)網(wǎng)絡(luò)故障,即使該分片傳輸失敗,傳輸并不會(huì)立即中斷,而是會(huì)繼續(xù)上傳下一個(gè)分片,直至網(wǎng)絡(luò)恢復(fù)或最后一個(gè)分片上傳結(jié)束.在續(xù)傳過程中,并不是簡(jiǎn)單的從中斷的文件偏移位置繼續(xù)上傳,而會(huì)逐個(gè)校驗(yàn)分片的上傳結(jié)果,找出傳輸失敗和MD5 不一致的分片進(jìn)行補(bǔ)充上傳.

2.5 極速秒傳

極速秒傳是指當(dāng)服務(wù)器上已經(jīng)存在某個(gè)文件,而用戶又要上傳此文件,此時(shí),服務(wù)器則會(huì)檢測(cè)此文件的特征碼已被收錄,就可直接提示用戶文件已上傳完畢,而免去用戶再次上傳的過程[17,18].

2.6 文件切片

要想實(shí)現(xiàn)斷點(diǎn)續(xù)傳、多并發(fā)上傳、文件傳輸校驗(yàn)等技術(shù),關(guān)鍵在于文件分片,而且是在文件上傳前已經(jīng)完成分片.將大文件進(jìn)行分片傳輸,可以有效地避免文件上傳過程中可能出現(xiàn)的失敗問題[19,20].

在HTML5 標(biāo)準(zhǔn)制定前,如果實(shí)現(xiàn)文件分片,則必須采用某些前端控件來實(shí)現(xiàn);從HTML5 標(biāo)準(zhǔn)制定之后,直接可以使用HTML5 相應(yīng)的File API 功能函數(shù),解決文件在Web 前端無插件分片的問題.

2.7 文件合并

目前有兩種方法實(shí)現(xiàn)對(duì)上傳分片文件進(jìn)行合并,一種是待所有分片傳完之后統(tǒng)一合并,這就需要服務(wù)端將接收到的所有分片進(jìn)行臨時(shí)存儲(chǔ),最終合并也會(huì)消耗較長(zhǎng)時(shí)間;另一種方法是“邊傳邊合并”[19],服務(wù)端可以直接將上傳過程中接收到文件分片,按順序追加保存至第一個(gè)分片文件中,這就不需要存儲(chǔ)臨時(shí)文件,且最終所有分片文件上傳完畢同時(shí)也完成文件合并操作,減少文件合并消耗時(shí)間.

3 方案設(shè)計(jì)

基于上述大文件上傳方法與關(guān)鍵技術(shù),綜合其優(yōu)缺點(diǎn),本文提出一種基于Web 的大文件安全高效上傳方案.該方案是基于HTTP 協(xié)議,利用HTML5 的XMLHttpRequest 2 特性[21],采用File API 提供的功能函數(shù),實(shí)現(xiàn)無客戶端方式下文件分塊傳輸.并在首傳和續(xù)傳過程中對(duì)每一個(gè)分片進(jìn)行MD5 校驗(yàn),提高傳輸安全性.同時(shí)利用多線程技術(shù),在前端構(gòu)建線程池[22],實(shí)現(xiàn)多線程的創(chuàng)建與管理,提高文件傳輸?shù)膸捓寐?進(jìn)而提升了文件的上傳效率.此外在處理重復(fù)文件上傳時(shí),通過提取文件特征碼,匹配已上傳的文件信息庫,如果匹配成功,則可免去重復(fù)文件上傳過程,節(jié)約帶寬資源及時(shí)間成本.其基于Web 的大文件高效上傳方法的邏輯設(shè)計(jì)過程如圖1 所示.

圖1 并發(fā)文件校驗(yàn)算法流程示意圖

4 具體實(shí)現(xiàn)

針對(duì)文件上傳流程示意圖,基于Javascript 語言對(duì)流程中關(guān)鍵步驟進(jìn)行代碼實(shí)現(xiàn),具體如下所示.

4.1 文件分片

在前端分片傳輸過程中,分片大小是一定的,分片越小,請(qǐng)求越多,開銷越大;分片越大,靈活度越小,

分片上傳的優(yōu)勢(shì)就會(huì)相對(duì)越不明顯[6],因此,分片大小可以根據(jù)實(shí)際情況設(shè)置一個(gè)合適的值[23].

本文采取的shardSize = 2×1024×1024.初始化start =currentChunk×shardSize;end = start + shardSize ＞=file.size? file.size :start + shardSize,變量start 表示的是分片的開始節(jié)點(diǎn),變量end 表示的是分片的終止節(jié)點(diǎn).條件表達(dá)式start + shardSize ＞= file.size? file.size :start +shardSize,功能是獲取下一個(gè)分片文件的終止節(jié)點(diǎn).其表達(dá)式如式(1)所示.其中x代表分片序號(hào)currentChunk,取值從0 開始,遞增量為1;y代表分片大小shardSize,是個(gè)固定值;z代表整個(gè)文件的大小file.size.

該表達(dá)式通過計(jì)算起始節(jié)點(diǎn)加分片大小獲取文件上傳傳輸?shù)慕K止結(jié)點(diǎn).參數(shù)arrayObj 為所有分片文件的M D 5 碼存放數(shù)組,文件的M D 5 碼可以通過spark.end()函數(shù)生成.

大文件上傳的前端分片及MD5 計(jì)算關(guān)鍵代碼摘錄如下所示:

4.2 多并發(fā)上傳

在并發(fā)上傳過程中,瀏覽器支持的最大并發(fā)數(shù)t是一定的,因此設(shè)置的并發(fā)數(shù)如果超過該值,則會(huì)造成瀏覽器在執(zhí)行過程中并發(fā)請(qǐng)求排隊(duì)等待.所以,并發(fā)數(shù)的設(shè)置越接近t,傳輸效率越大.

本文采取不同并發(fā)數(shù)來觀察它的效率變化情況,以控制并發(fā)數(shù)在一個(gè)合理值,poolSize 是最大并發(fā)請(qǐng)求數(shù),poolCount 是活動(dòng)并發(fā)數(shù).通過定時(shí)函數(shù)setInterval()來執(zhí)行并發(fā)請(qǐng)求,當(dāng)poolCount＜poolSize 時(shí),就發(fā)起一個(gè)并發(fā)請(qǐng)求進(jìn)行分片傳輸,poolCount 增加1,傳輸完成后poolCount 減少1,以此來保證并發(fā)數(shù)在設(shè)定值.

多并發(fā)上傳的關(guān)鍵代碼摘錄如下所示:

var idInt = setInterval(function(){

5 實(shí)驗(yàn)結(jié)果與分析

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

本次實(shí)驗(yàn)服務(wù)器資源配置如表1 所示.

表1 服務(wù)器配置信息

為排除其它因素對(duì)本次實(shí)驗(yàn)的影響,此次實(shí)驗(yàn)僅保留原生的操作系統(tǒng),不安裝任何軟件/服務(wù)/組件(測(cè)試程序除外),最大程度的減少實(shí)驗(yàn)影響因素.

5.2 實(shí)驗(yàn)結(jié)果

本文提出基于Web 的大文件安全高效上傳方法主要設(shè)置參數(shù)為瀏覽器請(qǐng)求并發(fā)數(shù),為驗(yàn)證其靈活性及通用性,本次實(shí)驗(yàn)在保持分片大小不變的基礎(chǔ)上,采用不同并發(fā)數(shù)上傳同一文件進(jìn)行驗(yàn)證,重復(fù)進(jìn)行3 次,實(shí)現(xiàn)結(jié)果如圖2 所示.

圖2 不同線程數(shù)文件上傳耗時(shí)圖

通過圖2 實(shí)驗(yàn)結(jié)果可得出文件傳輸耗時(shí)是L 型變化的,請(qǐng)求并發(fā)數(shù)設(shè)置為3 時(shí)產(chǎn)生拐點(diǎn).請(qǐng)求并發(fā)數(shù)與耗費(fèi)時(shí)間在拐點(diǎn)之前呈反比關(guān)系,耗費(fèi)時(shí)間隨著并發(fā)數(shù)的增大而線性減少,由于網(wǎng)絡(luò)帶寬以及瀏覽器軟件等實(shí)驗(yàn)環(huán)境因素的影響,在拐點(diǎn)之后耗費(fèi)時(shí)間趨于平穩(wěn).

5.3 實(shí)驗(yàn)分析

對(duì)于文件上傳來說其優(yōu)劣主要由傳輸?shù)恼_性、時(shí)間成本、適應(yīng)性、可移植性、魯棒性這五個(gè)方面決定,通過這些判斷條件能夠很好的評(píng)估大文件安全高效上傳方案是否準(zhǔn)確高效.

本文提出的大文件安全高效上傳方案基于Web方式進(jìn)行優(yōu)化,利用HTML5 文件接口對(duì)大文件進(jìn)行前端切片,后端合并,其本質(zhì)相當(dāng)于對(duì)待上傳文件進(jìn)行了一次完整的數(shù)據(jù)傳輸,最終得到結(jié)果文件與上傳文件完全相符.在保持文件內(nèi)容不變的前提下,使用并發(fā)上傳能夠大大節(jié)約時(shí)間成本.其中基于Web 和HTML5 切片的傳輸方式,幾乎能適應(yīng)所有規(guī)模的文件Web 上傳環(huán)境;并通過斷點(diǎn)續(xù)傳確保了Web 傳輸?shù)目煽啃?

6 總結(jié)

本文提出基于Web 的大文件高效上傳方法,在傳統(tǒng)單線程大文件上傳基礎(chǔ)上,采用了多并發(fā)上傳,充分利用帶寬資源提高傳輸效率,對(duì)于存儲(chǔ)的資源文件進(jìn)行特征庫收錄,實(shí)現(xiàn)已收錄文件的極速秒傳,節(jié)約了時(shí)間成本.同時(shí)對(duì)于大文件的MD5 計(jì)算,利用循環(huán)切片計(jì)算的方式極大的降低磁盤I/O 和內(nèi)存的占用.該方法普適性強(qiáng)、能夠很好地在文件傳輸過程中提高上傳效率、提升穩(wěn)定性、增強(qiáng)安全性,從而更好地為用戶服務(wù).