套接字压缩数据的优点

我使用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

套接字压缩数据的优点

回答

相关问题