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

在了解HTTP断点续传的原理之前，让我们先来了解一下HTTP协议，，HTTP协议是一种基于tcp的简单协议，分为请求和回复两种。请求协议是由客户机(浏览器)向服务器（WEB SERVER）提交请求时发送报文的协议。回复协议是由服务器(web server)，向客户机(浏览器)回复报文时的协议。请求和回复协议都由头和体组成。头和体之间以一行空行为分隔。
以下是一个请求报文与相应的回复报文的例子：

　　下面我们就来说说"断点续传"，顾名思义，断点续传就是在上一次下载时断开的位置开始继续下载。
在HTTP协议中，可以在请求报文头中加入Range段，来表示客户机希望从何处继续下载。