Nginx admite cargas G de gran tamaño y múltiples cargas de archivos adjuntos

I. Resumen

 

La llamada descarga reanudable en realidad solo se refiere a la descarga, es decir, a continuar la descarga desde el lugar donde se ha descargado el archivo. En la versión anterior del protocolo HTTP, no se admitían puntos de interrupción. Desde entonces se admite HTTP / 1.1. Los encabezados de entidad Range y Content-Range se utilizan generalmente cuando se descarga con un punto de interrupción. El protocolo HTTP en sí no admite la carga de puntos de interrupción, debe implementarlo usted mismo.

 

Dos, rango 

 

Se utiliza en el encabezado de la solicitud para especificar la posición del primer byte y la posición del último byte, el formato general:

 

    Rango: Se utiliza para solicitudes de cliente a servidor. Puede especificar el tamaño y la unidad de una determinada sección del archivo descargado cambiando el campo. El desplazamiento de bytes comienza desde 0. Formato típico:

    Rangos: (unidad = posición del primer byte) - [posición del último byte]

    Rangos: bytes = 4000 - descarga desde el byte 4000 hasta el final del archivo

    Rangos: bytes = 0 ~ N descargar el contenido del rango de bytes 0-N

    Rangos: bytes = MN Descargar el contenido del rango de bytes M-Nth

    Rangos: bytes = -N descargar los últimos N bytes de contenido


 

 

1. Es necesario tener en cuenta los siguientes puntos:

(1) Este intervalo de datos es un intervalo cerrado y el valor inicial es 0, por lo que una solicitud como "Rango: bytes = 0-1" es en realidad 2 bytes al comienzo de la solicitud.

(2) "Rango: bytes = -200", no indica los 201 bytes al principio del archivo solicitado, pero indica los 200 bytes al final del archivo solicitado.

(3) Si el último byte pos es menor que el primer byte pos, entonces la solicitud de rango es una solicitud inválida. El servidor debe ignorar la solicitud de rango y luego responder con un 200 y enviar el archivo completo al cliente.

(4) Si el último byte pos es mayor o igual a la longitud del archivo, entonces la solicitud de rango se considera insatisfecha y el servidor debe responder con un 416, rango solicitado no satisfactorio.

 

2. Ejemplo de explicación:

Representa los primeros 500 bytes: bytes = 0-499  

Representa los segundos 500 bytes: bytes = 500-999  

Representa los últimos 500 bytes: bytes = -500  

Indica el rango después de 500 bytes: bytes = 500-  

El primer y último byte: bytes = 0-0, -1  

Especifique varios rangos al mismo tiempo: bytes = 500-600,601-999 

 

Tres, rango de contenido

 

Se usa en el encabezado de respuesta para especificar la posición de inserción de una parte de la entidad completa y también indica la longitud de toda la entidad. Cuando el servidor devuelve una respuesta parcial al cliente, debe describir el alcance de la respuesta y la longitud de toda la entidad. Formato general: 

 

Rango de contenido: bytes (posición del primer byte de la unidad) - [posición del último byte] / [longitud de la entidad] 

 

Cuatro, ejemplo de encabezado

 

Solicitud para descargar el archivo completo: 

 

OBTENER /test.rar HTTP / 1.1 

Conexión: cerrar 

Anfitrión: 116.1.219.219 

Rango: bytes = 0-801 // Generalmente, la solicitud para descargar el archivo completo es bytes = 0- o no usar este encabezado

 

Respuesta normal 

 

HTTP / 1.1 200 OK 

Longitud del contenido: 801      

Tipo de contenido: aplicación / secuencia de octetos 

Rango de contenido: bytes 0-800 / 801 // 801: tamaño total del archivo

 

Una de las implementaciones más simples de transferencia reanudable es la siguiente:

1. El cliente descarga un archivo de 1024 K, de los cuales se han descargado 512 K

2. La red se interrumpe y el cliente solicita la reanudación, por lo que es necesario declarar los fragmentos que deben reanudarse en el encabezado HTTP:

Rango: bytes = 512000-

Este encabezado informa al servidor que comience a transferir el archivo desde la posición de 512K del archivo

3. El servidor recibe la solicitud para reanudar la transferencia con un punto de interrupción, comienza la transferencia desde la posición de 512K del archivo y agrega en el encabezado HTTP:

Rango de contenido: bytes 512000- / 1024000

Y en este momento, el código de estado HTTP devuelto por el servidor debería ser 206 en lugar de 200.

Sin embargo, en un escenario real, puede surgir una situación, es decir, cuando el terminal inicia una solicitud de reanudación, el contenido del archivo correspondiente a la URL ha cambiado en el lado del servidor y los datos de reanudación deben ser incorrectos en este momento. ¿Cómo resolver este problema? Obviamente, necesitamos una forma de identificar la singularidad del archivo en este momento. También hay definiciones correspondientes en RFC2616, como implementar Última modificación para identificar la última hora de modificación del archivo, de modo que se pueda juzgar si el archivo se ha modificado cuando se reanuda. Al mismo tiempo, RFC2616 también define un encabezado ETag, que se puede usar para colocar el identificador único del archivo, como el valor MD5 del archivo.

El terminal debe declarar el campo If-Match o If-Modified-Since en el encabezado HTTP al iniciar la solicitud de reanudación para ayudar al servidor a identificar el cambio de archivo.

Además, RFC2616 define un encabezado If-Range al mismo tiempo, y el terminal usa If-Range para reanudar la transmisión. El contenido en If-Range puede ser el primer encabezado ETag recibido o la última hora de modificación en Last-Modfied. Cuando el servidor recibe la solicitud de reanudación, verificará el contenido en el If-Range. Si la verificación es coherente, devolverá una respuesta de reanudación 206. Si es inconsistente, el servidor devolverá una respuesta de 200. El contenido de la respuesta es todo el archivo nuevo. datos.


Enlaces de referencia relacionados: http://blog.ncmem.com/wordpress/2019/08/09/http%e6%96%ad%e7%82%b9%e7%bb%ad%e4%bc%a0/ 
welcome Discusión de grupo: 374992201

Supongo que te gusta

Origin blog.csdn.net/weixin_45525177/article/details/108464184
Recomendado
Clasificación