响应压缩中间件的优缺点

Question

在启动类中，我将以下行添加到我的 asp.net 核心应用程序中

services.AddResponseCompression();

所以 configureServices 方法如下所示

  public void ConfigureServices(IServiceCollection services)
        {
            services.AddDbContext<MyDBContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

            services.AddCors(options =>
            {
                options.AddPolicy("AllowAll",
                    builder =>
                    {
                        builder
                        .AllowAnyOrigin()
                        .AllowAnyMethod()
                        .AllowAnyHeader();
                    });
            });
            services.AddMvc();

            services.AddResponseCompression();

        }

我还添加了以下行来配置方法

 app.UseResponseCompression();

这是配置方法

 public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
          if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseCors("AllowAll");
            app.UseResponseCompression();
            app.UseMvc();
        }

现在，当我运行该项目时，它运行得更快，响应的大小已经减小和压缩（我通过 chrome 控制台网络选项卡检查了它），响应压缩中间件的目的是压缩响应

我的问题是：使用这个中间件有什么缺点吗，或者有什么情况我不应该使用响应压缩？

Answer 1

好处

• 压缩内容有助于减少客户端下载所需的时间。
• 它可以节省您的带宽，从而降低成本！

缺点

• 压缩内容会消耗服务器的 CPU 周期！
• 解压也会消耗您的客户端 CPU 周期（@Evk）

Answer 2

好的，经过一番调查，自 dot.net core 2 以来，接缝发生了一些变化。首先UseResponseCompression应该用作最后一个选项，或者换句话说

在以下情况下使用响应压缩中间件：

无法使用以下基于服务器的压缩技术：

• IIS动态压缩模块
• Apache mod_deflate 模块
• NGINX 压缩和解压

直接托管在：

• HTTP.sys 服务器（以前称为 WebListener）
• 红隼

来源

仅建议将在 Kestrel 上托管用于高性能 api 端点，对于面向公众的端点，您应该在 IIS 下运行，因此使用本机压缩而不是中间件。

当中间件的开箱即用 Gzip 压缩时，这种使用表现非常糟糕，并且往往会减慢总往返时间，而不是改进它，尤其是对于小负载。从我所看到的，他们改变了 .net 标准 2.0 的实现，我不确定它会如何工作。

但是，当您谈论压缩时，它确实取决于用例，因此您应该使用您期望的负载和设置进行性能测试，看看是否有任何改进。

有关 gzip 主题的一般信息，您应该查看其他问题