介紹

????響應(yīng)壓縮技術(shù)是目前Web開發(fā)領(lǐng)域中比較常用的技術(shù)，在帶寬資源受限的情況下，使用壓縮技術(shù)是提升帶寬負(fù)載的首選方案。我們熟悉的Web服務(wù)器，比如IIS、Tomcat、Nginx、Apache等都可以使用壓縮技術(shù)，常用的壓縮類型包括Brotli、Gzip、Deflate，它們對CSS、JavaScript、HTML、XML 和 JSON等類型的效果還是比較明顯的，但是也存在一定的限制對于圖片效果可能沒那么好，因?yàn)閳D片本身就是壓縮格式。其次，對于小于大約150-1000 字節(jié)的文件（具體取決于文件的內(nèi)容和壓縮的效率，壓縮小文件的開銷可能會(huì)產(chǎn)生比未壓縮文件更大的壓縮文件。在ASP.NET Core中我們可以使用非常簡單的方式來使用響應(yīng)壓縮。

使用方式

????在ASP.NET Core中使用響應(yīng)壓縮的方式比較簡單。首先，在ConfigureServices中添加services.AddResponseCompression注入響應(yīng)壓縮相關(guān)的設(shè)置，比如使用的壓縮類型、壓縮級別、壓縮目標(biāo)類型等。其次，在Configure添加app.UseResponseCompression攔截請求判斷是否需要壓縮,大致使用方式如下

public class Startup {public void ConfigureServices(IServiceCollection services){services.AddResponseCompression();}public void Configure(IApplicationBuilder app, IHostingEnvironment env){app.UseResponseCompression();} }

如果需要自定義一些配置的話還可以手動(dòng)設(shè)置壓縮相關(guān)

public void ConfigureServices(IServiceCollection services) {services.AddResponseCompression(options =>{//可以添加多種壓縮類型，程序會(huì)根據(jù)級別自動(dòng)獲取最優(yōu)方式options.Providers.Add<BrotliCompressionProvider>();options.Providers.Add<GzipCompressionProvider>();//添加自定義壓縮策略options.Providers.Add<MyCompressionProvider>();//針對指定的MimeType來使用壓縮策略options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(new[] { "application/json" });});//針對不同的壓縮類型，設(shè)置對應(yīng)的壓縮級別services.Configure<GzipCompressionProviderOptions>(options => {//使用最快的方式進(jìn)行壓縮，單不一定是壓縮效果最好的方式options.Level = CompressionLevel.Fastest;//不進(jìn)行壓縮操作//options.Level = CompressionLevel.NoCompression;//即使需要耗費(fèi)很長的時(shí)間，也要使用壓縮效果最好的方式//options.Level = CompressionLevel.Optimal;}); }

? 關(guān)于響應(yīng)壓縮大致的工作方式就是，當(dāng)發(fā)起Http請求的時(shí)候在Request Header中添加Accept-Encoding:gzip或者其他你想要的壓縮類型，可以傳遞多個(gè)類型。服務(wù)端接收到請求獲取Accept-Encoding判斷是否支持該種類型的壓縮方式，如果支持則壓縮輸出內(nèi)容相關(guān)并且設(shè)置Content-Encoding為當(dāng)前使用的壓縮方式一起返回。客戶端得到響應(yīng)之后獲取Content-Encoding判斷服務(wù)端是否采用了壓縮技術(shù)，并根據(jù)對應(yīng)的值判斷使用了哪種壓縮類型，然后使用對應(yīng)的解壓算法得到原始數(shù)據(jù)。

源碼探究

通過上面的介紹，相信大家對ResponseCompression有了一定的了解，接下來我們通過查看源碼的方式了解一下它大致的工作原理。

AddResponseCompression

首先我們來查看注入相關(guān)的代碼，具體代碼承載在ResponseCompressionServicesExtensions擴(kuò)展類中[點(diǎn)擊查看源碼????]

public static class ResponseCompressionServicesExtensions {public static IServiceCollection AddResponseCompression(this IServiceCollection services){services.TryAddSingleton<IResponseCompressionProvider, ResponseCompressionProvider>();return services;}public static IServiceCollection AddResponseCompression(this IServiceCollection services, Action<ResponseCompressionOptions> configureOptions){services.Configure(configureOptions);services.TryAddSingleton<IResponseCompressionProvider, ResponseCompressionProvider>();return services;} }

主要就是注入ResponseCompressionProvider和ResponseCompressionOptions,首先我們來看關(guān)于ResponseCompressionOptions[點(diǎn)擊查看源碼????]

public class ResponseCompressionOptions {// 設(shè)置需要壓縮的類型public IEnumerable<string> MimeTypes { get; set; }// 設(shè)置不需要壓縮的類型public IEnumerable<string> ExcludedMimeTypes { get; set; }// 是否開啟https支持public bool EnableForHttps { get; set; } = false;// 壓縮類型集合public CompressionProviderCollection Providers { get; } = new CompressionProviderCollection(); }

關(guān)于這個(gè)類就不做過多介紹了，比較簡單。ResponseCompressionProvider是我們提供響應(yīng)壓縮算法的核心類，具體如何自動(dòng)選用壓縮算法都是由它提供的。這個(gè)類中的代碼比較多，我們就不逐個(gè)方法講解了，具體源碼可自行查閱[點(diǎn)擊查看源碼????]，首先我們先看ResponseCompressionProvider的構(gòu)造函數(shù)

public ResponseCompressionProvider(IServiceProvider services, IOptions<ResponseCompressionOptions> options) {var responseCompressionOptions = options.Value;_providers = responseCompressionOptions.Providers.ToArray();//如果沒有設(shè)置壓縮類型默認(rèn)采用Br和Gzip壓縮算法if (_providers.Length == 0){_providers = new ICompressionProvider[]{new CompressionProviderFactory(typeof(BrotliCompressionProvider)),new CompressionProviderFactory(typeof(GzipCompressionProvider)),};}//根據(jù)CompressionProviderFactory創(chuàng)建對應(yīng)的壓縮算法Provider比如GzipCompressionProviderfor (var i = 0; i < _providers.Length; i++){var factory = _providers[i] as CompressionProviderFactory;if (factory != null){_providers[i] = factory.CreateInstance(services);}}//設(shè)置默認(rèn)的壓縮目標(biāo)類型默認(rèn)為text/plain、text/css、text/html、application/javascript、application/xml//text/xml、application/json、text/json、application/wasvar mimeTypes = responseCompressionOptions.MimeTypes;if (mimeTypes == null || !mimeTypes.Any()){mimeTypes = ResponseCompressionDefaults.MimeTypes;}//將默認(rèn)MimeType放入HashSet_mimeTypes = new HashSet<string>(mimeTypes, StringComparer.OrdinalIgnoreCase);_excludedMimeTypes = new HashSet<string>(responseCompressionOptions.ExcludedMimeTypes ?? Enumerable.Empty<string>(),StringComparer.OrdinalIgnoreCase);_enableForHttps = responseCompressionOptions.EnableForHttps; }

其中BrotliCompressionProvider、GzipCompressionProvider是具體提供壓縮方法的地方，咱們就看比較常用的Gzip的Provider的大致實(shí)現(xiàn)[點(diǎn)擊查看源碼????]

public class GzipCompressionProvider : ICompressionProvider {public GzipCompressionProvider(IOptions<GzipCompressionProviderOptions> options){Options = options.Value;}private GzipCompressionProviderOptions Options { get; }// 對應(yīng)的Encoding名稱public string EncodingName { get; } = "gzip";public bool SupportsFlush => true;// 核心代碼就是這句 將原始的輸出流轉(zhuǎn)換為壓縮的GZipStream// 我們設(shè)置的Level壓縮級別將決定壓縮的性能和質(zhì)量public Stream CreateStream(Stream outputStream)=> new GZipStream(outputStream, Options.Level, leaveOpen: true); }

關(guān)于ResponseCompressionProvider其他相關(guān)的方法咱們在講解UseResponseCompression中間件的時(shí)候在具體看用到的方法，因?yàn)檫@個(gè)類是響應(yīng)壓縮的核心類，現(xiàn)在提前說了，到中間件使用的地方可能會(huì)忘記了。接下來我們就看UseResponseCompression的大致實(shí)現(xiàn)。

UseResponseCompression

UseResponseCompression具體也就一個(gè)無參的擴(kuò)展方法，也比較簡單，因?yàn)榕渲煤凸ぷ鞫加勺⑷氲牡胤酵瓿闪?#xff0c;所以我們直接查看中間件里的實(shí)現(xiàn)，找到中間件位置ResponseCompressionMiddleware[點(diǎn)擊查看源碼????]

public class ResponseCompressionMiddleware {private readonly RequestDelegate _next;private readonly IResponseCompressionProvider _provider;public ResponseCompressionMiddleware(RequestDelegate next, IResponseCompressionProvider provider){_next = next;_provider = provider;}public async Task Invoke(HttpContext context){//判斷是否包含Accept-Encoding頭信息，不包含直接大喊一聲"抬走下一個(gè)"if (!_provider.CheckRequestAcceptsCompression(context)){await _next(context);return;}//獲取原始輸出Bodyvar originalBodyFeature = context.Features.Get<IHttpResponseBodyFeature>();var originalCompressionFeature = context.Features.Get<IHttpsCompressionFeature>();//初始化響應(yīng)壓縮Bodyvar compressionBody = new ResponseCompressionBody(context, _provider, originalBodyFeature);//設(shè)置成壓縮Bodycontext.Features.Set<IHttpResponseBodyFeature>(compressionBody);context.Features.Set<IHttpsCompressionFeature>(compressionBody);try{await _next(context);await compressionBody.FinishCompressionAsync();}finally{//恢復(fù)原始Bodycontext.Features.Set(originalBodyFeature);context.Features.Set(originalCompressionFeature);}} }

這個(gè)中間件非常的簡單，就是初始化了ResponseCompressionBody。看到這里你也許會(huì)好奇，并沒有觸發(fā)調(diào)用壓縮相關(guān)的任何代碼，ResponseCompressionBody也只是調(diào)用了FinishCompressionAsync都是和釋放相關(guān)的，不要著急我們來看ResponseCompressionBody類的結(jié)構(gòu)

internal class ResponseCompressionBody : Stream, IHttpResponseBodyFeature, IHttpsCompressionFeature { }

?這個(gè)類實(shí)現(xiàn)了IHttpResponseBodyFeature，我們使用的Response.Body其實(shí)就是獲取的HttpResponseBodyFeature.Stream屬性。我們使用的Response.WriteAsync相關(guān)的方法，其實(shí)內(nèi)部都是在調(diào)用PipeWriter進(jìn)行寫操作，而PipeWriter就是來自HttpResponseBodyFeature.Writer屬性。可以大致概括為，輸出相關(guān)的操作其核心都是在操作IHttpResponseBodyFeature。有興趣的可以自行查閱HttpResponse相關(guān)的源碼可以了解相關(guān)信息。所以我們的ResponseCompressionBody其實(shí)是重寫了輸出操作相關(guān)方法。也就是說，只要你調(diào)用了Response相關(guān)的Write或Body相關(guān)的，其實(shí)本質(zhì)都是在操作IHttpResponseBodyFeature，由于我們開啟了響應(yīng)輸出相關(guān)的中間件，所以會(huì)調(diào)用IHttpResponseBodyFeature的實(shí)現(xiàn)類ResponseCompressionBody相關(guān)的方法完成輸出。和我們常規(guī)理解的還是有偏差的，一般情況下我們認(rèn)為，其實(shí)只要針對輸出的Stream做操作就可以了，但是響應(yīng)壓縮中間件竟然重寫了輸出相關(guān)的操作。
????了解到這個(gè)之后，相信大家就沒有太多疑問了。由于ResponseCompressionBody重寫了輸出相關(guān)的操作，代碼相對也比較多，就不逐一粘貼出來了，我們只查看設(shè)計(jì)到響應(yīng)壓縮核心相關(guān)的代碼，關(guān)于ResponseCompressionBody源碼相關(guān)的細(xì)節(jié)有興趣的可以自行查閱[點(diǎn)擊查看源碼????]，輸出的本質(zhì)其實(shí)都是在調(diào)用Write方法，我們就來查看一下Write方法相關(guān)的實(shí)現(xiàn)

public override void Write(byte[] buffer, int offset, int count) {//這是核心方法有關(guān)于壓縮相關(guān)的輸出都在這OnWrite();//_compressionStream初始化在OnWrite方法里if (_compressionStream != null){_compressionStream.Write(buffer, offset, count);if (_autoFlush){_compressionStream.Flush();}}else{_innerStream.Write(buffer, offset, count);} }

通過上面的代碼我們看到OnWrite方法是核心操作，我們直接查看OnWrite方法實(shí)現(xiàn)

private void OnWrite() {if (!_compressionChecked){_compressionChecked = true;//判斷是否滿足執(zhí)行壓縮相關(guān)的邏輯if (_provider.ShouldCompressResponse(_context)){//匹配Vary頭信息對應(yīng)的值var varyValues = _context.Response.Headers.GetCommaSeparatedValues(HeaderNames.Vary);var varyByAcceptEncoding = false;//判斷Vary的值是否為Accept-Encodingfor (var i = 0; i < varyValues.Length; i++){if (string.Equals(varyValues[i], HeaderNames.AcceptEncoding, StringComparison.OrdinalIgnoreCase)){varyByAcceptEncoding = true;break;}}if (!varyByAcceptEncoding){_context.Response.Headers.Append(HeaderNames.Vary, HeaderNames.AcceptEncoding);}//獲取最佳的ICompressionProvider即最佳的壓縮方式var compressionProvider = ResolveCompressionProvider();if (compressionProvider != null){//設(shè)置選定的壓縮算法，放入Content-Encoding頭的值里//客戶端可以通過Content-Encoding頭信息判斷服務(wù)端采用的哪種壓縮算法_context.Response.Headers.Append(HeaderNames.ContentEncoding, compressionProvider.EncodingName);//進(jìn)行壓縮時(shí)，將 Content-MD5 刪除該標(biāo)頭，因?yàn)檎膬?nèi)容已更改且哈希不再有效。_context.Response.Headers.Remove(HeaderNames.ContentMD5); //進(jìn)行壓縮時(shí)，將 Content-Length 刪除該標(biāo)頭，因?yàn)樵趯憫?yīng)進(jìn)行壓縮時(shí)，正文內(nèi)容會(huì)發(fā)生更改。_context.Response.Headers.Remove(HeaderNames.ContentLength);//返回壓縮相關(guān)輸出流_compressionStream = compressionProvider.CreateStream(_innerStream);}}} }private ICompressionProvider ResolveCompressionProvider() {if (!_providerCreated){_providerCreated = true;//調(diào)用ResponseCompressionProvider的方法返回最合適的壓縮算法_compressionProvider = _provider.GetCompressionProvider(_context);}return _compressionProvider; }

從上面的邏輯我們可以看到，在執(zhí)行壓縮相關(guān)邏輯之前需要判斷是否滿足執(zhí)行壓縮相關(guān)的方法ShouldCompressResponse，這個(gè)方法是ResponseCompressionProvider里的方法，這里就不再粘貼代碼了，本來就是判斷邏輯我直接整理出來大致就是一下幾種情況

• 如果請求是Https的情況下，是否設(shè)置了允許Https情況下壓縮的設(shè)置，即ResponseCompressionOptions的EnableForHttps屬性設(shè)置

• Response.Head里不能包含Content-Range頭信息

• Response.Head里之前不能包含Content-Encoding頭信息

• Response.Head里之前必須要包含Content-Type頭信息

• 返回的MimeType里不能包含配置的不需要壓縮的類型，即ResponseCompressionOptions的ExcludedMimeTypes

• 返回的MimeType里需要包含配置的需要壓縮的類型，即ResponseCompressionOptions的MimeTypes

• 如果不滿足上面的兩種情況，返回的MimeType里包含*/*也可以執(zhí)行響應(yīng)壓縮

  接下來我們查看ResponseCompressionProvider的GetCompressionProvider方法看它是如何確定返回哪一種壓縮類型的

public virtual ICompressionProvider GetCompressionProvider(HttpContext context) {var accept = context.Request.Headers[HeaderNames.AcceptEncoding];//判斷請求頭是否包含Accept-Encoding信心if (StringValues.IsNullOrEmpty(accept)){Debug.Assert(false, "Duplicate check failed.");return null;}//獲取Accept-Encoding里的值，判斷是否包含gzip、br、identity等，并返回匹配信息if (!StringWithQualityHeaderValue.TryParseList(accept, out var encodings) || !encodings.Any()){return null;}//根據(jù)請求信息和設(shè)置信息計(jì)算匹配優(yōu)先級var candidates = new HashSet<ProviderCandidate>();foreach (var encoding in encodings){var encodingName = encoding.Value;//Quality涉及到一個(gè)非常復(fù)雜的算法，有興趣的可以自行查閱var quality = encoding.Quality.GetValueOrDefault(1);//quality需大于0if (quality < double.Epsilon){continue;}//匹配請求頭里encodingName和設(shè)置的providers壓縮算法里EncodingName一致的算法//從這里可以看出匹配的優(yōu)先級和注冊providers里的順序也有關(guān)系for (int i = 0; i < _providers.Length; i++){var provider = _providers[i];if (StringSegment.Equals(provider.EncodingName, encodingName, StringComparison.OrdinalIgnoreCase)){candidates.Add(new ProviderCandidate(provider.EncodingName, quality, i, provider));}}//如果請求頭里EncodingName是*的情況則在所有注冊的providers里進(jìn)行匹配if (StringSegment.Equals("*", encodingName, StringComparison.Ordinal)){for (int i = 0; i < _providers.Length; i++){var provider = _providers[i];candidates.Add(new ProviderCandidate(provider.EncodingName, quality, i, provider));}break;}//如果請求頭里EncodingName是identity的情況，則不對響應(yīng)進(jìn)行編碼if (StringSegment.Equals("identity", encodingName, StringComparison.OrdinalIgnoreCase)){candidates.Add(new ProviderCandidate(encodingName.Value, quality, priority: int.MaxValue, provider: null));}}ICompressionProvider selectedProvider = null;//如果匹配的只有一個(gè)則直接返回if (candidates.Count <= 1){selectedProvider = candidates.FirstOrDefault().Provider;}else{//如果匹配到多個(gè)則按照Quality倒序和Priority正序的負(fù)責(zé)匹配第一個(gè)selectedProvider = candidates.OrderByDescending(x => x.Quality).ThenBy(x => x.Priority).First().Provider;}//如果沒有匹配到selectedProvider或是identity的情況直接返回nullif (selectedProvider == null){return null;}return selectedProvider; }

通過以上的介紹我們可以大致了解到響應(yīng)壓縮的大致工作方式，簡單總結(jié)一下

• 首先設(shè)置壓縮相關(guān)的算法類型或是壓縮目標(biāo)的MimeType

• 其次我們可以設(shè)置壓縮級別，這將決定壓縮的質(zhì)量和壓縮性能

• 通過響應(yīng)壓縮中間件，我們可以獲取到一個(gè)優(yōu)先級最高的壓縮算法進(jìn)行壓縮，這種情況主要是針對多種壓縮類型的情況。這個(gè)壓縮算法與內(nèi)部機(jī)制和注冊壓縮算法的順序都有一定的關(guān)系，最終會(huì)選擇權(quán)重最大的返回。

• 響應(yīng)壓縮中間件的核心工作類ResponseCompressionBody通過實(shí)現(xiàn)IHttpResponseBodyFeature，重寫輸出相關(guān)的方法實(shí)現(xiàn)對響應(yīng)的壓縮，不需要我們手動(dòng)進(jìn)行調(diào)用相關(guān)方法，而是替換掉默認(rèn)的輸出方式。只要設(shè)置了響應(yīng)壓縮，并且請求滿足響應(yīng)壓縮，那么有調(diào)用輸出的地方默認(rèn)都是執(zhí)行ResponseCompressionBody里壓縮相關(guān)的方法，而不是攔截具體的輸出進(jìn)行統(tǒng)一處理。至于為什么這么做，目前我還沒有理解到設(shè)計(jì)者真正的考慮。

總結(jié)

????在查看相關(guān)代碼之前，本來以為關(guān)于響應(yīng)壓縮相關(guān)的邏輯會(huì)非常的簡單，看過了源碼才知道是自己想的太簡單了。其中和自己想法出入最大的莫過于在ResponseCompressionMiddleware中間件里，本以為是通過統(tǒng)一攔截輸出流來進(jìn)行壓縮操作，沒想到是對整體輸出操作進(jìn)行重寫。因?yàn)樵谥拔覀兪褂肁sp.Net相關(guān)框架的時(shí)候是統(tǒng)一寫Filter或者HttpModule進(jìn)行處理的，所以存在思維定式。可能是Asp.Net Core設(shè)計(jì)者有更深層次的理解，可能是我理解的還不夠徹底，不能夠體會(huì)這樣做的好處究竟是什么，如果你有更好的理解或則答案歡迎在評論區(qū)里留言解惑。

????歡迎掃碼關(guān)注我的公眾號????

總結(jié)

以上是生活随笔為你收集整理的ASP.NET Core中的响应压缩的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。