One-time compressed or encrypted data – streams that are never to be seen again and have already been compressed or encrypted, such as encrypted SSH tunnels and real-time video camera monitoring – are not compress, since their data streams are never the same twice.
Compressed binary data or encrypted data that is seen more than once compresses extremely well on the second and subsequent transfers, with compression ratios in the range of hundreds to thousands to one on these later transfers. On the first transfer, they do not compress. The average compression ratio for such data is dependent on how frequently data is seen more than once. While individual transfers sometimes show compression ratios over 1,000:1, averages for the compressed binary data on the link averages between 1.5:1 and 5:1 on most links, with averages over 10:1 on some links, depending on the nature of the traffic.
Text streams and uncompressed/unencrypted binary data compress even on the first pass. Text streams compress well because even unrelated texts have many substrings in common. This is true of documents, source code, HTML pages, and so on. First-pass compression on the order of 1.5:1 to 4:1 are common. On the second and subsequent passes, they compress almost as well as compressed binary data (100:1 or more). Uncompressed binary data is variable, but often compresses better than text. Examples of uncompressed binary data include CD images, executable files, and uncompressed image, audio, and video formats. On the second and subsequent passes, they compress about as well as compressed binary data.
XenApp and XenDesktop data compresses especially well with file transfers, printer output, and video, provided that the same data streams have traversed the link before. Because of protocol overhead, peak compression is approximately 40:1, and average compression is likely to be in the neighborhood of 3:1. Interactive data streams, such as screen updates), give compression results on the order of 2:1.
Compression, on the other hand, has no concept of object names, and provided benefit whenever a string in the transfer matches one that is already in compression history. This means that if you download a file, change 1% of its content, and upload the new file, you might achieve 99:1 compression on the upload. If you download a file and then upload it to a different directory on the remote site, you might achieve a high compression ratio as well. Compression does not require file locking and does not suffer from “staleness.” The object is always fetched from the server and is thus always byte-for-byte correct.