基于.Net的Web应用系统中大文件传输方案的研究

刘 苡，吴 刚

0 引言

大文件上传是Web应用系统中常见的问题。企业的各种信息系统，包括电子商务、电子政务系统，以及制造类企业的ERP、CRM、MES、PDM等系统对文件传输，都有着不同程度的需求。以产品数据管理（PDM）系统为例，它管理着大型设计、生产型企业的数字化文档，并优化其管理流程，例如航空航天及船舶制造企业，其单个文档的规格往往很大，在几兆至上百兆之间。因此，如何在PDM系统中实现大文件传输，并且在高并发环境中提供稳定、安全、可靠的服务成为一个关键的功能模块。

Net平台是当前最为流行的Web应用开发框架之一，其强大的功能及便捷的开发、维护方式使它深受开发人员的青睐。然而，在基于.Net平台的Web项目中实现大文件传输功能仍存在各种问题，例如并发情况下服务器CPU使用率过高、内存占用过大、传输速度过慢、网络不稳定时容易造成传输失败等。但是企业应用对大文件传输的需求日益增大，并且并发情况越来越频繁，如何在.Net平台中实现大文件传输功能成为一个重要的课题。

目前，用于文件传输的Web组件并不少见，也不乏优秀的成果，例如常见的ASP.NET自带的FileUpload控件，国内常用的Lyfupload组件等。但是绝大多数组件并不适合于大文件传输（大于 30M），当大量用户同时上传大文件时，将造成上传速度慢，容易发生意外中断等结果。如何选择和使用适当的上传组件，或者使用何种技术开发文件传输模块，成为企业开发信息系统过程的常见问题，企业需要结合自身的需求做出不同的选择。

1 基于Web上传组件的研究

1.1 支持大文件上传的Web组件

目前流行的大文件上传组件有许多。以下对FileUpload，SWFUpload及SlickUpload组件的特性及可用性进行分析、评估。

ASP.NET自带的FileUpload控件是最简单、最常用的文件上传方式。但是出于各种因素的考虑，特别是安全方面的原因，该组件对上传文件大小以及相应响应时间存在默认的限制，例如只能在规定的时间上限内上传小于 4M 的文件。为了解决大文件上传的问题，可以修改配置文件web.config中文件大小及响应时间的限制，即修改httpRuntimeexecutionTimeout（响应时间限制，单位秒）与maxRequestLength（请求数据流的最长字节数限制）节点的属性。然而这不是解决问题的根本方法。由于该组件是为传输较小文件而设计，会在所有请求数据全部上传到服务器内存后才进行相应处理。如果多用户同时向服务器上传大文件，会导致在短时间内消耗服务器大量内存资源，对服务器造成极大压力，甚至崩溃。因此，ASP.NET自带的FileUpload控件，不能满足大规模制造企业文件传输的需求。

SWFUpload是一个开源的轻量级的JavaScript/Flash库，它结合了JavaScript和Flash的功能，以提供一种超越了传统的浏览器中标签提供的文件上传功能。通过它可以实现文件的异步传输，能够更友好地在界面上显示上传进度和上传信息，并且可以实现多文件上传。理论上通过 SWFUpload，可以上传服务器限制下的任意大小文件（如IIS限制传输文件最大为2G）。但是，SWFUpload仍然是将文件数据一次读入服务器端的session对象。因此，多用户同时访问服务器在上传文件时，服务器消耗大量内存的问题仍然不可避免。

在支持大文件上传的组件中，国外的商业组件SlickUpload在局域网内具有很好的表现：上传速度快，能显示进度条，上传文件大小不受限制。

SlickUpload的处理过程如下：1.客户端初始化上传请求；2.IIS接收请求并把请求传递给 ASP.NET；3.ASP.NET接收到请求；4.在 ASP.NET处理程序接收到请求之前，SlickUpload截获该上传请求；5.SlickUpload把接收到的请求，以流的方式写入数据存储设备；6.当 SlickUpload处理请求的时候，客户端可以接收到处理进度；7.SlickUpload完成请求处理；8.ASP.NET继续处理除了上传数据之外的请求。具体实现方法是：SlickUpload组件在浏览器端把上传表单（包括上传文件）封装成XML文件，然后使用XMLHttp技术异步发送。为了突破应用服务器对上传文件大小的限制，SlickUpload在服务器端使用 IHttpModule技术，在ASP.NET进程处理request请求之前截获request对象，然后使用隐含的HttpWorkerRequest对象通过分块读取和写入的方式来接收数据。这种方式对服务器接收过程进行优化处理，能够实现超大文件的上传，并提高上传速度。但是该收费产品仍然不能实现断点续传。

1.2 Web组件上传效率的验证

为了验证以上3种组件在并发环境下的表现，分别使用3种组件搭建文件上传原型，并在实验室LAN网络环境中进行并发实验，观察并记录每种原型下服务器的运行状态。

Web服务器：IIS 7，内存2G，启动Web服务器无请求时CPU使用率处于7%左右。

并发请求：10条并发请求，每条请求上传 200M 大小的文件。实际企业环境中可能有更多的并发请求，但是每个用户上传文件的大小可能在 3M-80M 不等，故使用较大的文件来模拟更多的用户场景。

(1) FileUpload控件

实验结果：仅1人上传文件时文件传输成功；10个用户同时传输时，浏览器报错，传输失败。10条并发上传任务发生时服务器CPU使用率明显上升，但内存使用率相对平稳，该实验中详细服务器消耗情况，如图1所示：

图1 FileUpload控件在并发情况下的服务器资源消耗情况

事实上，文件在完全载入服务器内存前传输就发生了错误，因此服务器内存占用情况并没有很大变化。实验结果说明：FileUpload控件不能支持高并发的大文件上传要求。

结果分析：FileUpload控件的优点在于使用简单；缺点在于对于并发情况下，大文件的传输无法支持，服务器的资源消耗过大。

(2) SWFUpload开源库

实验结果：10条并发请求均上传成功，服务器CPU使用率及内存使用率均有明显提高。由于 SWFUpload使用FlashPlayer的客户端处理技术，对文件上传进行了优化，避免了同一时间请求信息过大，造成响应失败的情况。SWFUpload开源库在并发环境中的服务器资源使用情况，如图2所示：

图2 SWFUpload组件在并发情况下的服务器资源消耗情况

结果分析：SWFUpload开源库的优点在于提供了界面友好传输进度反馈，并改善了传输过程，能够支持较大文件的并发上传，使用较为简单；缺点在于服务器资源消耗大的问题仍然不可避免。

(3) SlickUpload组件

实验结果：均上传成功，CPU使用率有一定提高，内存使用率略有增大。由于该组件在传输和保存大文件过程中能够实现边上传边处理，因此能够避免服务器内存的大量消耗。SWFUpload开源库在并发环境中的服务器资源使用情况，如图3所示：

图3 SlickUpload控件在并发情况下的服务器资源消耗情况

结果分析：SlickUpload组件的优点在于采用了边上传边存储的处理方法，避免了将文件一次读入内存，从而降低了服务器的资源消耗，提高了系统响应速度，同时SlickUpload也提供了界面友好的进度显示，并支持多文件上传；SlickUpload商业组件的缺点在于成本较高，并且由于用户群不广，组件的说明文档及用户交流都较缺乏，组件的使用方法也不如前两种便捷。

FileUpload组件、SWFUpload开源库与SlickUpload控件在并发环境中的服务器资源消耗情况有较大区别：FileUpload上传失败；SWFUpload与SlickUpload均上传成功，但是 SlickUpload控件的服务器资源消耗较为理想。3组文件上传组件实验中服务器的资源消耗情况的对比结果，如表1所示：

表1 大文件传输组件实验结果

实验结果证实：由于FileUpload与SWFUpload均是把用户提交的文件一次读入内存再进行处理，服务器资源消耗大（或响应失败）的问题不可避免。但SWFUpload对数据流进行了一定优化，对于并发性不常见的企业，SWFUpload组件是一个良好的解决方案。而使用SlickUpload组件时服务端能够边接收，边处理文件流，并及时存储，避免了服务器资源消耗大的问题。因此，在高并发的环境中，SlickUpload是较为理想的解决方案。

2 Web应用中大文件上传的其他实现思路

2.1 文件分块传输方案

受SlickUpload组件的实现原理启发，将文件分块传输、存储，可能是解决大文件传输过程中，CPU使用率过高以及实现断点续传问题的一个良好解决方案。问题转变为：文件如何分块、如何传输、如何存储、如何控制整个传输过程中的临时状态。

分块传输方案中，大文件上传的过程，如图3所示：

图4 文件分块传输流程

AJAX技术可以实现以上流程：使用ADODB.Stream装载文件并获取文件块；使用XMLHttp协议作为文件块信息的载体；服务器解析接受到的XML信息，并存入文件系统，记录日志；异步刷新页面，逐步获取新文件块，直至整个文件传输完毕。

ADO（ActiveXDataObjects）是微软开发的数据访问组件，在微软各个版本的操作系统中都自带有 ADO组件。ADODB.Stream对象可用来表示文本流和数据流，它允许开发者对字节型的二进制流进行读写，因此可被用于实现客户端的读取文件功能。XMLHttp是传送 XML 格式数据的超文本传输协议，可以方便地在异构平台之间进行数据交换。XMLHttp最大的用处是可以更新网页的部分内容而不需要刷新整个页面，因此，作为AJAX技术的重要成员，它在浏览器端的应用非常普遍。

根据以上方法的设计，续传的过程，如图5所示：

图5 文件续传流程

利用 ADODB.Stream来装载文件并获取文件块，再通过XMLHttp把封装好的文件块发送给服务器的方法，能很好地解决大文件上传的问题。但是其控制过程复杂，企业在选择该方案时，需综合考虑时间成本及稳定性等各种因素。

2.2 FTP文件传输的方式

以上讨论的文件传输方式均基于HTTP协议。超文本传输协议（HTTP，HyperText Transfer Protocol）是客户端浏览器或其他程序与Web服务器之间的应用层通信协议，是互联网上应用最为广泛的一种网络协议。但是大文件传输并不是 HTTP的强项，使用 HTTP协议传输大文件大多会有CPU使用率高或处理过程复杂化的缺陷。FTP（文件传输协议）是一种经典的 C/S 结构的文件传输方式，其优点是上传速度快、能实现断点续传，缺点是是部署麻烦、维护困难，不能实现与Web应用的无缝接合。

FTP的实现是通过两个TCP连接完成的：一个称为控制连接，用于传输 FTP命令；另一个称为数据连接，用于传输文件数据。FTP服务器端可以方便地以文件夹为单位控制用户对文件的操作权限、管理用户的访问信息等。

在浏览器实现 FTP客户端功能可以有几种方法：ActiveX、Java Applet，以及SilverLight、Flex等富客户端技术。

ActiveX 是一个开放的集成平台，为开发人员、用户和Web生产商提供了一个快速而简便地在 Internet 和 Intranet 创建程序集成和内容的方法。ActiveX的缺点是需要在用户机器中下载可执行代码，不仅维护麻烦，而且可能带来安全隐患。Applet（小应用程序）是使用 Java创建的基于HTML的程序。浏览器将其暂时下载到用户的硬盘上，并在Web页打开时在本地运行。由于可执行代码每次都是临时下载、运行，因此在客户端维护方面比ActiveX方便许多，但是为了防止其中带有的恶意代码对本机造成的破坏，Applet的限制较多。并且Applet要求客户机上装有JDK环境，因此该方案也渐渐被新技术所取代。SilverLight与Flex是支持RIA（Rich Internet Applications）的开发和部署的技术，可用于构建具有表现力的Web应用程序。由于它们具有编译器性能，可以支持客户端代码的运行，可以作为FTP客户端的技术载体，并提升Web页面的用户体验。但是客户端为了支持SilverLight必须下载并安装SilverLight插件，这是很多用户所不喜欢的方式。而 Flex需要客户浏览器上装有Adobe FlashPlayer插件，这类软件在客户机上比较普及。因此，在制造型企业的内部网络环境中，使用 Flex优于SilverLight技术。

使用Flex技术进行页面开发，可以较便捷地实现FTP客户端功能，并且无需复杂的客户端代码维护工作，是实现大文件传输的一个较合适的解决方案。

3 结论

针对基于.Net的Web应用系统对大文件传输的特定需求，本文通过对基于Web的大文件传输方案的研究，分析了多种解决方案的优缺点，运用实验的方法，提出了多项解决方案并对其特点及优缺点进行了归纳与总结，其结果，如表2所示：

表2 各种文件传输方案比较

从表2中可以看出，对于安全性要求低、并发程度不高，预算有限的小型企业信息系统，SWFUpload是一个理想的解决方案。而结合大规模制造企业对文件传输的特殊需求，使用SlickUpload组件能很好地解决大文件上传的问题。若企业选择自主搭建文件传输功能模块，则使用分块传输方法或使用Flex实现FTP传输方案均是较理想的选择，但是分块传输方案需要较高的学习成本及时间成本。不同行业、不同规模的企业可以根据自身的需求及资源限制，选择合适的文件传输实现方法。

[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系统中文档管理的研究及实现．[j]制造业信息化，1002- 2333 (2007) 10- 0042-02．

[4]崔文浩，张文国．基于 Web 的 PDM 系统文件存取的研究与应用．[j]科技信息，2007 年第 36 期．

[5]陈阳，黄宁，康锐，李瑞莹．局域网[j]FTP业务可靠性试验与评估技术．2011年第37卷第1期．

[6]张伟强．面向电子仓库的数据传输与访问方法的技术探索[j]．今日科苑，2007年 22期．

[7]任蜀焱，何玉林，曾慧娥．基于Web的PDMS电子仓库关键技术研究[j]．机械与电子，2006年 04期．

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