在我們傳輸數據之前，什麼讓我們壓縮數據？

Question

我想知道爲什麼我們需要應用文件壓縮之前，我們上傳文件到服務器在某些情況下。據我的理解，只要服務器收到壓縮文件，就需要提取壓縮文件以允許服務器讀取文件內容。如果從多個客戶端平臺發送多個Http POST，肯定會消耗服務器的計算能力。

因此，據我所能想到的發送壓縮文件的場景是上傳備份文件，設置文件，只有服務器作爲客戶端平臺備份的文件。請給我更多上傳壓縮數據的場景。

Answer 1

我想下面的文章給了這個問題一個完美的解釋：http://www.dataexpedition.com/support/notes/tn0014.html

這裏的內容：

壓縮優點&缺點

簡單地說，壓縮是換CPU的過程週期爲字節。但交易並不總是一個好的。有時你可以花很多寶貴的CPU週期來獲得很少或沒有收益。

在網絡數據傳輸的情況下，「我應該壓縮嗎？」是一個常見的問題。但是，根據幾個因素，答案可能會變得複雜。要記住的最重要的事情是，壓縮實際上可以使數據移動得更慢，所以不應該在沒有考慮的情況下使用它。

當壓縮好時 壓縮算法嘗試識別數據集中的大型重複模式，並用較小的模式替換它們。理想情況下，這會縮小數據集的大小。爲了網絡傳輸的目的，移動數據較少意味着它應該花費較少的時間來移動它。

主要由純文本或機器可執行代碼組成的文檔和文件往往壓縮得很好。例子包括文字處理文檔，HTML文件，一些.exe文件和一些數據庫文件。

在網絡傳輸之前將許多小文件合併到一個存檔中通常會導致比單獨傳輸每個文件更快的速度。即使單個文件本身不可壓縮，情況也是如此。許多歸檔實用程序可以選擇將文件打包到壓縮文件中，例如「zip」的「-0」選項。當您啓用流式文件夾時，ExpeDat會將文件夾的內容組合成單個數據流。

當壓縮不好時 許多數據類型不可壓縮，因爲重複模式已被刪除。這包括大多數圖像，視頻，歌曲，已壓縮的任何數據或任何已加密的數據。

試圖壓縮不可壓縮的數據會浪費CPU時間。當您嘗試高速移動數據時，該CPU時間可能對饋送網絡至關重要。因此，通過減少無用的壓縮處理時間，與壓縮關閉相比，實際上最終的數據移動速度要慢得多。

如果您僅將壓縮實用程序用於合併很多小文件，請檢查禁用壓縮的選項。例如，「zip」命令有一個「-0」選項，該選項將文件打包到歸檔中，而無需花費時間來壓縮它們。

在線與離線 許多傳輸機制允許您爲轉移的壓縮算法應用到數據。這很方便，因爲無需用戶執行額外的步驟就可以無縫地進行壓縮和解壓縮。但是它也是有風險的，因爲花費在壓縮上的任何CPU時間都不是用於通過網絡饋送數據的時間。如果網絡速度非常快，CPU速度很慢，或者壓縮算法無法擴展，打開內聯壓縮可能導致數據移動速度比關閉壓縮時慢。即使數據是可壓縮的，內聯壓縮也可能比不壓縮要慢！

如果你將要傳送同樣的數據集多次，就得先用Zip或焦油Gzip已壓縮。然後，您可以傳輸壓縮歸檔文件，而無需將CPU週期從網絡處理中移走。如果您打算加密數據，請確保先壓縮數據，然後再加密。

隱藏壓縮 設備在網絡中可能沒有你意識到這一點來進行壓縮。如果網絡的「速度」似乎因不同的數據類型而改變，則這變得明顯。如果在傳輸已經壓縮的數據時網絡看起來很慢，但在傳輸未壓縮的文本文件時速度很快，那麼您可以確定某些內容正在爲您做出壓縮決策。

網絡壓縮設備可以有所幫助，因爲它們將壓縮負擔從端點CPU中分離出來。但是它們也可能產生非常不一致的結果，因爲它們不適用於所有目的地和數據類型。網絡級壓縮也可能會遇到上面討論的相同的CPU折衷，導致一些文件的移動速度比沒有壓縮時的速度慢。

如果您正在測試網絡的速度，請嘗試使用已壓縮或加密的數據以確保一致的結果。

我應該打開內聯壓縮嗎？ 對於壓縮數據，圖像，音頻，視頻或加密文件：

對於其他類型的數據，可以通過兩種方式來測試哪種數據更快。

如果網絡速度非常快（每秒數百兆位秒或更快），考慮關閉在線壓縮，而是壓縮數據在移動之前。