响应压缩中间件的优缺点[关闭]

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

好的，经过一些调查后，自从dot.net core 2开始，接缝会有一些变化。首先，UseResponseCompression应该用作最后一个选项，换句话说

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

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

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

直接托管：

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

Source

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

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

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

有关gzip主题的一般信息，你应该看看这个其他的question

Answer 2

好处

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

缺点

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