HTTP之Range理解

　1、什么是Range？

　　当用户在听一首歌的时候，如果听到一半（网络下载了一半），网络断掉了，用户需要继续听的时候，文件服务器不支持断点的话，则用户需要重新下载这个文件。而Range支持的话，客户端应该记录了之前已经读取的文件范围，网络恢复之后，则向服务器发送读取剩余Range的请求，服务端只需要发送客户端请求的那部分内容，而不用整个文件发送回客户端，以此节省网络带宽。

　2、HTTP1.1规范的Range是怎样一个约定呢？

　　如果Server支持Range，首先就要告诉客户端，咱支持Range，之后客户端才可能发起带Range的请求。这里套用唐僧的一句话，你不说我怎么知道呢。response.setHeader('Accept-Ranges', 'bytes');

　　Server通过请求头中的Range: bytes=0-xxx来判断是否是做Range请求，如果这个值存在而且有效，则只发回请求的那部分文件内容，响应的状态码变成206，表示Partial Content，并设置Content-Range。如果无效，则返回416状态码，表明Request Range Not Satisfiable（http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.17 ）。如果不包含Range的请求头，则继续通过常规的方式响应。

3、应用

Range，是在 HTTP/1.1（http://www.w3.org/Protocols/rfc2616/rfc2616.html）里新增的一个 header field，也是现在众多号称多线程下载工具（如 FlashGet、迅雷等）实现多线程下载的核心所在。

Range 的规范定义如下：
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit “=” byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos “-” [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
（RFC2616 里充斥着这种形式的定义，一开始觉得挺乱，后来习惯了就发现其实挺科学，挺好理解的:)）

值得注意的就是 byte-range-set 是一个 byte-range 的集合，所以在实际请求中完全可能会出现如下这种形式：
Range: bytes=123-567,789-
这个数据区间是个闭合区间，起始值是 0，所以“Range: bytes=0-1”这样一个请求实际上是在请求开头的 2 个字节。

byte-range-spec 里的 last-byte-pos 可以省略，代表从 first-byte-pos 一直请求到结束位置。其实 first-byte-pos 也是可以省略的，只不过就不叫 byte-range-spec 了，而是叫 suffix-byte-range-spec，规范如下：
suffix-byte-range-spec = “-” suffix-length
suffix-length = 1*DIGIT
比如“Range: bytes=-200”，它不是表示请求文件开始位置的 201 个字节，而是表示要请求文件结尾处的 200 个字节。

如果 byte-range-spec 的 last-byte-pos 小于 first-byte-pos，那么这个 Range 请求就是无效请求，server 需要忽略这个 Range 请求，然后回应一个 200 OK，把整个文件发给 client。
如果 byte-range-spec 里的 first-byte-pos 大于文件长度，或者 suffix-byte-range-spec 里的 suffix-length 等于 0，那么这个 Range 请求被认为是不能满足的，server 需要回应一个 416 Requested range not satisfiable。

server 除了要能理解 Range 请求之外，在回应 client 时还要使用 Content-Range 来告诉 client 他到底发送了多少数据，Content-Range 的规范定义如下：
Content-Range = “Content-Range” “:” content-range-spec
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP byte-range-resp-spec “/” ( instance-length | “*” )
byte-range-resp-spec = (first-byte-pos “-” last-byte-pos) | “*”
instance-length = 1*DIGIT

详尽的细枝末节就不在这里记述了，举个例子说明一下，比如某文件的大小是 1000 字节，client 请求这个文件时用了 “Range: bytes=0-500”，那么 server 应该把这个文件开头的 501 个字节发回给 client，同时回应头要有如下内容：
Content-Range: bytes 0-500/1000

Range 请求的一些注意事项：
1) 不支持 Range 请求的 server 要用“Accept-Ranges: none”对 client 表明心意；server 也可以主动告诉 client “Accept-Ranges: bytes”，但是 client 也可以在没有收到这个指示的前提下向 server 发 Range 请求。
2) byte-range-set 中的区间可以是“有洞”的，也可以是部分重叠的
3) 单区间的 byte-range-set 正常回应就可以了，但是多区间 byte-range-set 需要 server 使用 multipart/byterange 来回应

Range头域
　　Range头域可以请求实体的一个或者多个子范围。例如，
　　表示头500个字节：bytes=0-499
　　表示第二个500字节：bytes=500-999
　　表示最后500个字节：bytes=-500
　　表示500字节以后的范围：bytes=500-
　　第一个和最后一个字节：bytes=0-0,-1
　　同时指定几个范围：bytes=500-600,601-999

4、Range相关的问题

（1）、写多线程下载时老报Http416的错误，正常的话应该返回code 206，但是这次却不正常，后来研究了一下，发现如下问题：
以下是错误log：
Server returned HTTP response code: 416 for URL: http://localhost:8080/QQ.exe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at com.lyc.download.Demo$DownloadThread.run(Demo.java:97)

HTTP response code: 416是由于读取文件时设置的Range有误造成的，具体的说就是下面这行代码有误：

connection.setRequestProperty("Range",
"bytes=:"+startIndex+"-"+endIndex);

中间的冒号：就是罪魁祸首，敲代码的时候不小心多敲了个冒号造成的；

（2）xutils android框架下载文件时，如果文件下载完成还继续下载会报”maybe the file has downloaded completely“