asp.net core gzip 压缩取决于响应大小

Question

我们使用 gzip 压缩，例如：

services.Configure<GzipCompressionProviderOptions>(options => options.Level = CompressionLevel.Fastest);
  services.AddResponseCompression(options =>
  {
    options.Providers.Add<GzipCompressionProvider>();
  });

由于我们希望避免对小响应进行压缩，因此问题是我们是否可以以某种方式配置 gzip 压缩，使其不用于小于 XY 的响应大小？

Answer 1

ASP.NET Core 2.1 中的压缩中间件似乎没有提供根据内容大小压缩数据的能力，因此对您问题的简短回答是“否”。

但是，我知道这种设置的主要原因是使整个请求端到端更快，这就是 CompressionLevel.Fastest应该为您做的事情。

ASP.NET Core 压缩中间件注意事项。

GZipCompressionProvider最终调用Deflater构造函数和CreateZLibStreamForDeflate方法，其中 .NET 中定义的 CompressionLevel 枚举被映射到用于执行实际压缩的底层 zlib 库中定义的压缩级别。来自zlib 手册：

压缩级别必须为 Z_DEFAULT_COMPRESSION，或介于 0 和 9 之间：1 提供最佳速度，9 提供最佳压缩，0 根本不提供压缩（输入数据一次简单地复制一个块）。Z_DEFAULT_COMPRESSION 请求速度和压缩之间的默认折衷（当前相当于级别 6）。

根据 ASP.NET Core 压缩中间件映射压缩级别的方式（如Deflater和ZLibNative中定义） ，我们可以推断出以下内容：

• CompressionLevel.Fastest：zlib 压缩级别将为 1，即速度更快，压缩更少。
• CompressionLevel.Optimal：zlib 压缩级别将为 6，即速度和压缩之间的折衷。

请注意，没有映射到更高 zlib 压缩级别的选项，例如 9，它是最高压缩率，也是最昂贵的，这可能会使 ASP.NET Core Web 应用程序花费更多时间进行压缩，而不是将整个内容发送回客户端。

CompressionLevel的使用和总体考虑。

在 Web 服务实现中，压缩只是一种使事情变得更快的工具，因此压缩应该尽可能轻，以避免压缩算法花费的时间超过网络传递未压缩的有效负载所需的时间。

在我看来，CompressionLevel.Fastest效果最好，因为在大多数情况下它可以保证客户端收到更快的响应，因此它通常是需要处理常见文件大小的网站或 Web api 的最佳选择。

另一方面，如果您的 Web 服务需要交付大量内容，CompressionLevel.Optimal会带来更多价值，因为它会对通过网络发送的数据量产生更大影响。

最重要的是，客户端始终可以通过适当设置 Accept-Encoding 请求 HTTP 标头来指定是否应压缩响应，如ASP.NET Core 压缩中间件文档中所述。