Il download di un file zippato richiede più tempo di un file decompresso?

13

Una volta ho letto da qualche parte che il download di un file zippato richiede più tempo rispetto a un file decompresso della stessa dimensione, a causa della natura del file zip.

È vero o senza senso?

modifica: sto parlando del traffico HTTP

download zip

— Jao
fonte

1

Su quale protocollo?

— innaM,

4

Stai parlando di due file della stessa dimensione uno zippato e uno decompresso (ad esempio ogni 1 MB) o lo stesso file che è compresso e non compresso (ad esempio 1 MB e 345 KB)?

— Toby Allen,

Dovresti considerare la velocità di download, non il tempo. In entrambi i casi, la velocità è la stessa ... alla fine hai scaricato un numero limitato di byte in un determinato periodo di tempo. Come suggerisce Toby, il download di un file compresso alla fine rende più dati non compressi, il che aumenta efficacemente la velocità di download non compresso.

— KFro,

21

Quando la connessione utilizza la compressione , ovviamente.

Non è possibile comprimere i dati in modo efficiente 2 volte. Pertanto, quando la compressione è attivata, un file zip da 1 MB verrà trasferito più lentamente di un file txt da 1 MB.

NB: dipende dal protocollo di trasferimento. FTP o altri protocolli non hanno una compressione integrata. HTTP ha.

— Christopher
fonte

Di solito solo leggermente però. Non dovresti gzip mp3, jpg o zip.

— Rich Bradshaw,

1

È configurabile per quali tipi comprimere. Quindi spetta all'amministratore del web server abilitare prima la compressione e poi disabilitare la compressione per tipi noti.

— Christopher,

Trasferirà più lentamente (più lentamente sulla pipe) o impiegherà più tempo a scaricarsi perché i cicli masterizzati dal server si ri-zippano (più lentamente sulla pipe)? Un punto pignolo perché il risultato finale è ancora un download più lento.

— MrChrister,

3

Non si tratta di quanto tempo ci vuole per comprimere / decomprimere i dati, perché nella maggior parte dei casi la connessione è il collo di bottiglia. La compressione http viene eseguita sui trasferimenti e non sul file stesso, quindi la latenza viene aumentata solo dalla latenza della compressione del trasferimento e non dell'intero file. Non c'è davvero alcun aspetto negativo nell'abilitare la compressione http oltre all'utilizzo della CPU troppo elevato sul server. D'altra parte, tutti gli amministratori del server dovrebbero disabilitare la compressione per i trasferimenti di tipi di file che non si comprimono molto bene.

— Christopher,

11

Non è vero se stai scaricando tramite FTP o HTTP standard. Per altri tipi di connessione vedere la risposta di Christopher .

Supponendo la stessa connessione, la velocità di download è determinata dalla dimensione del file.

Potrebbe esserci un ritardo alla fine del download se il controllo automatico dei virus è abilitato in quanto dovrà aprire e decomprimere il file zip per controllare il contenuto anziché essere in grado di controllare direttamente il file.

— ChrisF
fonte

2

Non se la compressione viene utilizzata sul canale (vedi la risposta di @ Christopher).

— fretje,

2

Se si utilizza una connessione PPP (dial-up o VPN) con compressione, i file compressi possono essere scaricati con una velocità inferiore rispetto ai file di testo a causa della loro natura (i primi sono già compressi e i secondi saranno compressi dal protocollo aumentando così la velocità misurata) .

Ma se si confrontano le quantità di informazioni che si ricevono, il download di file compressi sarà ancora più efficiente poiché qualsiasi archiviatore di file è in genere superiore alla compressione a livello di collegamento. Pertanto, un file di testo compresso verrà scaricato più velocemente dello stesso file di testo, anche se la compressione aumenta leggermente la velocità di download.

— piegatrice
fonte

0

devi notare che non ha alcuna differenza nel protocollo HTTP perché nel server e nel router usano GZIP per comprimere il pacchetto e quindi inviarlo se si zip o no si comportano allo stesso modo.

— Am1rr3zA
fonte

0

Come già accennato, il traffico HTTP può essere compresso, ma non sempre.

Potresti averlo letto in un momento in cui le persone usavano modem telefonici invece di modem adsl / via cavo. In questa situazione, il testo è stato compresso prima dell'invio o della ricezione, quindi il file di testo sarebbe stato inviato più velocemente.

— seanyboy
fonte

2

Alcuni di noi usano ancora modem telefonici per l'accesso a Internet. :-)

— Brian Knoblauch,

0

Non sono sicuro che sia correlato o meno, ma se scarichi un file zippato (zippato senza compressione) è più veloce del download dello stesso pacchetto di più file (decompressi), a causa dell'overhead della richiesta HTTP richiesto prima di iniziare a scaricare ogni singolo file.

— hasen
fonte

0

Risposta pratica: lo scopo di comprimere i tuoi file è di renderli più facili da condividere (iedownload) con altre persone. La compressione funziona tramite compressione, il che significa "ridurre i file" in inglese comune.

Il software per computer non è perfetto e potrebbero esserci strani casi limite in cui zippare un file lo renderebbe leggermente più grande e più difficile da condividere. Trovare questi casi limite in cui lo zipping fallisce probabilmente ti annoierà fino alle lacrime e non vale la pena.

Risposta ipotetica: è molto complicato. La risposta dipende dal programma zip, dai protocolli di trasmissione, dalle dimensioni del file, dal tipo di file, forse anche dal tipo di browser o dal software antivirus in esecuzione sul computer client. In altre parole, "dipende".

— CDeanMartin
fonte

-2

La risposta è in realtà "dipende": a seconda del formato che il server web sceglie di inviare il file.

Se il server genera la risposta con byte binari così come sono, i file zippati e decompressi di dimensioni uguali verranno scaricati alla stessa velocità.

Se il server genera una risposta nella codifica Base64, aumenta il numero di byte e il download del file zippato richiederà più tempo. La maggior parte dei moderni server Web non lo fa più, sebbene fosse piuttosto diffusa qualche anno fa.

Per spiegare, il formato base64 è un flusso di caratteri visualizzabili a 6 bit. Ciò significa, ad esempio, che 6 byte binari, che sono 6 * 8 = 48 bit, sono codificati come 48/6 = 8 caratteri. In generale, per n byte binari, il numero di caratteri base64 inviati è (n * 8) / 6. Quindi l'invio di n byte binari è più lento rispetto all'invio di n byte testuali del 33% (8 divisi per 6), perché più caratteri sono spediti.

— harrymc
fonte

1

Questo è vero per i messaggi di posta elettronica, ma non vale per tutti gli altri protocolli.

— Brian Knoblauch,

Vale per http, che era la domanda. Il download http utilizza la codifica multiparte in base64

— harrymc,

1

Ne dubito, hai qualche riferimento per eseguirne il backup?

— hasen

1

No, http in genere non codifica base64 per i file binari. Esiste un tipo mime per dichiarare quel caso, ma è generalmente usato solo per la posta elettronica dove ci si aspetta che il "pacchetto" (il messaggio di posta elettronica) passerà ad un certo punto attraverso una connessione che non è pulita a 8 bit. Il protocollo TCP / IP su cui si basa HTTP è garantito per essere pulito a 8 bit e il contenuto della codifica MIME perderebbe solo larghezza di banda.

— RBerteig,

1

Il server che invia il file può scegliere tra diversi formati. La mia risposta si riferiva a un sondaggio che ho fatto circa 5 anni fa. A quel tempo, parecchi siti generavano risposte multipart di download con Content-Transfer-Encoding (distinto dal tipo mime). Secondo un rapido controllo, questo non è più il caso, e in effetti gli ultimi consigli RFC contro l'uso di Content-Transfer-Encoding nelle risposte http. Quindi credo che la vera risposta all'OP sia: il calcolo di cui sopra era il caso in passato per alcuni siti Web, ma ora è piuttosto raro. Tuttavia, non è un mito urbano.

— harrymc,