在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）的一部分。

　　这个补丁引入了TransmitFile方法，它把一个磁盘文件读入到较小的内存缓冲区之后就开始传输该文件。尽管这个方案解决了内存和循环的问题，但是它仍然不能令人满意。你不能控制响应的生命周期。你无法知道下载是否正确地完成了，你没有办法知道下载是否被中断了，并且（如果你建立了临时文件）你也不知道是否应该、以及什么时候可以删除这些文件。更糟的是，如果下载的确失败了，TransmitFile方法又从客户端下次尝试的文件头部开始下载。

　　其中一种可能的解决方案--实现后台智能传输服务（BITS）对于多数站点来说是不可行的，因为这会毁掉维持客户端浏览器和操作系统独立性而作出的努力。

　　令人满意的解决方案的基础还是来自微软用于解决WriteFile引起的内存混乱问题的第一次尝试（见知识库文章812406）。那篇文章演示了智能的大块数据下载过程，它从文件流中读取数据。在服务器把字节块发送给客户端之前，它使用Response.IsClientConnected属性检查客户端是否仍然保持着连接。如果仍然保持连接，它就继续发送流字节，否则就停止，以防止服务器发送不必要的数据。
这就是我们采用的方法，特别是在下载临时文件的时候。在IsClientConnected返回False的情况下，你就知道下载过程被中断了，你应该保存文件；反之，当这个过程成功完成的时候，你就删除临时文件。此外，为了恢复中断了的下载，你需要做的工作是从上次下载尝试过程中客户端连接失败的文件点开始下载。

　　HTTP协议和头信息（Header）支持

　　HTTP协议支持可以用于处理被中断下载的头信息。使用少量的HTTP头信息，你可以增强自己的下载过程，使它完全遵循HTTP协议规范。这个规范与ranges一起提供恢复被中断的下载所需要的一切信息。

　　下面是它的工作方式。首先，如果服务器支持客户端断点续传，它就在初始的响应中发送Accept-Ranges头信息。服务器还发送一个实体标签（entity tag）头信息（ETag），它包含一个唯一的标识字符串。

[1] [2] [3] [4] [5] [6] 下一页