How to distribute large files, large file transfer solution -HTML5

I. Overview

 

The so-called HTTP, in fact, refers only to download a file that is already downloaded from place to start to continue downloading. In the previous version of the HTTP protocol does not support breakpoints, HTTP / 1.1 beginning supported. Breakpoints generally used when downloading Range and Content-Range entity-header. HTTP protocol itself does not support the breakpoint upload, it needs its own implementation.

 

Two, Range 

 

The request header is used to specify the position of the first byte and the last byte of data, the general format:

 

    Range: a client requests the server can specify a certain period of the download file size followed by changing field, a byte offset from zero. Typical format:

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

    Ranges: bytes = 4000- 4000 bytes downloaded from the first portion to the end of file

    Ranges: bytes = 0 ~ N 0-N of the download byte range

    Ranges: bytes = MN MN downloads the first byte range

    Ranges: bytes = -N last N bytes downloaded content



 

1. The following points should be noted:

(1) This data section is closed interval, the start value is 0, the "Range: bytes = 0-1" in such a request is actually 2 bytes beginning of the request.

(2) "Range: bytes = -200", it is not used 201 bytes of the requested file start position, but rather a request for 200 bytes at the end of the file.

(3) If the last byte pos is less than the first byte pos, then the Range request is invalid requests, server need to ignore the Range request and respond with a 200, the entire file is sent to client.

(4) If the last byte pos than or equal to the length of the file, then the Range request can not be considered satisfied, server need to respond to a 416, Requested range not satisfiable.

 

2. Example explained:

Represents the first 500 bytes: bytes = 0-499  

Represents the second 500 bytes: bytes = 500-999  

Denotes the last 500 bytes: bytes = -500  

500 bytes beyond the range indicated: bytes = 500-  

The first and last bytes: bytes = 0-0, -1  

Specify several ranges: bytes = 500-600,601-999 

 

Three, Content-Range

 

Responsive head, designated insertion position in a portion of the entire body, he also indicates the length of the entire entity. Returns a response to the client part of the server, it must describe the overall physical length of the response from the scope and coverage. The general format: 

 

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

 

Four, Header Example

 

Request to download the entire file: 

 

GET /test.rar HTTP/1.1 

Connection: close 

Host: 116.1.219.219 

Range: bytes = 0-801 // general request to download the entire file is bytes = 0- or without the head

 

The normal response 

 

HTTP/1.1 200 OK 

Content-Length: 801      

Content-Type: application/octet-stream 

Content-Range: bytes 0-800 / 801 // 801: total file size


One of the most simple HTTP achieve something like:

1. 1024K client to download a file, which has been downloaded 512K

2. Network interruption, resume the client request, and therefore need to affirm this segment needs to resume the HTTP header:

Range:bytes=512000-

512K location of this head start transferring files from a file server notification

3. The HTTP server receives the request, transmitted from 512K start location of the file, and the increase in the HTTP header:

Content-Range:bytes 512000-/1024000

And at this time the server returns an HTTP status code should be 206 instead of 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回应,回应的内容为新的文件的全部数据。


相关参考链接:http://blog.ncmem.com/wordpress/2019/08/09/http%e6%96%ad%e7%82%b9%e7%bb%ad%e4%bc%a0/

Guess you like

Origin www.cnblogs.com/songsu/p/12134292.html