¿Cómo sabe un descargador de archivos dónde comienza el archivo?

Supongamos que estoy descargando un archivo a través del protocolo HTTP. Los paquetes que contienen los fragmentos del archivo pueden llegar en cualquier orden. Entonces, ¿cómo sabe el descargador qué paquete es el primero en el pedido? Estaba mirando los campos de un paquete HTTP aquí y no encontró ningún campo "Número de secuencia".

Después de reflexionar un poco sobre la pregunta, llegué a la conclusión de que HTTP es un protocolo de capa 7 y depende de los protocolos de las capas subyacentes. TCP, al ser un protocolo de capa 4, proporciona a HTTP este servicio de secuenciación de datos, ya que el encabezado TCP tiene un número de secuencia ( Lo encontré aquí ).

Pero, no estoy seguro si esta teoría es correcta, así que quiero preguntarle a los expertos al respecto. ¿Existe algún otro mecanismo para enfrentar este problema?

Entonces, en realidad, si no hay interrupción, el archivo se está descargando con una conexión TCP única. Así que tu descargador ni siquiera sabe que está fragmentado.

Puedes usar wirehark y ver este ejemplo aquí

Si la conexión se cae o si el administrador de descargas quiere dividir la descarga para que pueda usar 4 conexiones, por ejemplo, tiene que configurar el Encabezado de rango :

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023

En este caso, la respuesta sería

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024

Lo adivinaste. De RFC 2616 sección 1.4 Operación general , énfasis añadido:

Comunicación HTTP Por lo general, se lleva a cabo a través de conexiones TCP / IP. los      el puerto predeterminado es TCP 80 [19], pero se pueden usar otros puertos. Esto hace      no impide que se implemente HTTP sobre cualquier otro protocolo      en Internet, o en otras redes. HTTP solo asume un confiable      transporte; Se puede utilizar cualquier protocolo que proporcione tales garantías;      El mapeo de las estructuras de solicitud / respuesta HTTP / 1.1 en el      Las unidades de datos de transporte del protocolo en cuestión están fuera del alcance.      de esta especificación.

"transporte confiable" es la jerga de red para "entrega los datos sin pérdida (a menos que se indique), duplicación / reproducción, alteración o desorden".

Y de manera similar, HTTPS se ejecuta sobre TLS (anteriormente SSL), que se basa en TCP y proporciona esencialmente el mismo servicio (transporte de byte-stream confiable) pero con las propiedades adicionales de confidencialidad e integridad (a menos que se indique un error) incluso contra atacantes inteligentes en lugar de simplemente naturales Errores y fallas. Existen diferencias de rendimiento, pero AFAIK las únicas diferencias de servicio son que TLS no proporciona el puntero "urgente" de TCP, también conocido como fuera de banda, o cierre separado por dirección, como los estados "semicerrados" de TCP, y HTTP / HTTPS no lo hace t necesita esos