HTTP协议断点续传

HTTP协议从V1.1开始可以使用长链接和断点续传和其他新特性，断点续传也就是从下载中断的分块，重新进行下载，直到下载的数据完整/可用。

1. Range相关字段

V1.1版本HTTP协议支持的这种断点续传，Header中4个字段必须要弄清楚，分别是Range、Content-Range、Accept-Ranges、Content-Length。

一般客户端发起请求，服务端来响应，Range就是请求的Header中所携字段（其为断点信息，需要服务端解析），三种格式如下：
Range : bytes=50- 意思是从第50个字节开始到最后一个字节
Range : bytes=50-100 意思是从第50字节到100字节
Range : bytes=-70 意思是最后的70个字节

一个正常Conten-type的HTTP请求，其响应状态码一般为200（OK，一切正常）。但上/下载的Conten-type有所区别，状态码也不同，一般为206、416等。206是Partial Content（服务器已经成功处理了部分内容），416是Requested Range Not Satisfiable（请求中的Range 请求头不合理）。

2. 下载流程

单线程下载流程： client发来请求 —> server返回200 —> client开始接受数据 —> user突发暂停下载 —> client突然停止接受数据 —> 然后client都没说再见就与server断开 —> user可能又按开始键 —> client再次与服务端连接上，并发送Header中带Range的请求给server —> server响应码206 —> 服务端从中断的数据块继续发送，并且会发送响应头：Content-Range给客户端 —> 客户端接收数据 —> 直到完成。

当然，下载一个分块文件，客户端也可以多线程并行进行（一般线程数不会超过5个），那么，服务端也相应地有多线程进行响应。想一想，这样的文件分块应该在什么层次进行？

3. HTTP断点续传示例

//// client发来请求
GET /123.zip HTTP/1.1 

//// server响应
HTTP/1.1 200 OK 

Accept-Ranges : bytes // 告知client，server支持断点传输的

Content-Length : 1900 // 文件总大小 

Content-Type : image/jpeg // 文件类型

····· // 二进制数据

若发送过程中，种种原因导致传输中断...
客户端又发来请求，如下：

//// 客户端发送请求
GET /123.zip HTTP/1.1 

Range：bytes=580- // 从580字节开始到1900字节，获取部分数据内容

//// 服务端响应
HTTP/1.1 206 Partial Content // 注意，是响应码是206

Accept-Ranges : bytes // 接收断点续传

Content-Type : image/jpeg // 文件类型

Content-Length : （1900 - 580） // 长度非总长度，为580-1900

Content-Range :bytes 580-（1900-1 ) / 1900 // 因为文件字节从0开始，结束字节要减1

····· // 二进制数据

因此，用存取断点续传文件时，在下载过程中：

1. 一定要记录好resumeData，以便恢复中断的下载；
2. 续存下载的数据时，对于本例，client一定要先seek文件的尾部进行追加；server一定要seek(580 byte)，然后循环读取，读到结束字节=1900。
   重点来了。假设我们用Hava RandomAccessFile类读取。

参考文章：
https://zhuanlan.zhihu.com/p/43226601
https://blog.csdn.net/ye1992/article/details/49998511
https://blog.csdn.net/u013827143/article/details/86222486
https://www.cnblogs.com/lz2017/p/7146579.html
http://blog.sina.com.cn/s/blog_ec8c9eae0102x3uu.html