基于.Net的Web應(yīng)用系統(tǒng)中大文件傳輸方案的研究

劉 苡，吳 剛

0 引言

大文件上傳是Web應(yīng)用系統(tǒng)中常見的問題。企業(yè)的各種信息系統(tǒng)，包括電子商務(wù)、電子政務(wù)系統(tǒng)，以及制造類企業(yè)的ERP、CRM、MES、PDM等系統(tǒng)對文件傳輸，都有著不同程度的需求。以產(chǎn)品數(shù)據(jù)管理（PDM）系統(tǒng)為例，它管理著大型設(shè)計(jì)、生產(chǎn)型企業(yè)的數(shù)字化文檔，并優(yōu)化其管理流程，例如航空航天及船舶制造企業(yè)，其單個(gè)文檔的規(guī)格往往很大，在幾兆至上百兆之間。因此，如何在PDM系統(tǒng)中實(shí)現(xiàn)大文件傳輸，并且在高并發(fā)環(huán)境中提供穩(wěn)定、安全、可靠的服務(wù)成為一個(gè)關(guān)鍵的功能模塊。

Net平臺是當(dāng)前最為流行的Web應(yīng)用開發(fā)框架之一，其強(qiáng)大的功能及便捷的開發(fā)、維護(hù)方式使它深受開發(fā)人員的青睞。然而，在基于.Net平臺的Web項(xiàng)目中實(shí)現(xiàn)大文件傳輸功能仍存在各種問題，例如并發(fā)情況下服務(wù)器CPU使用率過高、內(nèi)存占用過大、傳輸速度過慢、網(wǎng)絡(luò)不穩(wěn)定時(shí)容易造成傳輸失敗等。但是企業(yè)應(yīng)用對大文件傳輸?shù)男枨笕找嬖龃螅⑶也l(fā)情況越來越頻繁，如何在.Net平臺中實(shí)現(xiàn)大文件傳輸功能成為一個(gè)重要的課題。

目前，用于文件傳輸?shù)腤eb組件并不少見，也不乏優(yōu)秀的成果，例如常見的ASP.NET自帶的FileUpload控件，國內(nèi)常用的Lyfupload組件等。但是絕大多數(shù)組件并不適合于大文件傳輸（大于 30M），當(dāng)大量用戶同時(shí)上傳大文件時(shí)，將造成上傳速度慢，容易發(fā)生意外中斷等結(jié)果。如何選擇和使用適當(dāng)?shù)纳蟼鹘M件，或者使用何種技術(shù)開發(fā)文件傳輸模塊，成為企業(yè)開發(fā)信息系統(tǒng)過程的常見問題，企業(yè)需要結(jié)合自身的需求做出不同的選擇。

1 基于Web上傳組件的研究

1.1 支持大文件上傳的Web組件

目前流行的大文件上傳組件有許多。以下對FileUpload，SWFUpload及SlickUpload組件的特性及可用性進(jìn)行分析、評估。

ASP.NET自帶的FileUpload控件是最簡單、最常用的文件上傳方式。但是出于各種因素的考慮，特別是安全方面的原因，該組件對上傳文件大小以及相應(yīng)響應(yīng)時(shí)間存在默認(rèn)的限制，例如只能在規(guī)定的時(shí)間上限內(nèi)上傳小于 4M 的文件。為了解決大文件上傳的問題，可以修改配置文件web.config中文件大小及響應(yīng)時(shí)間的限制，即修改httpRuntimeexecutionTimeout（響應(yīng)時(shí)間限制，單位秒）與maxRequestLength（請求數(shù)據(jù)流的最長字節(jié)數(shù)限制）節(jié)點(diǎn)的屬性。然而這不是解決問題的根本方法。由于該組件是為傳輸較小文件而設(shè)計(jì)，會在所有請求數(shù)據(jù)全部上傳到服務(wù)器內(nèi)存后才進(jìn)行相應(yīng)處理。如果多用戶同時(shí)向服務(wù)器上傳大文件，會導(dǎo)致在短時(shí)間內(nèi)消耗服務(wù)器大量內(nèi)存資源，對服務(wù)器造成極大壓力，甚至崩潰。因此，ASP.NET自帶的FileUpload控件，不能滿足大規(guī)模制造企業(yè)文件傳輸?shù)男枨蟆?/p>

SWFUpload是一個(gè)開源的輕量級的JavaScript/Flash庫，它結(jié)合了JavaScript和Flash的功能，以提供一種超越了傳統(tǒng)的瀏覽器中標(biāo)簽提供的文件上傳功能。通過它可以實(shí)現(xiàn)文件的異步傳輸，能夠更友好地在界面上顯示上傳進(jìn)度和上傳信息，并且可以實(shí)現(xiàn)多文件上傳。理論上通過 SWFUpload，可以上傳服務(wù)器限制下的任意大小文件（如IIS限制傳輸文件最大為2G）。但是，SWFUpload仍然是將文件數(shù)據(jù)一次讀入服務(wù)器端的session對象。因此，多用戶同時(shí)訪問服務(wù)器在上傳文件時(shí)，服務(wù)器消耗大量內(nèi)存的問題仍然不可避免。

在支持大文件上傳的組件中，國外的商業(yè)組件SlickUpload在局域網(wǎng)內(nèi)具有很好的表現(xiàn)：上傳速度快，能顯示進(jìn)度條，上傳文件大小不受限制。

SlickUpload的處理過程如下：1.客戶端初始化上傳請求；2.IIS接收請求并把請求傳遞給 ASP.NET；3.ASP.NET接收到請求；4.在 ASP.NET處理程序接收到請求之前，SlickUpload截獲該上傳請求；5.SlickUpload把接收到的請求，以流的方式寫入數(shù)據(jù)存儲設(shè)備；6.當(dāng) SlickUpload處理請求的時(shí)候，客戶端可以接收到處理進(jìn)度；7.SlickUpload完成請求處理；8.ASP.NET繼續(xù)處理除了上傳數(shù)據(jù)之外的請求。具體實(shí)現(xiàn)方法是：SlickUpload組件在瀏覽器端把上傳表單（包括上傳文件）封裝成XML文件，然后使用XMLHttp技術(shù)異步發(fā)送。為了突破應(yīng)用服務(wù)器對上傳文件大小的限制，SlickUpload在服務(wù)器端使用 IHttpModule技術(shù)，在ASP.NET進(jìn)程處理request請求之前截獲request對象，然后使用隱含的HttpWorkerRequest對象通過分塊讀取和寫入的方式來接收數(shù)據(jù)。這種方式對服務(wù)器接收過程進(jìn)行優(yōu)化處理，能夠?qū)崿F(xiàn)超大文件的上傳，并提高上傳速度。但是該收費(fèi)產(chǎn)品仍然不能實(shí)現(xiàn)斷點(diǎn)續(xù)傳。

1.2 Web組件上傳效率的驗(yàn)證

為了驗(yàn)證以上3種組件在并發(fā)環(huán)境下的表現(xiàn)，分別使用3種組件搭建文件上傳原型，并在實(shí)驗(yàn)室LAN網(wǎng)絡(luò)環(huán)境中進(jìn)行并發(fā)實(shí)驗(yàn)，觀察并記錄每種原型下服務(wù)器的運(yùn)行狀態(tài)。

Web服務(wù)器：IIS 7，內(nèi)存2G，啟動Web服務(wù)器無請求時(shí)CPU使用率處于7%左右。

并發(fā)請求：10條并發(fā)請求，每條請求上傳 200M 大小的文件。實(shí)際企業(yè)環(huán)境中可能有更多的并發(fā)請求，但是每個(gè)用戶上傳文件的大小可能在 3M-80M 不等，故使用較大的文件來模擬更多的用戶場景。

(1) FileUpload控件

實(shí)驗(yàn)結(jié)果：僅1人上傳文件時(shí)文件傳輸成功；10個(gè)用戶同時(shí)傳輸時(shí)，瀏覽器報(bào)錯(cuò)，傳輸失敗。10條并發(fā)上傳任務(wù)發(fā)生時(shí)服務(wù)器CPU使用率明顯上升，但內(nèi)存使用率相對平穩(wěn)，該實(shí)驗(yàn)中詳細(xì)服務(wù)器消耗情況，如圖1所示：

圖1 FileUpload控件在并發(fā)情況下的服務(wù)器資源消耗情況

事實(shí)上，文件在完全載入服務(wù)器內(nèi)存前傳輸就發(fā)生了錯(cuò)誤，因此服務(wù)器內(nèi)存占用情況并沒有很大變化。實(shí)驗(yàn)結(jié)果說明：FileUpload控件不能支持高并發(fā)的大文件上傳要求。

結(jié)果分析：FileUpload控件的優(yōu)點(diǎn)在于使用簡單；缺點(diǎn)在于對于并發(fā)情況下，大文件的傳輸無法支持，服務(wù)器的資源消耗過大。

(2) SWFUpload開源庫

實(shí)驗(yàn)結(jié)果：10條并發(fā)請求均上傳成功，服務(wù)器CPU使用率及內(nèi)存使用率均有明顯提高。由于 SWFUpload使用FlashPlayer的客戶端處理技術(shù)，對文件上傳進(jìn)行了優(yōu)化，避免了同一時(shí)間請求信息過大，造成響應(yīng)失敗的情況。SWFUpload開源庫在并發(fā)環(huán)境中的服務(wù)器資源使用情況，如圖2所示：

圖2 SWFUpload組件在并發(fā)情況下的服務(wù)器資源消耗情況

結(jié)果分析：SWFUpload開源庫的優(yōu)點(diǎn)在于提供了界面友好傳輸進(jìn)度反饋，并改善了傳輸過程，能夠支持較大文件的并發(fā)上傳，使用較為簡單；缺點(diǎn)在于服務(wù)器資源消耗大的問題仍然不可避免。

(3) SlickUpload組件

實(shí)驗(yàn)結(jié)果：均上傳成功，CPU使用率有一定提高，內(nèi)存使用率略有增大。由于該組件在傳輸和保存大文件過程中能夠?qū)崿F(xiàn)邊上傳邊處理，因此能夠避免服務(wù)器內(nèi)存的大量消耗。SWFUpload開源庫在并發(fā)環(huán)境中的服務(wù)器資源使用情況，如圖3所示：

圖3 SlickUpload控件在并發(fā)情況下的服務(wù)器資源消耗情況

結(jié)果分析：SlickUpload組件的優(yōu)點(diǎn)在于采用了邊上傳邊存儲的處理方法，避免了將文件一次讀入內(nèi)存，從而降低了服務(wù)器的資源消耗，提高了系統(tǒng)響應(yīng)速度，同時(shí)SlickUpload也提供了界面友好的進(jìn)度顯示，并支持多文件上傳；SlickUpload商業(yè)組件的缺點(diǎn)在于成本較高，并且由于用戶群不廣，組件的說明文檔及用戶交流都較缺乏，組件的使用方法也不如前兩種便捷。

FileUpload組件、SWFUpload開源庫與SlickUpload控件在并發(fā)環(huán)境中的服務(wù)器資源消耗情況有較大區(qū)別：FileUpload上傳失敗；SWFUpload與SlickUpload均上傳成功，但是 SlickUpload控件的服務(wù)器資源消耗較為理想。3組文件上傳組件實(shí)驗(yàn)中服務(wù)器的資源消耗情況的對比結(jié)果，如表1所示：

表1 大文件傳輸組件實(shí)驗(yàn)結(jié)果

實(shí)驗(yàn)結(jié)果證實(shí)：由于FileUpload與SWFUpload均是把用戶提交的文件一次讀入內(nèi)存再進(jìn)行處理，服務(wù)器資源消耗大（或響應(yīng)失敗）的問題不可避免。但SWFUpload對數(shù)據(jù)流進(jìn)行了一定優(yōu)化，對于并發(fā)性不常見的企業(yè)，SWFUpload組件是一個(gè)良好的解決方案。而使用SlickUpload組件時(shí)服務(wù)端能夠邊接收，邊處理文件流，并及時(shí)存儲，避免了服務(wù)器資源消耗大的問題。因此，在高并發(fā)的環(huán)境中，SlickUpload是較為理想的解決方案。

2 Web應(yīng)用中大文件上傳的其他實(shí)現(xiàn)思路

2.1 文件分塊傳輸方案

受SlickUpload組件的實(shí)現(xiàn)原理啟發(fā)，將文件分塊傳輸、存儲，可能是解決大文件傳輸過程中，CPU使用率過高以及實(shí)現(xiàn)斷點(diǎn)續(xù)傳問題的一個(gè)良好解決方案。問題轉(zhuǎn)變?yōu)椋何募绾畏謮K、如何傳輸、如何存儲、如何控制整個(gè)傳輸過程中的臨時(shí)狀態(tài)。

分塊傳輸方案中，大文件上傳的過程，如圖3所示：

圖4 文件分塊傳輸流程

AJAX技術(shù)可以實(shí)現(xiàn)以上流程：使用ADODB.Stream裝載文件并獲取文件塊；使用XMLHttp協(xié)議作為文件塊信息的載體；服務(wù)器解析接受到的XML信息，并存入文件系統(tǒng)，記錄日志；異步刷新頁面，逐步獲取新文件塊，直至整個(gè)文件傳輸完畢。

ADO（ActiveXDataObjects）是微軟開發(fā)的數(shù)據(jù)訪問組件，在微軟各個(gè)版本的操作系統(tǒng)中都自帶有 ADO組件。ADODB.Stream對象可用來表示文本流和數(shù)據(jù)流，它允許開發(fā)者對字節(jié)型的二進(jìn)制流進(jìn)行讀寫，因此可被用于實(shí)現(xiàn)客戶端的讀取文件功能。XMLHttp是傳送 XML 格式數(shù)據(jù)的超文本傳輸協(xié)議，可以方便地在異構(gòu)平臺之間進(jìn)行數(shù)據(jù)交換。XMLHttp最大的用處是可以更新網(wǎng)頁的部分內(nèi)容而不需要刷新整個(gè)頁面，因此，作為AJAX技術(shù)的重要成員，它在瀏覽器端的應(yīng)用非常普遍。

根據(jù)以上方法的設(shè)計(jì)，續(xù)傳的過程，如圖5所示：

圖5 文件續(xù)傳流程

利用 ADODB.Stream來裝載文件并獲取文件塊，再通過XMLHttp把封裝好的文件塊發(fā)送給服務(wù)器的方法，能很好地解決大文件上傳的問題。但是其控制過程復(fù)雜，企業(yè)在選擇該方案時(shí)，需綜合考慮時(shí)間成本及穩(wěn)定性等各種因素。

2.2 FTP文件傳輸?shù)姆绞?/h3>

以上討論的文件傳輸方式均基于HTTP協(xié)議。超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol）是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。但是大文件傳輸并不是 HTTP的強(qiáng)項(xiàng)，使用 HTTP協(xié)議傳輸大文件大多會有CPU使用率高或處理過程復(fù)雜化的缺陷。FTP（文件傳輸協(xié)議）是一種經(jīng)典的 C/S 結(jié)構(gòu)的文件傳輸方式，其優(yōu)點(diǎn)是上傳速度快、能實(shí)現(xiàn)斷點(diǎn)續(xù)傳，缺點(diǎn)是是部署麻煩、維護(hù)困難，不能實(shí)現(xiàn)與Web應(yīng)用的無縫接合。

FTP的實(shí)現(xiàn)是通過兩個(gè)TCP連接完成的：一個(gè)稱為控制連接，用于傳輸 FTP命令；另一個(gè)稱為數(shù)據(jù)連接，用于傳輸文件數(shù)據(jù)。FTP服務(wù)器端可以方便地以文件夾為單位控制用戶對文件的操作權(quán)限、管理用戶的訪問信息等。

在瀏覽器實(shí)現(xiàn) FTP客戶端功能可以有幾種方法：ActiveX、Java Applet，以及SilverLight、Flex等富客戶端技術(shù)。

ActiveX 是一個(gè)開放的集成平臺，為開發(fā)人員、用戶和Web生產(chǎn)商提供了一個(gè)快速而簡便地在 Internet 和 Intranet 創(chuàng)建程序集成和內(nèi)容的方法。ActiveX的缺點(diǎn)是需要在用戶機(jī)器中下載可執(zhí)行代碼，不僅維護(hù)麻煩，而且可能帶來安全隱患。Applet（小應(yīng)用程序）是使用 Java創(chuàng)建的基于HTML的程序。瀏覽器將其暫時(shí)下載到用戶的硬盤上，并在Web頁打開時(shí)在本地運(yùn)行。由于可執(zhí)行代碼每次都是臨時(shí)下載、運(yùn)行，因此在客戶端維護(hù)方面比ActiveX方便許多，但是為了防止其中帶有的惡意代碼對本機(jī)造成的破壞，Applet的限制較多。并且Applet要求客戶機(jī)上裝有JDK環(huán)境，因此該方案也漸漸被新技術(shù)所取代。SilverLight與Flex是支持RIA（Rich Internet Applications）的開發(fā)和部署的技術(shù)，可用于構(gòu)建具有表現(xiàn)力的Web應(yīng)用程序。由于它們具有編譯器性能，可以支持客戶端代碼的運(yùn)行，可以作為FTP客戶端的技術(shù)載體，并提升Web頁面的用戶體驗(yàn)。但是客戶端為了支持SilverLight必須下載并安裝SilverLight插件，這是很多用戶所不喜歡的方式。而 Flex需要客戶瀏覽器上裝有Adobe FlashPlayer插件，這類軟件在客戶機(jī)上比較普及。因此，在制造型企業(yè)的內(nèi)部網(wǎng)絡(luò)環(huán)境中，使用 Flex優(yōu)于SilverLight技術(shù)。

使用Flex技術(shù)進(jìn)行頁面開發(fā)，可以較便捷地實(shí)現(xiàn)FTP客戶端功能，并且無需復(fù)雜的客戶端代碼維護(hù)工作，是實(shí)現(xiàn)大文件傳輸?shù)囊粋€(gè)較合適的解決方案。

3 結(jié)論

針對基于.Net的Web應(yīng)用系統(tǒng)對大文件傳輸?shù)奶囟ㄐ枨螅疚耐ㄟ^對基于Web的大文件傳輸方案的研究，分析了多種解決方案的優(yōu)缺點(diǎn)，運(yùn)用實(shí)驗(yàn)的方法，提出了多項(xiàng)解決方案并對其特點(diǎn)及優(yōu)缺點(diǎn)進(jìn)行了歸納與總結(jié)，其結(jié)果，如表2所示：

表2 各種文件傳輸方案比較

從表2中可以看出，對于安全性要求低、并發(fā)程度不高，預(yù)算有限的小型企業(yè)信息系統(tǒng)，SWFUpload是一個(gè)理想的解決方案。而結(jié)合大規(guī)模制造企業(yè)對文件傳輸?shù)奶厥庑枨螅褂肧lickUpload組件能很好地解決大文件上傳的問題。若企業(yè)選擇自主搭建文件傳輸功能模塊，則使用分塊傳輸方法或使用Flex實(shí)現(xiàn)FTP傳輸方案均是較理想的選擇，但是分塊傳輸方案需要較高的學(xué)習(xí)成本及時(shí)間成本。不同行業(yè)、不同規(guī)模的企業(yè)可以根據(jù)自身的需求及資源限制，選擇合適的文件傳輸實(shí)現(xiàn)方法。

[1]Evangelos P. Markatos, Dionisios N. Pnevmatikatos,Michail D. Flouris, andManolis G. H. Katevenis,Web-conscious storage management for web proxies,IEEE/ACM, VOL. 10, NO. 6, DECEMBER 2002.

[2]Wu-Tao, Jiang, Shou-Shan, Research on document management based on virtual folder, Computer Engineering and Applications, Vol. 42, no. 30, Oct. 2007.

[3]沈順成，盧龍.基于Web的PDM系統(tǒng)中文檔管理的研究及實(shí)現(xiàn)．[j]制造業(yè)信息化，1002- 2333 (2007) 10- 0042-02．

[4]崔文浩，張文國．基于 Web 的 PDM 系統(tǒng)文件存取的研究與應(yīng)用．[j]科技信息，2007 年第 36 期．

[5]陳陽，黃寧，康銳，李瑞瑩．局域網(wǎng)[j]FTP業(yè)務(wù)可靠性試驗(yàn)與評估技術(shù)．2011年第37卷第1期．

[6]張偉強(qiáng)．面向電子倉庫的數(shù)據(jù)傳輸與訪問方法的技術(shù)探索[j]．今日科苑，2007年 22期．

[7]任蜀焱，何玉林，曾慧娥．基于Web的PDMS電子倉庫關(guān)鍵技術(shù)研究[j]．機(jī)械與電子，2006年 04期．

[8]ANONYMOUS. SlickUpload overview.http://krystalware.com/Products /SlickUpload/