IE的自带下载功能中没有断点续传功能，要实现断点续传功能，需要用到HTTP协议中鲜为人知的几个响应头和请求头。
一. 两个必要响应头Accept-Ranges、ETag
客户端每次提交下载请求时，服务端都要添加这两个响应头，以保证客户端和服务端将此下载识别为可以断点续传的下载：
Accept-Ranges：告知下载客户端这是一个可以恢复续传的下载，存放本次下载的开始字节位置、文件的字节大小；
ETag：保存文件的唯一标识（我在用的文件名+文件最后修改时间，以便续传请求时对文件进行验证）；
Last-Modified：可选响应头，存放服务端文件的最后修改时间，用于验证
二. 一个重要请求头Range
Range：首次下载时，Range头为null，此时服务端的响应头中必须添加响应头Accept-Ranges、ETag；
续传请求时，其值表示客户端已经收到的字节数，即本次下载的开始字节位置，服务端依据这个 值从相应位置读取数据发送到客户端。
三. 用于验证的请求头If-Range、
当响应头中包含有Accept-Ranges、ETag时，续传请求时，将包含这些请求头：
If-Range：对应响应头ETag的值；
Unless-Modified-Since：对应响应头Last-Modified的值。
续传请求时，为了保证客户端与服务端的文件的一致性和正确性，有必要对文件进行验证，验证需要自己写验证代码，就根据解析这两个请求头的值，将客户端已下载的部分与服务端的文件进行对比，如果不吻合，则从头开始下载，如果吻合，则断点续传。
四. 速度限制
程序中加入了速度限制，用于对客户端进行权限控制的流量限制。
五. 其它注意事项
如：文件名乱码的问题、文件名中空格变加号、强制客户端显示下载对话框等，详见源码注释：
1
2 /// <summary>
3 /// 下载文件，支持大文件、续传、速度限制。支持续传的响应头Accept-Ranges、ETag，请求头Range 。
4 /// Accept-Ranges：响应头，向客户端指明，此进程支持可恢复下载.实现后台智能传输服务（BITS），值为：bytes；
5 /// ETag：响应头，用于对客户端的初始（200）响应，以及来自客户端的恢复请求，
6 /// 必须为每个文件提供一个唯一的ETag值（可由文件名和文件最后被修改的日期组成），这使客户端软件能够验证它们已经下载的字节块是否仍然是最新的。
7 /// Range：续传的起始位置，即已经下载到客户端的字节数，值如：bytes=1474560- 。
8 /// 另外：UrlEncode编码后会把文件名中的空格转换中+（+转换为%2b），但是浏览器是不能理解加号为空格的，所以在浏览器下载得到的文件，空格就变成了加号；
9 /// 解决办法：UrlEncode 之后, 将 “+” 替换成 “%20″，因为浏览器将%20转换为空格
10 /// </summary>
11 /// <param name=”httpContext”>当前请求的HttpContext</param>
12 /// <param name=”filePath”>下载文件的物理路径，含路径、文件名</param>
13 /// <param name=”speed”>下载速度：每秒允许下载的字节数</param>
14 /// <returns>true下载成功，false下载失败</returns>
15 public static bool DownloadFile(HttpContext httpContext, string filePath, long speed)
16 {
17 bool ret = true;
18 try
19 {
20 –验证：HttpMethod，请求的文件是否存在
36
37 定义局部变量
49
50 –验证：文件是否太大，是否是续传，且在上次被请求的日期之后是否被修改过————–
67
68 try
69 {
70 ——-添加重要响应头、解析请求头、相关验证——————-
97
98 ——-向客户端发送数据块——————-
108 }
109 catch
110 {
111 ret = false;
112 }
113 finally
114 {
115 br.Close();
116 myFile.Close();
117 }
118 }
119 catch
120 {
121 ret = false;
122 }
123 return ret;
124 }
上传展示截图：
详细配置信息可以参考我写的这篇文章：http://blog.ncmem.com/wordpress/2019/08/09/net%E6%96%AD%E7%82%B9%E7%BB%AD%E4%BC%A0/
