套接字中压缩数据的优点

Advantages of compressed data in socket

本文关键字：数据 压缩 套接字      更新时间：2023-10-16

我使用zlib来压缩我的文件，压缩后我没有看到它的大小有显着变化，我试图用套接字提高传输速度，所以我试图在通过套接字发送之前压缩文件。

我使用下面的代码来压缩文件:

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);
}

在套接字上发送之前压缩文件有什么好处?

在套接字上发送之前压缩文件有什么好处?

显然，节省了网络带宽。然而，这将是一种权衡。下面我们就来谈谈和的优点

在网络压缩中很难选择一个最佳点，特别是当要压缩的内容是未知的。

你需要在"压缩速度"、"压缩率"answers"解压速度"之间取得平衡:

  1. 如果第一个是低的，你有未使用的网络容量，而你正在压缩有效载荷

  2. 如果压缩比低，那么你可能以网络"饱和"结束，如果有成堆的客户端通信和/或你的可用带宽很窄

  3. 如果解压缩的速度很低，你可能会淹没服务器CPU在做大部分的解压缩而不是处理负载。

在任何情况下，在网络中使用压缩都不是免费的:它是两端网络带宽和cpu周期之间的权衡。如果你在压缩的基础上添加SSL/TSL，你可能会付出高昂的CPU成本，尤其是在服务器/主端(扩展你的集群，安排额外的冷却，做负载平衡，雇佣高级系统，等等)。用一根更大的管子来装这些输入的比特不是更便宜吗?

对于最常见的场景，当压缩是合理的，平衡被转移到客户端较重的一方-假设客户端将有多余的处理能力，因此选择更好的压缩算法将节省带宽和服务器CPU。

然而，当发送者处于"实时压力"下时，情况就会发生变化(想想现场直播音乐会，或者在日内瓦的大型强子对撞机中收集希格斯玻色子碰撞的数据):如果使用压缩(大多数时候不会，除了标准/编解码器中内置的压缩算法)，压缩比将会很低，计算成本也很低。

相关文章：