背景
在WEB程序中下载一个文件，最简单有效的办法就是直接给个链接到该文件的虚拟路径，把所有的问题交给浏览器和WEB服务器(IIS)去处理，但这种“良好”好的解决方案也会带来一些其它问题，譬如：无法在程序中控制下载权限，无法统计下载信息，无法将文件名更改为一个对客户良好的名字（事实上，为了避免服务器中文件名的重复，我们一般会分配给文件一个很长而又没有任何实际意义的名字，这不是客户端希望看到的，所以我们有必要在下载时重新为文件分配一个有意义的名字）。
基于Asp.net的方案
Response.Write/Response.BinaryWrite
WriteFile和BinaryWrite出现得比较早，在获取文件的路径后，会试图将文件流全部读入内存，之后再发送回客户端。对于小文件和流量很小的网站，使用这个方法或许问题不大，但如果文件很大或者网站的流量很大，使用这个方法可以让 aspnet_wp.exe 进程意味终止，导致当前服务器下所有 asp.net 站点全部瘫痪，不仅如此，服务器的物理内存也会在瞬间被填满，导致其它程序运行失败或意外终止。
示例代码：string filePath = Server.MapPath("test.rar ");
FileInfo fileInfo = new FileInfo(filePath);
Response.Clear();
Response.ClearContent();
Response.ClearHeaders();
Response.AddHeader("Content-Disposition", "attachment;filename=" + fileInfo.Name);
Response.ContentType = "application/octet-stream";
Response.AddHeader("Content-Length", fileInfo.Length.ToString());
Response.WriteFile(fileInfo.FullName);
Response.Flush();
Response.End();
Response.TransmitFile
TransmitFile是为了弥补WriteFile和BinaryWrite的不足才出现的方法，比WriteFile和BinaryWrite更加的稳定强大，对大文件的支持也不错。但其也有不足之处，对断点续传的支持不行，一个大的文件如果一次性没有下载完成的话，就需要从头再来。
示例代码：Response.ClearContent();
Response.AddHeader("Content-Disposition", "attachment; filename=" + fileInfo.Name);
Response.AddHeader("Content-Length", fileInfo.Length.ToString());
Response.ContentType = "application/octet-stream";
Response.TransmitFile(fileInfo.FullName);
Response.End();
将大文件分为小块下载
每次使用 while 循环读取文件中的 10,000 个字节，然后将这些文件块发送给浏览器。因此，在运行时文件不会有任何重要部分保留在内存中。文件块大小目前被设为一个常量，但可通过编程方式对其修改，甚至也可以将其移动到配置文件中，以便根据服务器限制和性能要求对其进行更改。
示例代码：// Buffer to read 10K bytes in chunk:
byte[] buffer = new Byte[10000];
int length;
long dataToRead;
System.IO.Stream iStream = null;
try
{
// Open the file.
iStream = new System.IO.FileStream(filepath, System.IO.FileMode.Open,
System.IO.FileAccess.Read, System.IO.FileShare.Read);
// Total bytes to read:
dataToRead = iStream.Length;
Response.ContentType = "application/octet-stream";
Response.AddHeader("Content-Disposition", "attachment; filename=" + filename);
// Read the bytes.
while (dataToRead > 0) {
// Verify that the client is connected.
if (Response.IsClientConnected) {
length = iStream.Read(buffer, 0, 10000);
Response.OutputStream.Write(buffer, 0, length);
Response.Flush();
buffer = new Byte[10000];
dataToRead = dataToRead - length;
}
else {
//prevent infinite loop if user disconnects
dataToRead = -1;
}
}
}
catch (Exception ex) {
Response.Write("Error : " + ex.Message);
}
finally {
if (iStream != null) {
iStream.Close();
}
}
文件分块并支持断点续传
结合将大文件分为小块下载和HTTP 1.1的两个标头元素Accept-Ranges/Etags实现对断点续传的支持。
为使 ASP.NET 下载应用程序实现可恢复下载功能，您需要能够拦截浏览器发出的请求（进行下载恢复），并使用请求中的 HTTP 标头在 ASP.NET 代码中明确表达相应的响应。要完成此操作，您应在正常处理序列中早一些捕获该请求。
示例代码：/// <summary>
/// 下载文件，支持大文件、续传、速度限制。支持续传的响应头Accept-Ranges、ETag，请求头Range 。
/// Accept-Ranges：响应头，向客户端指明，此进程支持可恢复下载.实现后台智能传输服务（BITS），值为：bytes；
/// ETag：响应头，用于对客户端的初始（200）响应，以及来自客户端的恢复请求，
/// 必须为每个文件提供一个唯一的ETag值（可由文件名和文件最后被修改的日期组成），这使客户端软件能够验证它们已经下载的字节块是否仍然是最新的。
/// Range：续传的起始位置，即已经下载到客户端的字节数，值如：bytes=1474560- 。
/// 另外：UrlEncode编码后会把文件名中的空格转换中+（+转换为%2b），但是浏览器是不能理解加号为空格的，所以在浏览器下载得到的文件，空格就变成了加号；
/// 解决办法：UrlEncode 之后, 将 "+" 替换成 "%20"，因为浏览器将%20转换为空格
/// </summary>
/// <param name="httpContext">当前请求的HttpContext</param>
/// <param name="filePath">下载文件的物理路径，含路径、文件名</param>
/// <param name="speed">下载速度：每秒允许下载的字节数</param>
/// <returns>true下载成功，false下载失败</returns>
public static bool DownloadFile(HttpContext httpContext, string filePath, long speed)
{
httpContext.Response.Clear();
bool ret = true;
try
{
#region --验证：HttpMethod，请求的文件是否存在#region
switch (httpContext.Request.HttpMethod.ToUpper())
{ //目前只支持GET和HEAD方法
case "GET":
case "HEAD":
break;
default:
httpContext.Response.StatusCode = 501;
return false;
}
if (!File.Exists(filePath))
{
httpContext.Response.StatusCode = 404;
return false;
}
#endregion
#region 定义局部变量#region 定义局部变量
long startBytes = 0;
long stopBytes = 0;
int packSize = 1024 * 10; //分块读取，每块10K bytes
string fileName = Path.GetFileName(filePath);
FileStream myFile = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
BinaryReader br = new BinaryReader(myFile);
long fileLength = myFile.Length;
int sleep = (int)Math.Ceiling(1000.0 * packSize / speed);//毫秒数：读取下一数据块的时间间隔
string lastUpdateTiemStr = File.GetLastWriteTimeUtc(filePath).ToString("r");
string eTag = HttpUtility.UrlEncode(fileName, Encoding.UTF8) + lastUpdateTiemStr;//便于恢复下载时提取请求头;
#endregion
#region --验证：文件是否太大，是否是续传，且在上次被请求的日期之后是否被修改过
if (myFile.Length > long.MaxValue)
{//-------文件太大了-------
httpContext.Response.StatusCode = 413;//请求实体太大
return false;
}
if (httpContext.Request.Headers["If-Range"] != null)//对应响应头ETag：文件名+文件最后修改时间
{
//----------上次被请求的日期之后被修改过--------------
if (httpContext.Request.Headers["If-Range"].Replace("\"", "") != eTag)
{//文件修改过
httpContext.Response.StatusCode = 412;//预处理失败
return false;
}
}
#endregion
try
{
#region -------添加重要响应头、解析请求头、相关验证
httpContext.Response.Clear();
if (httpContext.Request.Headers["Range"] != null)
{//------如果是续传请求，则获取续传的起始位置，即已经下载到客户端的字节数------
httpContext.Response.StatusCode = 206;//重要：续传必须，表示局部范围响应。初始下载时默认为200
string[] range = httpContext.Request.Headers["Range"].Split(new char[] { '=', '-' });//"bytes=1474560-"
startBytes = Convert.ToInt64(range[1]);//已经下载的字节数，即本次下载的开始位置
if (startBytes < 0 || startBytes >= fileLength)
{
//无效的起始位置
return false;
}
if (range.Length == 3)
{
stopBytes = Convert.ToInt64(range[2]);//结束下载的字节数，即本次下载的结束位置
if (startBytes < 0 || startBytes >= fileLength)
{
return false;
}
}
}
httpContext.Response.Buffer = false;
//httpContext.Response.AddHeader("Content-MD5", FileHash.MD5File(filePath));//用于验证文件
httpContext.Response.AddHeader("Accept-Ranges", "bytes");//重要：续传必须
httpContext.Response.AppendHeader("ETag", "\"" + eTag + "\"");//重要：续传必须
httpContext.Response.AppendHeader("Last-Modified", lastUpdateTiemStr);//把最后修改日期写入响应
httpContext.Response.ContentType = "application/octet-stream";//MIME类型：匹配任意文件类型
httpContext.Response.AddHeader("Content-Disposition", "attachment;filename=" + HttpUtility.UrlEncode(fileName, Encoding.UTF8).Replace("+", "%20"));
httpContext.Response.AddHeader("Content-Length", (fileLength - startBytes).ToString());
httpContext.Response.AddHeader("Connection", "Keep-Alive");
httpContext.Response.ContentEncoding = Encoding.UTF8;
if (startBytes > 0)
{//------如果是续传请求，告诉客户端本次的开始字节数，总长度，以便客户端将续传数据追加到startBytes位置后----------
httpContext.Response.AddHeader("Content-Range", string.Format("bytes {0}-{1}/{2}", startBytes, fileLength - 1, fileLength));
}
#endregion
#region -------向客户端发送数据块-------------------
br.BaseStream.Seek(startBytes, SeekOrigin.Begin);
int maxCount = (int)Math.Ceiling((fileLength - startBytes + 0.0) / packSize);//分块下载，剩余部分可分成的块数
for (int i = 0; i < maxCount && httpContext.Response.IsClientConnected; i++)
{//客户端中断连接，则暂停
httpContext.Response.BinaryWrite(br.ReadBytes(packSize));
httpContext.Response.Flush();
if (sleep > 1) Thread.Sleep(sleep);
}
#endregion
}
catch
{
ret = false;
}
finally
{
br.Close();
myFile.Close();
}
}
catch
{
ret = false;
}
return ret;
}
其它可能
- 使用FTP提供下载。可以利用FTP的特性进行权限控制。
- 扩展ISAPI以下载文件。
结论
基于Asp.net下载的方式可以更灵活的对用户权限、下载统计进行扩展，下面是几个方案的简单对比：
| 方法 | 优点 | 缺点 |
|---|---|---|
Response.Write/BinaryWrite |
代码简洁 | 大文件比较占用Server内存，可能把IIS托垮，不支持断点续传 |
Response.TransmitFile |
代码简洁，大文件下载对服务器端资源占用较少 | 不支持断点续传 |
| 将大文件分为小文件 | 大文件下载对服务器端资源占用较少 | 不支持断点续传 |
| 文件分块并支持断点续传 | 支持断点续传 | 需要编码实现 |
选择方案时，要根据可能需要支持的download文件大小以及用户的网络情况，做合理选择。如果需要支持的文件大小不是很大，可以直接使用TransmitFile进行下载，否则就要考虑支持断点续传。
附录
关于HTTP 1.1的两个标头元素Accept-Ranges和Etags的说明
Accept-Ranges 标头元素可以非常简单地向客户端（这里指 Web 浏览器）指明，此进程支持可恢复下载。实体标记或 Etag 元素将为该会话指定一个唯一标识符。因此，可由 ASP.NET 应用程序发送到浏览器以开始一个可恢复下载的 HTTP 标头可能如下所示：HTTP/1.1 200 OK
Connection: close
Date: Mon, 22 May 2006 11:09:13 GMT
Accept-Ranges: bytes
Last-Modified: Mon, 22 May 2006 08:09:13 GMT
ETag: "58afcc3dae87d52:3173"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 39551221
由于使用了 ETag 和 Accept-Headers，浏览器知道了 Web 服务器将支持可恢复下载。
如果下载失败，则当该文件再一次被请求时，Internet Explorer 将发送 ETag、文件名和指明在中断前已成功下载的文件字节数的值范围，以便 Web 服务器 (IIS) 可以尝试恢复下载。第二次请求可能如下所示。GET http://192.168.0.1/download.zip HTTP/1.0
Range: bytes=933714-
Unless-Modified-Since: Sun, 26 Sep 2004 15:52:45 GMT
If-Range: "58afcc3dae87d52:3173"
请注意，If-Range 元素包含服务器可用于标识要重新发送的文件的原始 ETag 值。您还会看到 Unless-Modified-Since 元素包含了最初下载的开始日期和时间。服务器将利用此信息来确定自最初下载开始后该文件是否已被修改过。如果已被修改，则服务器将从头开始重新下载。
Range 元素也包含在标头中，它会向服务器指明还需要传送多少字节才能完成文件，服务器可以利用此信息来确定应从已部分下载文件的何处开始继续下载。
不同浏览器使用这些标头的方式略有不同。客户端可能发送的用于唯一标识该文件的其他 HTTP 标头包括：If-Match、If-Unmodified-Since 和 Unless-Modified-Since。请注意，HTTP 1.1 在某个客户端应该需要支持哪些标头方面并没有特定要求。因此，就有可能出现这样的情况，某些 Web 浏览器不支持这些 HTTP 标头中的任一个，而其他浏览器可能使用不同于 IE 要求的标头的另一个标头。
默认情况下，IIS 将包含一个如下所示的标头集：HTTP/1.1 206 Partial Content
Content-Range: bytes 933714-39551221/39551222
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "58afcc3dae87d52:3173"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2021408
此标头集包含的响应代码不同于原始请求的响应代码。原始响应包含的代码为 200，而该请求使用的响应代码为 206（即“恢复下载”），用于向客户端指明，后面的数据不是一个完整文件，而只是继续先前启动的下载，该下载的文件名由 ETag 标识。
尽管某些 Web 浏览器依赖的是文件名其本身，但 Internet Explorer 非常明确地要求 ETag 标头。如果 ETag 标头在最初下载响应或下载恢复中不存在，则 Internet Explorer 不会尝试恢复下载，而只是开始一个新下载。