这一个HTTP头记录一下，可以的话或者能帮到别人。
在HTTP/1.1协议没出的时候，也就是HTTP/1.0协议，这种协议不可以使用长链接和断点续传和其他新特性；自从这个1.1被广大使用的现在，很多的下载器都被支持断点续传。
断点续传也就是从下载断开的哪里，重新接着下载，直到下载完整/可用。如果要使用这种断点续传，4个HTTP头不可少的，分别是Range头、Content-Range头、Accept-Ranges头、Content-Length头。这里我讲的是服务端，其中要用Range头是因为它是客户端发过来的信息。服务端是响应，而客户端（浏览器）是请求。
Range头必须要了解它，否则没法解析。请求中会带过来的断点信息，一般三种格式。
Range : bytes=50- 意思是从第50个字节开始到最后一个字节
Range : bytes=-70 意思是最后的70个字节
Range : bytes=50-100 意思是从第50字节到100字节
读取客户端发来的Range头解析为：
假设文件总大小为130字节。
第一种Range
第二种Range ( 130 - 70 )-130
第三种Range 50-100
还有一点要晓得的就是返回的HTTP状态码200、206、416这些意义。200是OK（一切正常），206是Partial Content（服务器已经成功处理了部分内容），416 Requested Range Not Satisfiable（对方（客户端）发来的Range 请求头不合理）。
一般处理单线程处理： 客户端发来请求 ——-> 服务端返回200 ——> 客户端开始接受数据 ——> 用户手多多把下载停止了 ——> 客户端突然停止接受数据 ——> 然后客户端都没说再见就与服务端断开了 ——> 用户手的痒了又按回开始键 ——> 客户端再次与服务端连接上，并发送Range请求头给服务端——> 这时服务端返回是206 ——> 服务端从断开的数据那继续发送，并且会发送响应头：Content-Range给客户端 ——>客户端接收数据 ——>直到完成。
再服务端返回206的前面，客户端假如发送了些不合理的Range请求头，服务端就不是返回206而是416。就是结尾字节大于开始字节或者是结尾字节是0什么的，这必定是416的。
单线程通常就是这样，那么我们的客户端是多线程呢，那么我们必定也是多线程。客户端会一次性发来多个请求，来贪婪的快速地下载完成文件。链接别太多就行了。会爆？
GET /123.zip HTTP/1.1
那我们告诉它。
HTTP/1.1 200 OK
Accept-Ranges : bytes
Content-Length : 1900 //文件总大小
Content-Type : image/jpeg //文件类型
二进制数据。
好了，就这样发送去了。发着发着，咦TM断掉了。我的七舅姥爷姑奶奶，为毛就断掉了呢，包租婆，怎么霎时间摸左水呐。
客户端又发来请求这回有点意思。
GET /123.zip HTTP/1.1
Range：bytes=580-
大家看到没，会多了怎么一行，我们解析为从580字节开始到1900字节，是要部分内容耶，那么返回什么呢。没错206啊。
HTTP/1.1 206 Partial Content
Accept-Ranges : bytes
Content-Type : image/jpeg //文件类型
Content-Length : （1900 - 580） //长度则不是总长度了，而580到1900共有多少字节。
Content-Range :bytes 580-（1900-1 ) / 1900
重点来了。假设我们用RandomAccessFile类读取。
首先肯定是.seek(开始字节=580 byte);
然后循环读取，读到结束字节=1900。
