《HTTP协议》响应内容压缩个人技术分享

区别

首部名称	说明	使用方式	使用位置
Transfer-Encoding	指定报文主体在传输时使用的编码方式	逐跳首部	通用首部
TE	用于告知服务器客户端能够处理的编码方式和相对优先级	逐跳首部	请求首部
Content-Encoding	指定报文主体在传输时使用的编码方式	端到端首部	实体首部
Accept-Encoding	用于告知服务器客户端能够处理的编码方式和相对优先级	端到端首部	请求首部

其中，逐跳首部 表示只在两个节点之间（源服务器和代理服务器之间、代理服务器和客户端之间等）有效； 端到端首部 表示在整个传输过程有效。

假设A为服务器，D为客户端，从A到D的路径为A-B-C-D，所需传输的资源为X。步骤如下：

D向A请求X，并在请求报文中指明自己支持的编码方式为gzip；
```
Accept-Encoding:gzip
```
请求按路径传递到A处，A将X用gzip编码进行压缩并发到B处，由B进行下一步转交，并在报文中指明使用的编码方式为gzip；
```
Content-Encoding:gzip
```
B认为传给C时使用分块传输比较合理，就对A传过来的报文实体进行分块，并在报文中说明：
```
Content-Encoding:gzip
Transfer-Encoding:chunked
```
C收到B的报文，并根据Transfer-Encoding:chunked判断出B进行了分块传输，于是C对收到的各个分块进行重组，还原出完整的X（注意此时的X还是被gzip压缩过的状态）。之后C不进行分块，直接将整个发送给D：
```
Content-Encoding:gzip
```
D接收到响应报文，并根据Content-Encoding:gzip判断出报文实体已经被gzip压缩过了，于是对其进行解码，最终获得资源X。

chunked
数据以一系列分块的形式进行发送。 Content-Length 首部在这种情况下不被发送。在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着 ‘\r\n’ ，之后是分块本身，后面也是’\r\n’ 。终止块是一个常规的分块，不同之处在于其长度为0。终止块后面是一个挂载（由trailer首部在报文主体之前规定），由一系列（或者为空）的实体消息首部构成。

HTTP/1.1 200 OK
Content-Type: text/plain 
Transfer-Encoding: chunked
7\r\n
Mozilla\r\n 
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n

compress
已被弃用
deflate
采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。

据说浏览器和服务器支持性不好，也是应该被禁用的压缩方法。对压缩的机制并不是十分清楚，请参考 deflate——过时的网页压缩格式，最好禁用
gzip
表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式。这个编码方式最初由 UNIX 平台上的 gzip 程序采用。处于兼容性的考虑， HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的 x-gzip 指令。
gzip是目前支持性最好，也最常用的压缩格式，Apache开启gzip有两种方式：第三方模块mod_gzip，官方模块mod_deflate（虽然名字里有deflate但是跟deflate指令没有关系）
identity
用于指代自身（例如：未经过压缩和修改）