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 module
NGINX压缩和解压缩

直接托管：

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

Source

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

当开箱即用Gzip对中间件进行压缩时，这种用法非常糟糕，并且往往会减慢总往返时间，而不是特别针对小型有效负载进行改进。 From what I can see他们改变了.net标准2.0的实现，我不确定它的效果如何。

但是当你谈论压缩时，它实际上取决于用例，所以你应该使用你期望的负载进行性能测试，并设置你的设置，看看你是否有任何改进。

有关gzip主题的一般信息，您应该查看另一个question

响应压缩中间件的优缺点

2 个答案:

当您执行以下操作时使用响应压缩中间件：