一、为什么要编码（压缩）
- 编码的目的就是为了压缩报文实体内容的大小，而通过压缩服务器响应报文传输的内容实体，在一定程度上就可以加快响应的速度。
- encode:If you encode a message or some information, you put it into a code or express it in a different form or system of language.
Accept-Encoding:设置接受的编码格式（对内容[body部分]压缩方式）
二、Accept-encoding与Content-encoding压缩过程
-
浏览器发送Http request 给Web服务器, request 中有Accept-Encoding: gzip, deflate。 (告诉服务器， 浏览器支持gzip压缩)
-
Web服务器接到request后， 生成原始的Response, 其中有原始的Content-Type和Content-Length。
-
Web服务器通过Gzip，来对Response进行编码， 编码后header中有Content-Type和Content-Length(压缩后的大小)， 并且增加了Content-Encoding:gzip. 然后把Response发送给浏览器。
-
浏览器接到Response后，根据Content-Encoding:gzip来对Response 进行解码。 获取到原始response后， 然后显示出网页。
（因为客户端Accept-Encoding有可能提供了多种解压方式，所以服务端返回时，要指定是用哪种压缩方式进行压缩的）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nVvhHxHr-1582283888338)(https://user-images.githubusercontent.com/56629574/70876605-31badd80-1ff5-11ea-81ca-1fb8572c79c0.png)]
三、二中为什么要加content-length
- 在http1.0时非持久连接，是用连接是否关闭来界定请求或响应实体的边界；对于http1.1持久连接（浏览器可以重用已经打开的空闲持久连接，来避免三次握手，从而避免遇上TCP慢启动的拥塞适应阶段），显然不奏效，因为连接并没有关闭，造成浏览器并不知道已经发送完毕（尽管服务端已经发送完所有数据），从而导致响应内容不会显示在浏览器界面上。
- 要解决这个问题可以在响应头上加content-length，浏览器用此字段判断响应实体结束。
- 但是content-length有时并不容易获取，需要开足够大的buffer，等内容全部生成再计算，从而造成内存开销大而且用户等待时间长（这不利于用户体验），为解决此问题，有了Transfer-Encoding。
四、传输编码Transfer-Encoding解决的问题
- Transfer-Encoding会改变报文的格式和传输方式，使用它不会减少内容传输的大小，甚至会使传输变大，但是解决了content-length所带来的问题。
五、Transfer-Encoding-Chunked格式
- 将报文中实体用分块方式来传输。每个分块包含16进制的长度值及数据，最后一个分块长度值必须为0，代表传输结束。
- Transfer-Encoding: chunked：数据以一系列分块的形式进行发送。 Content-Length 首部在这种情况下不被发送。
六、Content-Encoding和Transfer-Encoding结合使用
即先对内容压缩，再对其分块传输。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c7jOi3sY-1582283888341)(https://user-images.githubusercontent.com/56629574/70877049-d984db00-1ff6-11ea-9f0a-595fc913123e.png)]
参考：https://blog.csdn.net/zhangzeguang88/article/details/51554097
https://www.cnblogs.com/plokmju/p/http_code.html
