Hi，大家好，我是承香墨影！
HTTP 协议在网络知识中占据了重要的地位，HTTP 协议最基础的就是请求和响应的报文，而报文又是由报文头（Header）和实体组成。大多数 Http 协议的使用方式，都是依赖设置不同的 HTTP 请求/响应 的 Header 来实现的。
本系列《实用 HTTP》就抛开常规的 Header 讲解式的表述方式，从实际问题出发，来分析这些 HTTP 协议的使用方式，到底是为了解决什么问题？同时讲解它是如何设计的和它实现原理。
HTTP 协议是一种无状态的“松散协议”，它不会记录不同请求的状态，并且因为它本身包含了两端（客户端和服务端），根据请求和响应来区分，它大部分的内容都只是一个建议，其实双边是可以不遵守此建议的。
“这里写了建议零售价 2 元...”
“哦，不接受建议！”
在上一篇文章中，聊到了 ，其实缓存的主要起因就是为了减少网络请求次数，来达到快速响应的目的。而除了减少网络请求之外，其实我们还可以通过对实体内容，进行编码压缩的方式，减少传输的内容大小，从而加快响应的速度。
本文就就继续来聊聊 HTTP 的实体内容压缩编码机制。
二、HTTP 的内容编码 2.1 为什么要对内容进行编码？编码的目的就是为了压缩报文实体内容的大小，而通过压缩服务器响应报文传输的内容实体，在一定程度上就可以加快响应的速度。
毕竟传输一个 10kb 的内容，会比传输一个 100kb 的内容快很多。这就是需要使用内容编码进行压缩的原因。
2.2 压缩编码说到压缩编码，就先简单聊聊压缩算法，对于压缩算法而言，分为两类：
无损压缩算法
有损压缩算法
从名称上就可以理解，无损压缩意味着它是可以被还原的，通常被应用在文本，而有损压缩会对原始数据进行修改，以加大压缩率的目的，对文件进行有损失的压缩，这是一种不可逆的操作，通常一些对质量要求不高的图片和视频上，虽然压缩以后可能会导致文件模糊，但是勉强还可以看。
而在 HTTP 协议中，通常我们只会对文本内容，进行压缩编码。一个主要的原因在于，压缩本身是会消耗服务器资源的，而文件比多媒体文件轻便了很多。并且多媒体文件多数情况下，本身就已经是高度压缩的二进制格式，再次进行压缩的意义也不大。
2.3 设计一个“压缩协议”前面提到，HTTP 协议是一种松散的 “协商协议”，需要客户端和服务端双端配合，才可以生效。而压缩算法有很多种，到底应该选择哪一种，也是需要双方协商的。
如果我们尝试设计一下这个 HTTP 的 “压缩协议”，主要需要关注这两点。
1. 通知服务端，客户端支持的压缩算法
一个 HTTP 事务，总是由客户端发起请求，而服务端将响应返回。那么客户端就要在发起请求的时候，率先告知服务端，当前客户端支持的压缩算法。
通常客户端会支持多种压缩算法，为了让服务端有选择的空间，应该允许传递多个支持的压缩算法。既然有多选的空间，那么就一定要有优先级的概念。
类似于我们在市场上交易，我接受人民币、美元、比特币的交易，但是因为我使用人民币更方便，所以我需要指明交易方，如果方便的话最好通过人民币交易。
2. 服务端选择支持的压缩算法压缩内容
服务端接受到客户端的请求后，辨识出客户端支持的压缩算法，现在当前环境最优的一种压缩算法对响应内容体进行压缩，然后将压缩后的内容返回。
为了让客户端接收到响应后，能明确知道服务端使用的压缩算法，还需要在响应中明确指明，当前的响应实体的数据使用的压缩算法（当然也可以不压缩）。
2.4 HTTP 的“压缩协议”前面我们自己设计的两个条件，都是基于 HTTP 报文中的报文头来实现的。接下来我们看看 HTTP 协议中，是如何设计“压缩协议”的。
1. 请求头中的 Accept-Encoding
客户端为了告知服务端当前支持的压缩编码，可以在请求头中，增加 Accept-Encoding 这个头部字段，用来指定当前客户端支持的压缩编码，如果有多个可以使用逗号 , 进行分割。
为了满足优先级，其实是可以通过 , 分割的顺序来指定的。HTTP 协议中，还可以使用 Q 值来说明编码的优先级，Q 值的取值范围是 0.0 ~ 1.0。0.0 表示客户端不想接受此编码，而 1.0 则表示希望使用此编码，不过通常我们不需要明确的指定它，大家了解一下即可。
2. 响应头中的 content-encoding
服务端为了在响应报文里体现当前对内容压缩使用的编码格式，会在响应头中使用 Content-Encoding 标记，它是一个明确值，所以只可能有一个。
编码的目的就是为了压缩，所以当服务端选择压缩内容实体的时候，同时还会修改 Content-Length 来明确表示当前实体被编码压缩后的长度。
发两张压缩前和压缩后的流程图，就清晰了。
压缩前：
压缩后：