Does it take longer to download a zipped file than an unzipped file?

13

1

I once read somewhere that it takes longer to download a zipped file than an unzipped file of the same size, due to the nature of the zip file.

Is this true or nonsense?

edit: i'm speaking about HTTP traffic

jao

Posted 2009-09-23T12:48:59.157

Reputation: 1 780

1Over which protocol? – innaM – 2009-09-23T12:57:46.580

4Are you talking about two files of the same size one zipped and one unzipped (eg each 1MB), or the same file which is compressed and uncompressed (eg 1MB and 345KB) ? – Toby Allen – 2009-09-23T21:40:23.807

You should consider download rate, not time. In both cases, the rate is the same...in the end you downloaded a limited number of bytes in a given amount of time. Like Toby hints at, downloading a compressed files gets you more data uncompressed in the end, which effectively increases your uncompressed download rate. – KFro – 2009-09-23T22:18:16.600

Answers

21

When the connection is using compression, then of course.

You cannot efficiently compress data 2 times. So when compression is turned on, a 1 MB zip file will be transferred slower then a 1 MB txt file.

NB: This is dependent on the transfer protocol. FTP or other protocols don't have built-in compression. HTTP has.

Christopher

Posted 2009-09-23T12:48:59.157

Reputation: 909

Usually only slightly though.

You shouldn't gzip mp3, jpg or zips. – Rich Bradshaw – 2009-09-23T13:08:16.683

1It is configurable for which types to compress. So its up to the web-server administrator to first enable compression and then to disable compression for well known types. – Christopher – 2009-09-23T13:13:48.850

Will it transfer slower (slower over the pipe) or will it take longer to download because the server burned cycles re-zipping (slower to the pipe)? A nit-picky point because the end result is still a slower download. – MrChrister – 2009-09-23T13:39:43.100

3This is not a question of how long it does take to compress/decompress the data, because in most cases the connection is the bottleneck. The http compression is done on the transfers and not the file itself, so the latency is only increased by the latency of compressing the transfer and not the whole file. There is really no downside to enabling http-compression other then too high cpu usage on the server. On the other side, all server admins should disable the compression for transfers of files types which don't compress very well. – Christopher – 2009-09-23T16:28:51.360

11

It's not true if you are downloading via standard FTP or HTTP. For other connection types see Christopher's answer.

Assuming the same connection the speed of download is determined by the size of the file.

There might be a delay at the end of the download if you have automatic virus checking enabled as it will have to open and unpack the zip file to check the contents rather than being able to check the file directly.

ChrisF

Posted 2009-09-23T12:48:59.157

Reputation: 39 650

2Not if compression is used on the channel (see @Christopher's answer). – fretje – 2009-09-23T13:49:28.607

2

If you use a PPP (dial-up or VPN) connection with compression, zipped files may download with lower speed than text files due to their nature (the former are already compressed and the latter will be compressed by the protocol thus increasing measured speed).

But if you compare amounts of information you receive, downloading zipped files will still be more efficient because any file archiver is usually superior to link-layer compression. So a zipped text file will be downloaded faster than the same text file verbatim, even if compression increases download speed a little.

Bender

Posted 2009-09-23T12:48:59.157

Reputation: 906

0

Practical Answer: the purpose of zipping up your files is to make them easier to share (i.e.download) with other people. Zipping works by compression, which means 'shrinking files' in common english.

Computer software is not perfect, and there may be weird edge cases where zipping a file would make it slightly larger and harder to share. Finding these edge cases where zipping fails will likely bore you to tears and is not worth your time.

Hypothetical Answer: It's very complicated. The answer would depend on the zip program, transmission protocols, file size, file type, maybe even the browser type or antivirus software running on the client computer. In other words, "it depends."

CDeanMartin

Posted 2009-09-23T12:48:59.157

Reputation: 31

0

you must notice it's has no difference in HTTP protocol because in server and in router they use GZIP to zip packet and then send therefor if you zip or non they act the same.

Am1rr3zA

Posted 2009-09-23T12:48:59.157

Reputation: 4 715

0

As already mentioned, HTTP traffic can be compressed, but it isn't always.

You may have read this at a time when people used phone modems instead of adsl/cable modems. In this situation, the text was compressed before sending or receiving, so your text file would have been sent faster.

seanyboy

Posted 2009-09-23T12:48:59.157

Reputation: 1 568

2Some of us still use phone modems for Internet access. :-) – Brian Knoblauch – 2009-09-23T16:36:15.887

0

Not sure if this is related or not, but if you download one zipped file (zipped without compression) it's faster than downloading the same package as multiple (unzipped) files, due to the HTTP request overhead required before starting to download each individual file.

hasen

Posted 2009-09-23T12:48:59.157

Reputation: 4 556

-2

The answer is actually "it depends" : Depending on the format that the web-server chooses to send the file.

If the server generates the answer with binary as-is bytes, than equal-sized zipped and unzipped files will download in the same speed.

If the server generates a response in Base64 encoding, then it increases the number of the bytes and the zipped file will take longer to download. Most modern web-servers do not do that any more, although it used to be quite prevalent a few years ago.

To explain, base64 format is a stream of 6-bit displayable characters. That means, for example, that 6 binary bytes, which are 6*8=48 bits, are encoded as 48/6=8 characters. In general, for n binary bytes, the number of base64 characters that are sent is (n * 8) / 6. So sending n binary bytes is slower than sending n textual bytes by 33% (8 divided by 6), because more characters are sent.

harrymc

Posted 2009-09-23T12:48:59.157

Reputation: 306 093

1That's true for e-mail messages, but does not hold true for all other protocols. – Brian Knoblauch – 2009-09-23T20:01:39.637

It does hold for http, which was the question. http download uses multi-part encoding in base64 – harrymc – 2009-09-23T20:25:47.763

1I'm kinda doubting this, do you any reference to back it up? – hasen – 2009-09-23T21:45:01.847

1Nope, http generally does not base64 encode binary files. There is a mime type to declare that case, but it is generally only used for email where there is an expectation that the "packet" (the email message) will at some point pass through a connection that is not 8-bit clean. The TCP/IP protocol on which HTTP lies is guaranteed to be 8-bit clean and mime encoding content would only waste bandwidth. – RBerteig – 2009-09-23T22:14:38.747

1The server sending the file can choose among several formats. My answer related to a survey that I did about 5 years ago. At that time, quite a few sites were generating download multipart responses with Content-Transfer-Encoding (as distinct from the mime type). According to a quick check, this is no longer the case, and in fact the latest RFCs advice against using Content-Transfer-Encoding in http responses. So I believe that the real answer to the OP is : the calculation above used to be the case in the past for some web sites, but now is quite rare. However, it's not an urban myth. – harrymc – 2009-09-24T08:11:06.760