http压缩,Content-Encoding

HTTP 协议中的Content-Encoding


Accept-Encoding 和Content-Encoding是HTTP中用来对采用哪种编码格式传输正文进行协定的一对头部字段。


工作原理如下:

• 首先浏览器（也就是客户端）发送请求时，通过Accept-Encoding带上自己支持的内容编码格式列表；
• 服务端在接收到请求后，从中挑选出一种用来对响应信息进行编码，并通过Content-Encoding来说明服务端选定的编码信息
• 浏览器在拿到响应正文后，依据Content-Encoding进行解压。
• 服务端也可以返回未压缩的正文，但这种情况不允许返回Content-Encoding

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

// Multiple algorithms, weighted with the quality value syntax:
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5



gzip使用 Lempel-Ziv 编码（ LZ77 ）的压缩格式，带有32位 CRC 。

compress使用 Lempel-Ziv-Welch（ LZW ）算法的压缩格式。

deflate使用 zlib 结构的压缩格式，以及 deflate 压缩算法。

br使用 Brotli 算法的压缩格式。

identity指示身份功能（即不压缩，也不修改）。即使不存在，该值始终被认为是可以接受的。

*匹配尚未在标题中列出的任何内容编码。如果标题不存在，这是默认值。这并不意味着支持任何算法; 只是表示没有偏好。

;q=（ q 值加权）任何值都按照称为权重的相对质量值的优先顺序排列。


Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

// Multiple, in the order in which they were applied
Content-Encoding: gzip, identity
Content-Encoding: deflate, gzip

gzip一种使用 Lempel-Ziv 编码（ LZ77 ）和32位 CRC 的格式。这最初是 UNIX gzip 程序的格式。

x-gzip为了兼容性的目的，HTTP / 1.1 标准还建议支持该内容编码的服务器应该将其识别为别名。

compress使用 Lempel-Ziv-Welch（ LZW ）算法的格式。值名取自实施此算法的 UNIX 压缩程序。

与大多数 UNIX 发行版已经消失的压缩程序一样，目前几乎没有浏览器使用这种内容编码，部分原因是由于专利问题（已在2003年过期）。

deflate使用 deflate 压缩算法（在 RFC 1951中定义）使用 zlib 结构（在 RFC 1950中定义）。

identity指示身份功能（即不压缩，也不修改）。除非明确指定，否则此标记始终被视为可接受。

br使用 Brotli 算法的格式。

在http协议中对于压缩过的数据定义如下

发送头部
xxx: yyy
xxx: yyy
xxx: yyy
空行
某段数据压缩后的长度
这段数据

如：

HTTP/1.1 200 OK
Date: Sun, 21 Jul 2019 18:55:38 GMT
Server: Apache
Vary: Accept-Encoding
Content-Encoding: gzip
Access-Control-Allow-Origin: *
Keep-Alive: timeout=5, max=50
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

19
   �