网络文件传输断点续传，带进度条和判断文件是否一致还有就是重复文件自动重命名。

有点多线程基础的可以自己弄成多文件 多线程下载哦，

这一个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    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协议 <wbr>Content-Range头 <wbr>用于http断点续传

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

重点来了。假设我们用Hava RandomAccessFile类读取。

首先肯定是.seek(580 byte);

然后循环读取，读到结束字节=1900。