asp.net core文件壓縮常見使用誤區(qū)(最佳實(shí)踐)

前言

　　在微軟官方文檔中，未明確指出文件壓縮功能的使用誤區(qū)。

　　本文將對(duì) asp.net core 文件響應(yīng)壓縮的常見使用誤區(qū)做出說明。

誤區(qū)1：未使用brotil 壓縮

　　幾乎不需要任何額外的代價(jià)，brotil 壓縮算法可以幫助你的網(wǎng)站提升約 20% 靜態(tài)資源加載性能。

　　同時(shí)啟用 gzip / brotil 壓縮

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

　　所以我們通常需要在 asp.net core 網(wǎng)站中同時(shí)啟用這兩種壓縮。

　　如何區(qū)分 gzip 壓縮和 brotli 壓縮

　　網(wǎng)站啟用 brotli 壓縮時(shí)，服務(wù)器請(qǐng)求返回頭 content-encoding 中會(huì)包含 br 字樣，否則是 gzip。

誤區(qū)2：使用 fastest 級(jí)別的 brotli 壓縮

　　如果你閱讀并參考了微軟官方文檔或者其他中文資源，比如：

　　asp.net core 中的響應(yīng)壓縮 - ms doc

　　在asp.net core中使用brotli壓縮- cnblogs

　　那么你可能會(huì)在代碼中像下面這樣使用壓縮功能：

　　寫法1：使用默認(rèn)的壓縮行為（框架將隱式添加 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);
  }
}

　　不幸的是，以上三種寫法都沒有發(fā)揮出 brotil 壓縮算法的優(yōu)勢(shì)。

　　它們的共同點(diǎn)是均使用了 compressionlevel.fastest壓縮級(jí)別。

　　而在 compressionlevel.fastest 級(jí)別時(shí)，brotil 與 gzip 壓縮性能幾乎無異。

　　參考：introducing support for brotli compression

圖 2-1 fastest 模式下，三種算法的壓縮率等同

誤區(qū)3：使用 optimal 級(jí)別的 brotli 壓縮

　　compressionlevel 只有三個(gè)枚舉值：fastest / nocompression / optimal。

　　既然 fastest 級(jí)別沒有用，那我們只能換成 optimal 了。

圖 3-1 壓縮級(jí)別枚舉

　　非常不幸，brotil 的 optimal 壓縮級(jí)別存在嚴(yán)重的性能問題，在實(shí)際網(wǎng)站應(yīng)用中幾乎沒有適用的場(chǎng)景。

圖 3-2 optimal 壓縮耗時(shí)對(duì)比

最佳實(shí)踐：使用 4 或 5 級(jí)別的 brotli 壓縮

　　在introducing support for brotli compression這篇文章中，作者對(duì)不同級(jí)別 brotil 的壓縮耗時(shí)做了評(píng)測(cè)，也就是下面這幅圖。

圖 4-1 不同壓縮級(jí)別下 brotli 的壓縮耗時(shí)

　　觀察這副圖，brotil 的壓縮質(zhì)量其實(shí)有 1~11 個(gè)級(jí)別。

　　那我們?nèi)绾巫远x brotli 的壓縮級(jí)別呢，答案是直接將級(jí)別對(duì)應(yīng)的整數(shù)轉(zhuǎn)成 compressionlevel 枚舉。

　　參考：setting a specific brotli compression level when using response compression in asp.net core

圖 4-2 指定 brotli 的壓縮級(jí)別

　　盡管這種寫法看起來十分古怪，但通過考察 .net 源碼，可以確鑿這種寫法是可行的。

　　參考：system.io.compression.brotliutils.cs

圖 4-3 compressionlevel 枚舉強(qiáng)制轉(zhuǎn)換整數(shù)

　　現(xiàn)在我們可以自定義壓縮級(jí)別了，但注意上方源碼，只能指定 3 以上的級(jí)別，3 包括 3 以下的值有其他對(duì)應(yīng)的轉(zhuǎn)換邏輯。

　　回到本節(jié)第一副圖 4-1，通過實(shí)測(cè)，發(fā)現(xiàn)在 4 / 5 級(jí)別下，brotli 確實(shí)可以獲得最佳的壓縮率和較低的壓縮損耗。

總結(jié)

　　在 asp.net core 中，我們應(yīng)該同時(shí)啟用 gzip 和 brotil 壓縮功能，其中 brotil 的壓縮級(jí)別應(yīng)該自定義到 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文件壓縮最佳實(shí)踐的詳細(xì)內(nèi)容，更多關(guān)于asp.net core文件壓縮的資料請(qǐng)關(guān)注碩編程其它相關(guān)文章！