HTTP-断点续传和多线程下载

HTTP断点续传

  Range：客户端发请求的范围

  Content-Range：服务端返回当前请求范围和文件总大小

 

   续传成功返回206 

  文件又变动，返回200和新文件内容

 

 

HTTP1.1 协议（RFC2616）开始支持获取文件的部分内容，这为并行下载以及断点续传提供了技术支持。它通过在 Header 里两个参数实现的，客户端发请求时对应的是 Range ，服务器端响应时对应的是 Content-Range。

 

 

Range

用于请求头中，指定第一个字节的位置和最后一个字节的位置，一般格式：

 Range:(unit=first byte pos)-[last byte pos]

 

1.以下几点需要注意：

(1)这个数据区间是个闭合区间，起始值是0，所以“Range: bytes=0-1”这样一个请求实际上是在请求开头的2个字节。

(2)“Range: bytes=-200”，它不是表示请求文件开始位置的201个字节，而是表示要请求文件结尾处的200个字节。

(3)如果last byte pos小于first byte pos，那么这个Range请求就是无效请求，server需要忽略这个Range请求，然后回应一个200，把整个文件发给client。

(4)如果last byte pos大于等于文件长度，那么这个Range请求被认为是不能满足的，server需要回应一个416，Requested range not satisfiable。

 

2.示例解释：

 Range: bytes=0-499    表示第 0-499 字节范围的内容 

Range: bytes=500-999 表示第 500-999 字节范围的内容 

Range: bytes=-500   表示最后 500 字节的内容 

Range: bytes=500-   表示从第 500 字节开始到文件结束部分的内容 

Range: bytes=0-0,-1 表示第一个和最后一个字节 

Range: bytes=500-600,601-999 同时指定几个范围

 

 

Content-Range

用于响应头中，在发出带 Range 的请求后，服务器会在 Content-Range 头部返回当前接受的范围和文件总大小。一般格式：

 

Content-Range: bytes (unit first byte pos) - [last byte pos]/[entity legth]

 

例如：

 请求下载整个文件: 

 

GET /test.rar HTTP/1.1 

Connection: close 

Host: 116.1.219.219 

Range: bytes=0-801   //一般请求下载整个文件是bytes=0- 或不用这个头

 

一般正常回应 

 

HTTP/1.1 200 OK 

Content-Length: 801      

Content-Type: application/octet-stream 

Content-Range: bytes 0-800/801   //801:文件总大小

 

而在响应完成后，返回的响应头内容也不同：

HTTP/1.1 200 Ok（不使用断点续传方式） 

HTTP/1.1 206 Partial Content（使用断点续传方式）

 

 

总结：

 

HTTP1.1协议（RFC2616）中定义了断点续传相关的HTTP头 Range和Content-Range字段，一个最简单的断点续传实现大概如下： 

  1.客户端下载一个1024K的文件，已经下载了其中512K 

  2. 网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段： 

       Range:bytes=512000- 

    这个头通知服务端从文件的512K位置开始传输文件 

  3. 服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加： 

    Content-Range:bytes 512000-/1024000 

    并且此时服务端返回的HTTP状态码应该是206，而不是200。 

 

但是在实际场景中，会出现一种情况，即在终端发起续传请求时，URL对应的文件内容在服务端已经发生变化，此时续传的数据肯定是错误的。如何解决这个问题了？显然此时我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义，比如实现Last-Modified来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头，可以使用ETag头来放置文件的唯一标识，比如文件的MD5值。

 

终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段，帮助服务端判别文件变化。 

 

另外RFC2616中同时定义有一个If-Range头，终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时，通过If-Range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据。

 

===========================================================

多线程下载：

假设你要开发一个多线程下载工具，你会自然的想到把文件分割成多个部分，比如4个部分，然后创建4个线程，每个线程负责下载一个部分，如果文件大小为403个byte，那么你的分割方式可以为：0-99 (前100个字节)，100-199(第二个100字节)，200-299(第三个100字节)，300-402（最后103个字节）。

分割完成，每个线程都明白自己的任务，比如线程3的任务是负责下载200-299这部分文件，现在的问题是：线程3发送一个什么样的请求报文，才能够保证只请求文件的200-299字节，而不会干扰其他线程的任务。这时，我们可以使用HTTP1.1的Range头。Range头域可以请求实体的一个或者多个子范围，Range的值为0表示第一个字节，也就是Range计算字节数是从0开始的：

    

表示头500个字节：Range: bytes=0-499

    表示第二个500字节：Range: bytes=500-999

    表示最后500个字节：Range: bytes=-500

    表示500字节以后的范围：Range: bytes=500-

    第一个和最后一个字节：Range: bytes=0-0,-1

    同时指定几个范围：Range: bytes=500-600,601-999

所以，线程3发送的请求报文必须有这一行：

Range: bytes=200-299

 

服务器接收到线程3的请求报文，发现这是一个带有Range头的GET请求，如果一切正常，服务器的响应报文会有下面这行：

HTTP/1.1 206 OK

表示处理请求成功，响应报文还有这一行

Content-Range: bytes 200-299/403

斜杠后面的403表示文件的大小，通常Content-Range的用法为：

 . The first 500 bytes:

 Content-Range: bytes 0-499/1234

 

 . The second 500 bytes:

 Content-Range: bytes 500-999/1234

 

 . All except for the first 500 bytes:

 Content-Range: bytes 500-1233/1234

 

 . The last 500 bytes:

 Content-Range: bytes 734-1233/1234