本文,幫助瞭解響應壓縮的一些知識及用法(大部分翻譯於官網,英文水平有限,不許確之處,歡迎指正)。javascript
什麼是響應壓縮?響應壓縮簡單的說就是爲了減小網絡帶寬,而把返回的響應壓縮,使之體積縮小,從而加快響應的一種技術(我的理解)css
網絡帶寬是有限的資源。減小響應(response)的大小一般能夠增長應用的響應性(即減小響應的大小能夠加快響應的速度),這是很引人注目的(often dramatically).壓縮(壓縮compress)應用的響應能夠減小裝載的大小。html
在IIS,Apache,Nginx中使用基於服務端的響應壓縮技術。中間件的執行可能和服務端模塊不匹配。HTTP.sys 和Kestrel server目前沒有提供內置的壓縮支持。java
何時使用Response Compression Middleware:nginx
一般,任何不能自動壓縮的響應均可以從響應壓縮中獲益。典型的不能自動壓縮的響應包括:CSS, JavaScript, HTML, XML, 和JSON. 你不該該壓縮自動壓縮的文件,例如 PNG文件。若是你嘗試更進一步壓縮一個自動壓縮的響應,那麼任何小的額外的縮小和傳送時間都將會顯得黯然失色,等到它處理壓縮, 不要壓縮小於150-1000bytes文件(取決於文件的內容和壓縮的效率)。 壓縮小文件開銷能夠產生大於未壓縮文件的壓縮文件。git
當客戶端能夠處理壓縮內容時,客戶端必須經過發送請求頭上的Accept-Encoding 通知服務器它的能力。當服務器發送壓縮內容時,它必須在Content-Encoding 頭中包含壓縮的響應是怎麼編碼的內容。內容編碼的指定是經過下表中展現的中間件支持的。github
中間件容許你爲自定義的Accept-Encoding 的頭上的值增長額外的壓縮提供者,中間件對於質量值的反應是很熟練的,質量值是被客戶端發送的用來衡量優先處理壓縮協議的。web
壓縮算法是受支配於壓縮速度和壓縮效率的一種平衡交易。效率關係到壓縮以後的大小,最優壓縮壓縮出來的就是最小的。算法
涉及到請求,發送,緩存,接收壓縮內容的頭部在下表中有描述json
利用sample app 探索響應壓縮的功能。這個例子代表:
爲了在項目中包含這個中間件,增長一個到 Microsoft.AspNetCore.App metapackage, 的引用,它包含 Microsoft.AspNetCore.ResponseCompression 包
下面的代碼展現了怎樣容許Response Compression Middleware , 對於默認的MIME類型和壓縮提供者(Brotli 和 Gzip):
public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddResponseCompression(); } public void Configure(IApplicationBuilder app, IHostingEnvironment env) { app.UseResponseCompression(); } }
注意:
App.UseResponseCompression 必須在app.UseMvc以前被調用
用一個工具(例如Fiddler, Filrebug, Postman)來設置Accept-Encoding 請求頭,而且研究響應頭,大小和body
提交一個不攜帶Acccept-Encoding 頭的請求到示例應用,而且觀察到響應是未壓縮的。Content-Encoding 和 Vary 頭沒有在響應中呈現。
提交一個帶Accept-Encoding: br頭的請求到示例應用。(Brotli compress)而且觀察響應是壓縮的。Content-Encoding 和Vary 在響應中呈現了。
Brotli Compression Provider
使用BrotliCompressionProvider來壓縮響應,使用Brotli compressed data format ( brotli compress 數據格式),
若是沒有compression providers(壓縮提供者)被明確的加到 CompressionProviderCollection中:
public void ConfigureServices(IServiceCollection services) { services.AddResponseCompression(); }
Brotoli Compression Provider必須被添加,當任意compression provider 明確的被添加時。
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" }); }); }
使用BrotliCompressionProviderOptions設置壓縮級別。Brotli Compression Provider默認使用的是最快的壓縮級別( CompressionLevel.Fastest ), 這種級別可能不會產生最有效率的壓縮。若是最有效率的壓縮被須要時,能夠爲最佳的壓縮配置中間件
public void ConfigureServices(IServiceCollection services) { services.AddResponseCompression(); services.Configure<BrotliCompressionProviderOptions>(options => { options.Level = CompressionLevel.Fastest; }); }
使用GzipCompressionProvider來壓縮響應,用Gzip file format.(用Gzip 文件格式)
若是沒有compression provider被明確的加入到CompressionProviderCollection中:
public void ConfigureServices(IServiceCollection services) { services.AddResponseCompression(); }
Gzip Compression Provider 必須被添加,當任意壓縮提供者被明確的添加時:
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" }); }); }
使用GzipCompressionProviderOptions設置壓縮級別。Gzip Compression Provider默認使用的是最快的壓縮級別( CompressionLevel.Fastest ), 這種級別可能不會產生最有效率的壓縮。若是最有效率的壓縮被須要時,能夠爲最佳的壓縮配置中間件
public void ConfigureServices(IServiceCollection services) { services.AddResponseCompression(); services.Configure<GzipCompressionProviderOptions>(options => { options.Level = CompressionLevel.Fastest; }); }
經過實現ICompressionProvider接口建立自定義的壓縮。EncodingName表明ICompressionProvider生成的內容編碼(the content encoding). 中間件使用這個信息來選擇provider,在請求的Accept-Encoding 頭上的列表的基礎上。
在示例項目上,客戶端提交請求,帶有Accept-Encoding: mycustomcompression頭。中間件使用自定義的壓縮實現而且返回帶有Content-Encoding:mycustomcompression頭的響應。客戶端必須能夠按順序的解壓自定義的編碼( the custom encoding) ,對於一個自定義的壓縮實現的工做。
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" }); }); }
public class CustomCompressionProvider : ICompressionProvider { public string EncodingName => "mycustomcompression"; public bool SupportsFlush => true; public Stream CreateStream(Stream outputStream) { // Create a custom compression stream wrapper here return outputStream; } }
提交一個帶Accept-Encodign:mycustomcompression頭的請求到示例應用,而且觀察響應頭。響應中呈現出了Vary 和Content-Encoding頭。The response body 沒有被壓縮在項目中。在示例項目的CustomCompressionProvider類中沒有一個壓縮實現。示例展現了你在哪裏實現這樣一個壓縮算法。
這個中間件指定一個默認的用於壓縮的MIME types:
在Response Compression Middleware options上替換或者增長MIME types. 注意,帶有通配符的MIME types, 例如 text/* 是不支持的。 示例應用中增長了一個MIME type 爲 image/svg+xml 而且壓縮而且做用於ASP.NET Core的banner image ( banner,svg ).
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" }); }); }
在安全鏈接上的壓縮響應可使用 EnableForHttps 項(option)來控制, 它默認是被禁用的, 在動態生成的頁面上面使用壓縮可能會致使安全問題, 例如 CRIME and BREACH 攻擊。
當壓縮響應在Accept-Encoding 頭上時, 那是可能會有多個壓縮版本(compressed versions)的響應和一個不壓縮的版本。爲了指導客戶端和代理(client and proxy)緩存多個存在的版本,而且存儲,Vary 頭是被加到Accept-Encoding 值。 在ASP.NET Core 2.0或者更新的版本,當響應被壓縮時,中間件自動添加Vary 頭。
當一個請求被Nginx代理時,Accept-Encoding 頭被移除了, Accept-Encoding頭的移除阻止了中間件壓縮響應。更多的信息:NGINX: Compression and Decompression.
當你有一個激活的IIS動態壓縮模塊配置在服務器級別(at the server level), 你可能會想要在一個應用上禁止它,那麼你能夠在web.config文件中禁用它。更多的信息:Disabling IIS modules.
本文翻譯於:https://docs.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-2.2