在Web应用程序中处理大文件下载的问题一直出了名的困难，因此对于大多数站点来说，如果用户的下载被中断了，它们只能说悲哀降临到用户的身上了。但是我们现在不必这样了，因为你可以使自己的ASP.NET应用程序有能力支持可恢复（继续）的大文件下载。 使用本文提供的方法的时候，你可以跟踪下载的过程，这样你就可以处理动态建立的文件--而且要达到这个目标根本不需要旧式的ISAPI动态链接库和非受控的（unmanaged）C++代码。

　　为客户端提供从互联网上下载文件的服务最容易了，对吗？仅仅只需要把可下载的文件复制到你的Web应用程序目录中，发布链接并让IIS完成所有相关的工作。但是，文件服务不应该比脖子上的疼痛还要多（还要麻烦），你不希望整个世界都能访问自己的数据，你不希望服务器被数百个静态文件塞满了，你甚至于希望下载临时文件--只有当客户端开始下载后的空闲时间才建立这些文件。

　　不幸的是，使用IIS对下载请求的默认的响应是不可能达到这些效果的。因此在一般情况下，为了获得对下载过程的控制权，开发者需要链接到一个定制的.aspx页面，在这个页面中它们检查用户凭证（credential）、建立可以下载的文件并使用下面的代码把该文件推送给客户端：

Response.WriteFile
Response.End()
　　而这就是出现真正麻烦的地方。

　　有什么问题？

　　WriteFile方法看起来非常完美，它使文件的二进制数据流向客户端。但是直到最近我们才知道，WriteFile方法是一个出名的内存占用狂，它把整个文件载入服务器的RAM中来提供服务（实际上它甚至于会占用文件两倍大小的空间）。对于大文件，这会引起服务内存问题，并且可能重复ASP.NET过程。但是在2004年6月微软发布了一个补丁解决了这个问题。这个补丁现在是.NET Framework 1.1补丁包（SP1）的一部分。

(编辑:aniston)