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中的压缩中间件似乎没有提供基于内容大小压缩数据的能力，因此对您的问题的简短回答是＆＃34;否＆＃34;。

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

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

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

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

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

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

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

CompressionLevel使用情况和总体考虑因素。

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

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

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

除此之外，客户端始终可以通过适当地设置Accept-Encoding请求HTTP标头来指定是否应该压缩响应，如ASP.NET Core Compression Middleware文档中所述。

asp.net核心gzip压缩依赖于响应大小

1 个答案:

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

CompressionLevel使用情况和总体考虑因素。