最近做在做一个项目，涉及到文件上传的问题。 以前也做过文件上传。但都是些小文件，不超过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种方法都不尽如人意思