14

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

Improve this question
3
  • 1
    Over which protocol?
    – innaM
    Commented Sep 23, 2009 at 12:57
  • 4
    Are 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
    Commented Sep 23, 2009 at 21:40
  • 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
    Commented Sep 23, 2009 at 22:18

8 Answers 8

Reset to default
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.

Improve this answer
4
  • Usually only slightly though. You shouldn't gzip mp3, jpg or zips.
    – Rich Bradshaw
    Commented Sep 23, 2009 at 13:08
  • 1
    It 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
    Commented Sep 23, 2009 at 13:13
  • 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
    Commented Sep 23, 2009 at 13:39
  • 3
    This 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
    Commented Sep 23, 2009 at 16:28
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.

Improve this answer
1
  • 2
    Not if compression is used on the channel (see @Christopher's answer).
    – fretje
    Commented Sep 23, 2009 at 13:49
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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
1
  • 2
    Some of us still use phone modems for Internet access. :-)
    – Brian Knoblauch
    Commented Sep 23, 2009 at 16:36
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.

Improve this answer
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."

Improve this answer
-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.

Improve this answer
5
  • 1
    That's true for e-mail messages, but does not hold true for all other protocols.
    – Brian Knoblauch
    Commented Sep 23, 2009 at 20:01
  • It does hold for http, which was the question. http download uses multi-part encoding in base64
    – harrymc
    Commented Sep 23, 2009 at 20:25
  • 1
    I'm kinda doubting this, do you any reference to back it up?
    – hasen
    Commented Sep 23, 2009 at 21:45
  • 1
    Nope, 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
    Commented Sep 23, 2009 at 22:14
  • 1
    The 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
    Commented Sep 24, 2009 at 8:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .