注意，本文所说的断点续传特指 HTTP 协议中的断点续传。本文主要聊聊思路和关键代码，更多细节请参考本文附带的 demo。
工作原理
HTTP 协议中定义了一些请求/响应头，通过组合使用这些头信息。我们可以在一次 HTTP 请求中只请求一个文件中的一部分数据。这样我们就可以把已经下载的数据存起来，下次只用请求剩余的数据即可，当全部数据都下载到本地后再完成合并工作。
HTTP 协议指出，可以通过 HTTP 请求中的 Range 头指定请求数据的范围，Range 头的使用也很简单，只要指定下面的格式就可以了：
Range: bytes=500-999
它的意思是，只请求目标文件的第 500 到第 999 这 500 个字节。
比如我有一个1000 bytes 大小的文件需要下载，第一次请求时不用指定 Range 头，表示下载整个文件。但在下载完第 499 个字节后，下载被取消了。那么在下一次请求下载同一个文件时，只需要下载第 500 个字节至第 999 个字节的数据就可以了。原理看上去很简单，但我们需要考虑下面几个问题：
1．是不是所有的 web 服务器都支持 Range 头？
2．多次请求之间可能会间隔很长的时间，服务器上的文件发生了变化怎么办？
3．如何保存下载的部分数据和相关信息？
4．当我们通过字节操作把一个文件拼成原始大小后，如何验证它和源文件一模一样？
下面我们就带着这些问题去探究断点续传的一些细节。
检查服务器端对断点续传的支持
在服务器响应我们的请求时，会在响应头中通过 Accept-Ranges 指明是否接受请求一个资源的一部分数据。但这里似乎有个小小的陷阱，就是不同的服务器可能返回不同的值来指明自己能够接受部分资源的请求。貌似比较统一的方法是，当服务器不支持请求部分数据时，都会返回 Accept-Ranges: none，我们只要判断这个返回值是不是等于 none 就行了。代码如下：
private static bool IsAcceptRanges(WebResponse res)
{
if (res.Headers["Accept-Ranges"] != null)
{
string s = res.Headers["Accept-Ranges"];
if (s == "none")
{
return false;
}
}
return true;
}
检查服务器端文件是否变化
当我们下载了一个文件的一部分之后，可能马上就会接着下载，也可能会过一段时间再下载，也可能永远不会再接着下载了…
这里的问题是，当下次要接着下载时，如何确定服务器上的文件还是当初下载了一半的那个文件。如果服务器上的文件已经更新了，那无论如何都需要重新从头开始下载。只有在服务器上的文件没有发生变化的情况下，断点续传才有意义。
对于这个问题，HTTP 响应头为我们提供了不同的选择。ETag 和 Last-Modified 都能完成任务。
