ASP.NET中大文件下载的跟踪和恢复

在接收这些头信息之后，如果下载被中断了，IE浏览器在后来的下载请求中会把Etag值和Range头信息发送回服务器。下面的代码显示了尝试恢复被中断下载时IE发送给服务器的一些头信息。

GET http://192.168.100.100/download.zip HTTP/1.0
Range: bytes=822603-
Unless-Modified-Since: Sun, 26 Sep 2004 15:52:45 GMT
If-Range: "47febb2cfd76c41:2062"

这些头信息表明IE缓存了IIS提供的实体标签，并在If-Range头信息中把它发送回服务器了，这是确保下载从准确相同的文件恢复的一种途径。不幸的是，并非所有的浏览器的工作方式都相同。客户端发送的用于验证文件的其它HTTP头信息可能是If-Match、If-Unmodified-Since或者Unless-Modified-Since.很明显，该规范对于客户端软件必须支持哪些头信息，或者必须使用哪些头信息没有明确的规定。因此，有些客户端根本就没有使用头信息，而IE只使用If-Range和Unless-Modified-Since.你最好用代码检查这些信息。采用这种方式的时候，你的应用程序可以在非常高的层次遵循HTTP规范，并可以使用多种浏览器。Range头信息指明了被请求的字节范围——在例子中它是服务器应该恢复文件流的起始点。

当IIS接收到恢复下载的请求类型时，它发回包含下面的头信息的响应信息：

HTTP/1.1 206 Partial Content
Content-Range: bytes 822603-2844010/2844011
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "47febb2cfd76c41:2062"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2021408

请注意上面的代码与最初的下载请求的HTTP响应有点差别——恢复下载的请求是206而最初下载的请求是200.这表明通过线路传递进来的内容是部分文件。这一次Content-Range头信息指出了被传递字节的精确数量和位置。

IE对于这些头信息是很挑剔的。如果最初的响应没有包含Etag头信息，IE永远不会尝试恢复下载。我测试过的其它客户端不使用ETag头信息，它们简单得依赖于文件名、请求范围，并使用Last-Modified头信息（如果它们试图验证该文件）。

深入了解HTTP协议

前面的部分中显示的头信息对于使恢复下载的解决方案运行来说是足够的，但是它没有完全覆盖HTTP规范。

在单个请求中，Range头信息可以询问多个范围，这种特性称为"多部分范围（multipart ranges）".请不要与分段下载（segmented downloading）混淆，几乎所有的下载工具都使用分段下载来提高下载速度。这些工具声称通过打开两个或多个并发的连接（每个连接请求文件的不同范围）提高了下载速度。

多部分范围的想法并没有开启多个连接，但是它可以使客户端软件可以在单个请求/响应周期中请求某个文件的最前面的十个和最后面的十个字节。

诚实地说，我从来都没有找到使用这种特性软件片断。但是我拒绝在代码声明中写入"它并不是完全的HTTP兼容的".略去这个特性必定会触犯墨菲法则（Murphy''s Law）。无论如何，多部分范围还是被用于电子邮件传输中，把头信息、普通文本和附件分开。