http断点续传

注：本文转自http://blog.sina.com.cn/s/blog_ec8c9eae0102x3uu.html

http1.0和1.1区别：

在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 50-130
第二种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的。

单线程通常就是这样，那么我们的客户端是多线程呢，那么我们必定也是多线程。客户端会一次性发来多个请求，来贪婪的快速地下载完成文件。链接别太多就行了。会爆？Http/1.1协议 Content-Range头 用于http断点续传

断点续传实例：

1、客户端请求：
GET /123.zip HTTP/1.1

2、服务端响应
HTTP/1.1 200 OK 
Accept-Ranges : bytes   //告诉客户端，我们是支持断点传输的，你知道了吗？
Content-Length : 1900 //文件总大小 
Content-Type : image/jpeg //文件类型
二进制数据。

3、中断。
好了，就这样发送去了。发着发着，咦TM断掉了。我的七舅姥爷姑奶奶，为毛就断掉了呢，包租婆，怎么霎时间摸左水呐。

4、客户端请求断点续传
GET /123.zip HTTP/1.1 
Range：bytes=580-
大家看到没，会多了怎么一行，我们解析为从580字节开始到1900字节，是要部分内容耶，那么返回什么呢。没错206啊。

5、服务端响应断点续传
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   //这位同学，我想问问你，为什么结束字节要减1呢。这是因为发来的Range请求头文件下标是0开始，那么结尾数显示也要减1；但是实际上输出的字节是不减1的，完全是写法问题。

6、服务端断点续传文件操作
重点来了。假设我们用Hava RandomAccessFile类读取。
首先肯定是.seek(580 byte);
然后循环读取，读到结束字节=1900。