套接字壓縮數據的優點

我使用zlib壓縮我的文件，我沒有看到它的大小在壓縮後的重大變化，我試圖有一個與套接字傳輸速度的改進，所以我' m在通過套接字發送文件之前嘗試壓縮文件。套接字壓縮數據的優點

我使用下面的代碼來壓縮文件：

int compress_file(char *infilename, char *outfilename) { 
     FILE *infile = fopen(infilename, "rb"); 
     gzFile outfile = gzopen(outfilename, "wb"); 
     if (!infile || !outfile) return -1; 

     char inbuffer[128]; 
     int num_read = 0; 
     unsigned long total_read = 0, total_wrote = 0; 
     while ((num_read = fread(inbuffer, 1, sizeof(inbuffer), infile)) > 0) { 
      total_read += num_read; 
      gzwrite(outfile, inbuffer, num_read); 
     } 
     fclose(infile); 
     gzclose(outfile); 
}

什麼是發送插座上之前壓縮文件的優勢是什麼？

來源

2016-09-27 Melissia_M

你爲什麼之前壓縮文件** **發送過來的插座？您應該在**發送時壓縮它**。然後，你不必浪費預壓縮的任何時間的文件，並且沒有浪費任何臨時磁盤空間。 –

你壓縮什麼樣的文件？請記住，如果該文件已經很好壓縮（例如.zip文件或。MP3文件），然後進一步壓縮它可能不會得到額外的大小減少（並可能實際上甚至使文件大小更大！） –

壓縮每個文件塊，而發送？我可以用zlib壓縮這些字節？ –

什麼是發送插座上之前壓縮文件的優勢是什麼？

顯然，節省網絡帶寬。但是，這將是一個折衷。因此，下面只會觸及區別優點

很難在網絡壓縮中選擇一個最佳位置，特別是當要壓縮的內容未知時。

你需要VS「壓縮率」 VS「解壓速度」壓縮的速度「之間的平衡：

，如果第一個是低，你有未使用網絡容量的同時，正在壓縮載荷
如果壓縮比低，那麼你可以與網絡終端「飽和度」，如果有客戶溝通堆和/或可用的帶寬較窄
如果解壓縮的速度低，你可能在做主要是減壓，而不是處理的有效載荷沼澤服務器CPU。

無論如何，在網絡中使用壓縮並不是免費的：它是網絡帶寬和兩端CPU週期之間的折衷。如果您在壓縮之上添加SSL/TSL，您可能會以高昂的CPU成本完成，特別是在服務器/主端端（擴展您的羣集，安排額外的冷卻，進行負載平衡，僱傭古茹系統管理員等）。對於這些傳入的比特，採用更大的管道是否更便宜）？

對於最常見的場景，當壓縮合理時，平衡會隨着客戶端較重的一方轉移 - 假設客戶端將具有過剩處理能力，因此選擇更好的壓縮算法將節省帶寬和服務器CPU 。

然而，當發送者處於'實時壓力'下（想想在日內瓦的LHC上實時流音樂會，或收集來自希格斯玻色子和碰撞希格斯玻色子的數據）：如果使用壓縮（大部分時間不會，除了標準/編解碼器中內置的壓縮算法之外），壓縮比將很低，並且計算便宜。

來源

2016-09-27 02:56:33

套接字壓縮數據的優點

回答

相關問題