前言

  在微软官方文档中,未明确指出文件压缩功能的使用误区。

  本文将对 asp.net core 文件响应压缩的常见使用误区做出说明。

误区1:未使用brotil 压缩

  几乎不需要任何额外的代价,brotil 压缩算法可以帮助你的网站提升约 20% 静态资源加载性能。

  同时启用 gzip / brotil 压缩

  gzip 有更好的 user-agent 兼容性,而 brotli 有更好的性能。

  所以我们通常需要在 asp.net core 网站中同时启用这两种压缩。

  如何区分 gzip 压缩和 brotli 压缩

  网站启用 brotli 压缩时,服务器请求返回头 content-encoding 中会包含 br 字样,否则是 gzip。

误区2:使用 fastest 级别的 brotli 压缩

  如果你阅读并参考了微软官方文档或者其他中文资源,比如:

  asp.net core 中的响应压缩 – ms doc

  在asp.net core中使用brotli压缩- cnblogs

  那么你可能会在代码中像下面这样使用压缩功能:

  写法1:使用默认的压缩行为(框架将隐式添加 brotli 和 gzip 功能)

public class startup
{
    public void configureservices(iservicecollection services)
    {
        services.addresponsecompression();
    }

    public void configure(iapplicationbuilder app, ihostingenvironment env)
    {
        app.useresponsecompression();
    }
}

  写法2:显式添加压缩功能

public void configureservices(iservicecollection services)
{
    services.addresponsecompression(options =>
    {
        options.providers.add<brotlicompressionprovider>();
        options.providers.add<gzipcompressionprovider>();
        options.providers.add<customcompressionprovider>();
        options.mimetypes = 
            responsecompressiondefaults.mimetypes.concat(
                new[] { "image/svg+xml" });
    });
    services.configure<brotlicompressionprovideroptions>(options => 
    {
        options.level = compressionlevel.fastest;
    });
}

  写法3:自定义 brotlicompressionprovider

public class brotlicompressionprovider : icompressionprovider
{
    public string encodingname => "br";
    public bool supportsflush => true
    public stream createstream(stream outputstream)
    {
           return new brotlistream(outputstream,compressionlevel.fastest);
    }
}

  不幸的是,以上三种写法都没有发挥出 brotil 压缩算法的优势。

  它们的共同点是均使用了 compressionlevel.fastest压缩级别。

  而在 compressionlevel.fastest 级别时,brotil 与 gzip 压缩性能几乎无异。

  参考:introducing support for brotli compression

图 2-1 fastest 模式下,三种算法的压缩率等同

误区3:使用 optimal 级别的 brotli 压缩

  compressionlevel 只有三个枚举值:fastest / nocompression / optimal。

  既然 fastest 级别没有用,那我们只能换成 optimal 了。

图 3-1 压缩级别枚举

  非常不幸,brotil 的 optimal 压缩级别存在严重的性能问题,在实际网站应用中几乎没有适用的场景。

图 3-2 optimal 压缩耗时对比

最佳实践:使用 4 或 5 级别的 brotli 压缩

  在introducing support for brotli compression这篇文章中,作者对不同级别 brotil 的压缩耗时做了评测,也就是下面这幅图。

图 4-1 不同压缩级别下 brotli 的压缩耗时

  观察这副图,brotil 的压缩质量其实有 1~11 个级别。

  那我们如何自定义 brotli 的压缩级别呢,答案是直接将级别对应的整数转成 compressionlevel 枚举。

  参考:setting a specific brotli compression level when using response compression in asp.net core

图 4-2 指定 brotli 的压缩级别

  尽管这种写法看起来十分古怪,但通过考察 .net 源码,可以确凿这种写法是可行的。

  参考:system.io.compression.brotliutils.cs

图 4-3 compressionlevel 枚举强制转换整数

  现在我们可以自定义压缩级别了,但注意上方源码,只能指定 3 以上的级别,3 包括 3 以下的值有其他对应的转换逻辑。

  回到本节第一副图 4-1,通过实测,发现在 4 / 5 级别下,brotli 确实可以获得最佳的压缩率和较低的压缩损耗。

总结

  在 asp.net core 中,我们应该同时启用 gzip 和 brotil 压缩功能,其中 brotil 的压缩级别应该自定义到 4 或 5。

public void configureservices(iservicecollection services)
        {
            services.addresponsecompression(options =>
            {
                options.providers.add<brotlicompressionprovider>();
                options.providers.add<gzipcompressionprovider>();
                options.mimetypes =
                    responsecompressiondefaults.mimetypes.concat(
                        new[] { "image/svg+xml" });
            });

            services.configure<brotlicompressionprovideroptions>(options =>
            {
                options.level = (compressionlevel)4; // 4 or 5 is ok
            });
        }
        public void configure(iapplicationbuilder app, iwebhostenvironment env)
        {
            app.useresponsecompression();
        }

以上就是asp.net core文件压缩最佳实践的详细内容,更多关于asp.net core文件压缩的资料请关注www.887551.com其它相关文章!