C# 响应压缩中间件的优缺点

在启动课程中，我在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控制台的网络选项卡进行了检查）， 响应压缩中间件的目的是压缩响应

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

优点

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

缺点

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

---

经过一些调查后，确定自dot.net core 2以来有一些变化。 首先，

userresponsecompression

应作为最后一个选项使用，或者换句话说

在以下情况下使用响应压缩中间件： 无法使用以下基于服务器的压缩技术：

• IIS动态压缩模块
• apachemod_deflate模块
• NGINX压缩与解压缩

直接在以下网站上托管：

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

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

当中间件的Gzip压缩开箱即用时，它的性能非常差，并且倾向于减慢总往返时间，而不是改善它，特别是对于小的有效负载。他们更改了.net标准2.0的实现，我不确定它是否能正常工作

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

---

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

也就是说，解压缩会消耗客户端的CPU周期。这个压缩中间件不是与完整的流一起工作，所以您的整个响应也会存储在内存中，而不是一部分一部分地发送吗？另一个优点是它既节省了客户端带宽，又节省了客户端的时间服务器的。作为一个缺点，它需要客户端兼容性，否则该网站根本无法工作。非常感谢much@Alejandro压缩的工作方式是，根据accept encoding请求头，只有当客户端浏览器支持压缩时，才会自动启用压缩。非常感谢