ASP.NET中大文件下载的跟踪和恢复来源: 发布时间:星期三, 2009年1月21日 浏览:6次 评论:0
在Web应用  中处理大文件下载 问题 直出了名困难 因此对于大多数站点来说如果用户下载被中断了它们只能说悲哀降临到用户身上了 但是我们现在不必这样了 你可以使自己ASP.NET应用有能力支持可恢复(继续)大文件下载使用本文提供思路方法时候你可以跟踪下载过程这样你就可以处理动态建立文件--而且要达到这个目标根本不需要旧式ISAPI动态链接库和非受控(unmanaged)C 代码 为客户端提供从互联网上下载文件 服务最容易了对吗？仅仅只需要把可下载文件复制到你Web应用目录中发布链接并让IIS完成所有相关工作但是文件服务不应该比脖子上疼痛还要多(还要麻烦)你不希望整个世界都能访问自己数据你不希望服务器被数百个静态文件塞满了你甚至于希望下载临时文件--只有当客户端开始下载后空闲时间才建立这些文件不幸 是使用IIS对下载请求默认响应是不可能达到这些效果因此在般情况下为了获得对下载过程控制权开发者需要链接到个定制.aspx页面在这个页面中它们检查用户凭证(credential)、建立可以下载文件并使用下面代码把该文件推送给客户端:Response.WriteFile Response.End 
而这就是出现真正麻烦 地方有什么问题？ WriteFile思路方法看起来非常完美 它使文件 2进制数据流向客户端但是直到最近我们才知道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)它包含个唯标识 串下面 代码显示了IIS发送给客户端用于响应个下载请求些头信息它向客户端传递了被请求文件详细信息 HTTP/1.1 200 OK Connection: close Date: Tue, 19 Oct 2004 15:11:23 GMT Accept-Ranges:  sLast-Mod  ied: Sun, 26 Sep 2004 15:52:45 GMTETag: "47febb2cfd76c41:2062" Cache-Control: private Content-Type: application/x-zip-compressed Content-Length: 2844011 在接收这些头信息的后 如果下载被中断了IE浏览器在后来下载请求中会把Etag值和Range头信息发送回服务器下面代码显示了尝试恢复被中断下载时IE发送给服务器些头信息GET http://192.168.100.100/download.zip HTTP/1.0 Range: s=822603-Unless-Mod ied-Since: Sun, 26 Sep 2004 15:52:45 GMTIf-Range: "47febb2cfd76c41:2062" 这些头信息表明IE缓存Cache了IIS提供 实体标签并在If-Range头信息中把它发送回服务器了这是确保下载从准确相同文件恢复种途径不幸是并非所有浏览器工作方式都相同客户端发送用于验证文件其它HTTP头信息可能是If-Match、If-Unmodied-Since或者Unless-Modied-Since很明显该规范标准对于客户端软件Software必须支持哪些头信息或者必须使用哪些头信息没有明确规定因此有些客户端根本就没有使用头信息而IE只使用If-Range和Unless-Modied-Since你最好用代码检查这些信息采用这种方式时候你应用可以在非常高层次遵循HTTP规范标准并可以使用多种浏览器Range头信息指明了被请求字节范围--在例子中它是服务器应该恢复文件流起始点
0
相关文章
读者评论
发表评论 |
 |
专注于互联网--专注于架构 |
最新标签 网站地图 文章索引 Rss订阅 |
