Le téléchargement d'un fichier compressé prend-il plus de temps qu'un fichier décompressé?

13

J'ai lu une fois quelque part qu'il faut plus de temps pour télécharger un fichier compressé qu'un fichier décompressé de la même taille, en raison de la nature du fichier zip.

Est-ce vrai ou absurde?

edit: je parle du trafic HTTP

download zip

— jao
source

1

Sur quel protocole?

— innaM

4

Parlez-vous de deux fichiers de la même taille, un zippé et un décompressé (par exemple chaque 1 Mo), ou le même fichier qui est compressé et non compressé (par exemple 1 Mo et 345 Ko)?

— Toby Allen

Vous devriez considérer le taux de téléchargement, pas le temps. Dans les deux cas, le taux est le même ... au final, vous avez téléchargé un nombre limité d'octets dans un laps de temps donné. Comme Toby le laisse entendre, le téléchargement de fichiers compressés vous permet d'obtenir davantage de données non compressées, ce qui augmente efficacement votre taux de téléchargement non compressé.

— KFro

21

Lorsque la connexion utilise la compression , alors bien sûr.

Vous ne pouvez pas compresser efficacement les données 2 fois. Ainsi, lorsque la compression est activée, un fichier zip de 1 Mo sera transféré plus lentement qu'un fichier txt de 1 Mo.

NB: Cela dépend du protocole de transfert. FTP ou d'autres protocoles n'ont pas de compression intégrée. HTTP a.

— Christophe
source

Habituellement seulement légèrement cependant. Vous ne devriez pas gzip mp3, jpg ou zips.

— Rich Bradshaw

1

Il est configurable pour quels types compresser. Il appartient donc à l'administrateur du serveur Web d'activer d'abord la compression, puis de désactiver la compression pour les types bien connus.

— Christopher

Sera-t-il transféré plus lentement (plus lentement sur le tuyau) ou prendra-t-il plus de temps à télécharger parce que le serveur a brûlé des cycles de recompression (plus lentement sur le tuyau)? Un point difficile car le résultat final est toujours un téléchargement plus lent.

— MrChrister

3

Il ne s'agit pas de savoir combien de temps il faut pour compresser / décompresser les données, car dans la plupart des cas, la connexion est le goulot d'étranglement. La compression http est effectuée sur les transferts et non sur le fichier lui-même, donc la latence n'est augmentée que par la latence de compression du transfert et non du fichier entier. Il n'y a vraiment aucun inconvénient à activer la compression http autre qu'une utilisation CPU trop élevée sur le serveur. De l'autre côté, tous les administrateurs de serveur devraient désactiver la compression pour les transferts de types de fichiers qui ne se compressent pas très bien.

— Christopher

11

Ce n'est pas vrai si vous téléchargez via FTP ou HTTP standard. Pour d'autres types de connexion, voir la réponse de Christopher .

En supposant la même connexion, la vitesse de téléchargement est déterminée par la taille du fichier.

Il peut y avoir un retard à la fin du téléchargement si la vérification automatique des virus est activée car il devra ouvrir et décompresser le fichier zip pour vérifier le contenu plutôt que de pouvoir vérifier directement le fichier.

— ChrisF
source

2

Pas si la compression est utilisée sur le canal (voir la réponse de @ Christopher).

— fretje

2

Si vous utilisez une connexion PPP (accès à distance ou VPN) avec compression, les fichiers zippés peuvent être téléchargés à une vitesse inférieure à celle des fichiers texte en raison de leur nature (les premiers sont déjà compressés et les seconds seront compressés par le protocole augmentant ainsi la vitesse mesurée) .

Mais si vous comparez les quantités d'informations que vous recevez, le téléchargement de fichiers compressés sera toujours plus efficace car tout archiveur de fichiers est généralement supérieur à la compression de couche liaison. Ainsi, un fichier texte compressé sera téléchargé plus rapidement que le même fichier texte textuellement, même si la compression augmente un peu la vitesse de téléchargement.

— Cintreuse
source

0

vous devez remarquer qu'il n'y a pas de différence dans le protocole HTTP car dans le serveur et dans le routeur, ils utilisent GZIP pour compresser les paquets, puis les envoyer si vous compressez ou non, ils agissent de la même manière.

— Am1rr3zA
source

0

Comme déjà mentionné, le trafic HTTP peut être compressé, mais ce n'est pas toujours le cas.

Vous avez peut-être lu ceci à un moment où les gens utilisaient des modems téléphoniques au lieu de modems adsl / câble. Dans cette situation, le texte a été compressé avant l'envoi ou la réception, donc votre fichier texte aurait été envoyé plus rapidement.

— seanyboy
source

2

Certains d'entre nous utilisent encore des modems téléphoniques pour accéder à Internet. :-)

— Brian Knoblauch

0

Je ne sais pas si cela est lié ou non, mais si vous téléchargez un fichier compressé (compressé sans compression), c'est plus rapide que de télécharger le même package que plusieurs fichiers (décompressés), en raison de la surcharge de requête HTTP requise avant de commencer à télécharger chaque fichier individuel.

— hasen
source

0

Réponse pratique: le but de zipper vos fichiers est de les rendre plus faciles à partager (iedownload) avec d'autres personnes. Le zip fonctionne par compression, ce qui signifie `` rétrécissement des fichiers '' en anglais courant.

Les logiciels informatiques ne sont pas parfaits, et il peut y avoir des cas étranges où la fermeture éclair d'un fichier le rendrait légèrement plus grand et plus difficile à partager. Trouver ces cas de bord où la fermeture éclair échoue vous ennuiera probablement et ne vaut pas votre temps.

Réponse hypothétique: c'est très compliqué. La réponse dépendra du programme zip, des protocoles de transmission, de la taille du fichier, du type de fichier, peut-être même du type de navigateur ou du logiciel antivirus exécuté sur l'ordinateur client. En d'autres termes, "cela dépend".

— CDeanMartin
source

-2

La réponse est en fait "cela dépend": selon le format choisi par le serveur Web pour envoyer le fichier.

Si le serveur génère la réponse avec des octets binaires tels quels, les fichiers zippés et décompressés de taille égale seront téléchargés à la même vitesse.

Si le serveur génère une réponse dans le codage Base64, il augmente le nombre d'octets et le téléchargement du fichier compressé prendra plus de temps. La plupart des serveurs Web modernes ne le font plus, même si cela était très courant il y a quelques années.

Pour expliquer, le format base64 est un flux de caractères affichables 6 bits. Cela signifie, par exemple, que 6 octets binaires, qui sont 6 * 8 = 48 bits, sont codés en 48/6 = 8 caractères. En général, pour n octets binaires, le nombre de caractères base64 envoyés est (n * 8) / 6. Ainsi, l'envoi de n octets binaires est plus lent que l'envoi de n octets textuels de 33% (8 divisé par 6), car plus de caractères sont envoyés.

— harrymc
source

1

Cela est vrai pour les messages électroniques, mais n'est pas vrai pour tous les autres protocoles.

— Brian Knoblauch,

Cela vaut pour http, qui était la question. Le téléchargement http utilise l'encodage en plusieurs parties en base64

— harrymc

1

J'en doute un peu, avez-vous une référence pour le sauvegarder?

— hasen

1

Non, http n'encode généralement pas les fichiers binaires en base64. Il existe un type MIME pour déclarer ce cas, mais il n'est généralement utilisé que pour les e-mails où il est prévu que le "paquet" (l'e-mail) passe à un moment donné par une connexion qui n'est pas propre à 8 bits. Le protocole TCP / IP sur lequel repose HTTP est garanti comme étant propre en 8 bits et le contenu d'encodage MIME ne ferait que gaspiller la bande passante.

— RBerteig

1

Le serveur envoyant le fichier peut choisir entre plusieurs formats. Ma réponse concernait un sondage que j'ai fait il y a environ 5 ans. À cette époque, un certain nombre de sites généraient des réponses de téléchargement en plusieurs parties avec Content-Transfer-Encoding (par opposition au type MIME). Selon une vérification rapide, ce n'est plus le cas, et en fait les derniers conseils des RFC contre l'utilisation de Content-Transfer-Encoding dans les réponses http. Je pense donc que la vraie réponse au PO est: le calcul ci-dessus était le cas dans le passé pour certains sites Web, mais il est maintenant assez rare. Cependant, ce n'est pas un mythe urbain.

— harrymc