如何详细改写.Net Core HttpClient处理响应压缩的代码，使其成为一篇长尾词的？

本文共计2690个文字，预计阅读时间需要11分钟。

目录：

一、使用方式

二、源码探讨

前言：在前面的文章中，我们提到了在ASP.NET Core中实现响应压缩的实践，其中服务端的主要工作是根据Content-Encoding头部信息判断采用何种方式压缩并返回。在此之前，群内有关于此的讨论。

目录

• 一、使用方式
• 二、源码探究

前言：

在之前的文章ASP.NET Core中的响应压缩的实现提到，服务端的主要工作就是根据Content-Encoding头信息判断采用哪种方式压缩并返回。之前在群里有人问道过，现在的网络带宽这么高了还有必要在服务端针对请求进行压缩吗？确实，如今分布式和负载均衡技术这么成熟，很多需要处理高并发大数据的场景都可以通过增加服务器节点来进行。但是，在资源受限的情况下，或者是还没必要为了某一个点去增加新的服务器节点的时候，我们还是要采用一些程序本身的常规处理手段来进行处理。笔者个人认为响应压缩的使用场景是这样的，在带宽压力比较紧张的情况，且CPU资源比较充足的情况下，使用响应压缩整体效果还是比较明显的。
有压缩就有解压，而解压的工作就是在请求客户端处理的。比如浏览器，这是我们最常用的Http客户端，许多浏览器都是默认在我们发出请求的时候(比如我们浏览网页的时候)在Request Head中添加Content-Encoding，然后根据响应信息处理相关解压。这些都源于浏览器已经内置了关于请求压缩和解压的机制。