¿Se tarda más en descargar un archivo comprimido que un archivo descomprimido?

13

Una vez leí en alguna parte que toma más tiempo descargar un archivo comprimido que un archivo comprimido del mismo tamaño, debido a la naturaleza del archivo comprimido.

¿Es esto cierto o sin sentido?

editar: estoy hablando sobre el tráfico HTTP

download zip

— jao
fuente

1

¿Sobre qué protocolo?

— innaM

44

¿Está hablando de dos archivos del mismo tamaño, uno comprimido y otro descomprimido (por ejemplo, cada 1 MB), o el mismo archivo comprimido y sin comprimir (por ejemplo, 1 MB y 345 KB)?

— Toby Allen

Debe considerar la velocidad de descarga, no el tiempo. En ambos casos, la velocidad es la misma ... al final descargó un número limitado de bytes en un período de tiempo determinado. Como sugiere Toby, la descarga de archivos comprimidos le permite obtener más datos sin comprimir al final, lo que aumenta efectivamente su velocidad de descarga sin comprimir.

— KFro

21

Cuando la conexión está usando compresión , entonces, por supuesto.

No puede comprimir eficientemente los datos 2 veces. Entonces, cuando la compresión está activada, un archivo zip de 1 MB se transferirá más lentamente que un archivo txt de 1 MB.

NB: esto depende del protocolo de transferencia. FTP u otros protocolos no tienen compresión incorporada. HTTP tiene.

— Christopher
fuente

Por lo general, solo un poco. No debes comprimir mp3, jpg o zips.

— Rich Bradshaw

1

Es configurable para qué tipos comprimir. Por lo tanto, depende del administrador del servidor web habilitar primero la compresión y luego deshabilitar la compresión para tipos conocidos.

— Christopher

¿Se transferirá más lentamente (más lento a través de la tubería) o tardará más en descargarse porque el servidor grabó los ciclos volviendo a comprimir (más lento a la tubería)? Un punto quisquilloso porque el resultado final sigue siendo una descarga más lenta.

— MrChrister

3

No se trata de cuánto tiempo lleva comprimir / descomprimir los datos, porque en la mayoría de los casos la conexión es el cuello de botella. La compresión http se realiza en las transferencias y no en el archivo en sí, por lo que la latencia solo se incrementa por la latencia de comprimir la transferencia y no todo el archivo. Realmente no hay inconveniente para habilitar la compresión http, aparte del uso de CPU demasiado alto en el servidor. Por otro lado, todos los administradores del servidor deberían deshabilitar la compresión para las transferencias de tipos de archivos que no se comprimen muy bien.

— Christopher

11

No es cierto si está descargando a través de FTP o HTTP estándar. Para otros tipos de conexión, vea la respuesta de Christopher .

Suponiendo la misma conexión, la velocidad de descarga está determinada por el tamaño del archivo.

Puede haber un retraso al final de la descarga si tiene habilitada la verificación automática de virus, ya que tendrá que abrir y descomprimir el archivo zip para verificar el contenido en lugar de poder verificar el archivo directamente.

— ChrisF
fuente

2

No si se usa compresión en el canal (ver la respuesta de @ Christopher).

— fretje

2

Si usa una conexión PPP (dial-up o VPN) con compresión, los archivos comprimidos pueden descargarse a una velocidad menor que los archivos de texto debido a su naturaleza (los primeros ya están comprimidos y el segundo será comprimido por el protocolo aumentando así la velocidad medida) .

Pero si compara la cantidad de información que recibe, la descarga de archivos comprimidos seguirá siendo más eficiente porque cualquier archivador de archivos suele ser superior a la compresión de la capa de enlace. Por lo tanto, un archivo de texto comprimido se descargará más rápido que el mismo archivo de texto textualmente, incluso si la compresión aumenta un poco la velocidad de descarga.

— Juerga
fuente

0

debe notar que no tiene ninguna diferencia en el protocolo HTTP porque en el servidor y en el enrutador usan GZIP para comprimir el paquete y luego lo envían si lo comprimen o no, actúan de la misma manera.

— Am1rr3zA
fuente

0

Como ya se mencionó, el tráfico HTTP se puede comprimir, pero no siempre es así.

Es posible que haya leído esto en un momento en que las personas usaban módems telefónicos en lugar de módems adsl / cable. En esta situación, el texto se comprimió antes de enviarlo o recibirlo, por lo que su archivo de texto se habría enviado más rápido.

— seanyboy
fuente

2

Algunos de nosotros todavía utilizamos módems telefónicos para acceder a Internet. :-)

— Brian Knoblauch el

0

No estoy seguro de si esto está relacionado o no, pero si descarga un archivo comprimido (comprimido sin compresión) es más rápido que descargar el mismo paquete que varios archivos (descomprimidos), debido a la sobrecarga de la solicitud HTTP requerida antes de comenzar a descargar cada archivo individual.

— Hasen
fuente

0

Respuesta práctica: el propósito de comprimir sus archivos es hacerlos más fáciles de compartir (es decir, descargar) con otras personas. La compresión funciona por compresión, lo que significa 'reducir archivos' en inglés común.

El software de la computadora no es perfecto, y puede haber casos extraños en los que comprimir un archivo lo haría un poco más grande y difícil de compartir. Encontrar estos casos extremos donde falla la compresión probablemente te hará llorar y no vale la pena tu tiempo.

Respuesta hipotética: es muy complicado. La respuesta dependería del programa zip, los protocolos de transmisión, el tamaño del archivo, el tipo de archivo, tal vez incluso el tipo de navegador o el software antivirus que se ejecuta en la computadora cliente. En otras palabras, "depende".

— CDeanMartin
fuente

-2

La respuesta es en realidad "depende": según el formato que el servidor web elija para enviar el archivo.

Si el servidor genera la respuesta con bytes binarios tal como están, los archivos comprimidos y descomprimidos del mismo tamaño se descargarán a la misma velocidad.

Si el servidor genera una respuesta en la codificación Base64, entonces aumenta el número de bytes y el archivo comprimido tardará más en descargarse. La mayoría de los servidores web modernos ya no lo hacen, aunque solía ser bastante frecuente hace unos años.

Para explicar, el formato base64 es una secuencia de caracteres visualizables de 6 bits. Eso significa, por ejemplo, que 6 bytes binarios, que son 6 * 8 = 48 bits, están codificados como 48/6 = 8 caracteres. En general, para n bytes binarios, el número de 64 caracteres básicos que se envían es (n * 8) / 6. Por lo tanto, enviar n bytes binarios es más lento que enviar n bytes textuales en un 33% (8 dividido por 6), porque hay más caracteres se envían.

— harrymc
fuente

1

Eso es cierto para los mensajes de correo electrónico, pero no es cierto para todos los demás protocolos.

— Brian Knoblauch, el

Es válido para http, que era la pregunta. descarga http utiliza codificación de varias partes en base64

— harrymc

1

Dudo un poco de esto, ¿alguna referencia para respaldarlo?

— hasen

1

No, http generalmente no codifica los archivos binarios en base64. Hay un tipo MIME para declarar ese caso, pero generalmente solo se usa para correo electrónico donde existe la expectativa de que el "paquete" (el mensaje de correo electrónico) pasará en algún momento a través de una conexión que no esté limpia de 8 bits. Se garantiza que el protocolo TCP / IP en el que se encuentra HTTP será limpio de 8 bits y el contenido de codificación MIME solo desperdiciaría el ancho de banda.

— RBerteig

1

El servidor que envía el archivo puede elegir entre varios formatos. Mi respuesta se relacionó con una encuesta que hice hace unos 5 años. En ese momento, bastantes sitios estaban generando descargas de respuestas multiparte con Content-Transfer-Encoding (a diferencia del tipo mime). Según una comprobación rápida, este ya no es el caso, y de hecho, el último consejo de RFC contra el uso de Content-Transfer-Encoding en respuestas http. Así que creo que la respuesta real al OP es: el cálculo anterior solía ser el caso en el pasado para algunos sitios web, pero ahora es bastante raro. Sin embargo, no es un mito urbano.

— harrymc