当前位置: 首页 > 图文教程 > 网络编程 > ASP.NET > 大文件上传浅谈,以及遇到的问题

ASP.NET
blog程序新版本V2.0 Beta完成,提供V1.0全部源码下载
“/”应用程序中的服务器错误
asp.net(c#)复数类(复数加减乘除四则运算)
asp.net(c#)不可访问,因为它受保护级别限制
asp.net(c#) 水仙花数
ASP.NET实现用图片进度条显示投票结果
asp.net(c#) MS AJAX的安装
asp.net(c#)有关 Session 操作的几个误区
ASP.net基础知识之常见错误分析
[.net] 操纵自如-页面内的配合与通信
c# static的全部用法收集整理
使CheckBoxList的Attributes属性生效(修改微软的一个bug)
在ASP.NET中使用Session常见问题集锦
[原创]完美解决Could not load file or assembly ''AjaxPro.2'' or one of its dependencies. 拒绝访问。
在Apache环境下成功的运行ASP.NET的注意事项
ClickOnce DIY全自动更新下载升级的自我实现
asp.net jscript 一句话木马
在ASP.Net中实现flv视频转换的代码
将DataTable中的一行复制到另一个DataTable的方法
在DataTable中执行Select("条件")后,返回DataTable的方法

ASP.NET 中的 大文件上传浅谈,以及遇到的问题


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-11-03   浏览: 229 ::
收藏到网摘: n/a


最近做在做一个项目,涉及到文件上传的问题。 以前也做过文件上传。但都是些小文件,不超过2M。 这次要求上传1G以上的东西。 没办法找来资料研究了一下。 基于WEB的文件上传可以使用FTP和HTTP两种协议,用FTP的话虽然传输稳定,但安全性是个严重的问题,所以没有考虑。 剩下只有HTTP。 在HTTP中有3种方式,PUT、WEBDAV、RFC1867,前2种方法不适合大文件上传,在这里也不说了。
确定使用RFC1867格式处理之后开始分析流行的上传组件。看了N多代码之后发现,目前无组件程序和一些COM组件都是使用Request.BinaryRead方法。一次性得到上传的数据,然后分析处理。这就是为什么上传大文件很慢的原因了,IIS超时不说,就算1G文件上去了,分析处理也得一阵子。 之后我把注意力放在国外商业组件上,比较流行的有Power-Web,AspUpload,ActiveFile,ABCUpload,aspSmartUpload,SA-FileUp。其中比较优秀的是ASPUPLOAD和SA-FILE,他们号称可以处理2G的文件(SA-FILE EE版甚至没有文件大小的限制),而且效率也是非常棒,难道编程语言的效率差这么多?(我的编程环境是VB6) 查了一些资料,觉得他们都是直接操作文件流。这样就不受文件大小的制约。 真是个好方法。
但老外的东西也不是绝对完美,ASPUPLOAD处理大文件后,内存占用情况惊人。1G左右都是稀松平常。我用的是3.0.0.3版。至于SA-FILE虽然是好东西但是破解难寻(郁闷死..) 失望之际,发现2款上传组件,Lion.Web.UpLoadModule和AspnetUpload,都是.NET的,估计也是操作文件流。但是上传速度和CPU占用率都不如老外的商业组件。
做了个测试,LAN内传1G的文件。ASPUPLOAD上传速度平均是4.4M/s,CPU占用10-15,内存占用700M。SA-FILE也差不多这样。而AspnetUpload最快也只有1.5M/s,平均是700K/s,CPU占用15-39,测试环境:PIII800,256M内存,100M LAN。我想AspnetUpload速度慢是可能因为一边接收文件,一边写硬盘。资源占用低的代价就是降低传输速度。 但也不得不佩服老外的程序,CPU占用如此之低.....这样2个.net的组件也被PASS.

稍带2个问题就是上传进度和断点续传。
显示上传进度比较简单,主要是查询用户上传的状态,用Script显示到浏览器中,至于无刷新显示就要看脚本语言运用的熟练程度了。
断点续传,HTTP方式是实现不了的,因为浏览器每次上传文件都是从头开始,没有Range标签。实现的方法只能用ActiveX。

研究之后决定写个CGI来处理文件上传。 这样可以不走IIS以免程序出错影响网站访问。小弟比较菜只能用VB6做,完成之后发现WIN CGI的效率简直就是差的不能再差。索性写个FILE SERVER,专门处理文件的上传。但是现在遇到一个2个问题。
一、用WINSOCK控件接收到的文本有乱码 不知道是程序转换时的错误还是WINSOCK本身垃圾,SO 换了PowerTCP的WINSOCK TOOL,情况有所好转 乱码没那么多了.........准备换vb.net,直接操作socket,程序还没做,不知道用.net接收会不会乱码。再有就哭了。
二、这个问题就比较初级了....接收到的文件流不能还原成文件..寒一个,

最后就是如何高效处理文件流, 我想来想去也就只有2种方法,一是都放在内存里,然后一起处理, 二是一边接收一边写文件。 但这2种方法都不尽如人意思