公司因业务需要，要求实现 REST API 的 HTTP 客户端支持 gzip 压缩。那么首先需要回答下面几个问题：
- gzip 压缩和其他压缩方式有什么不同？或者说优劣在哪里？
- HTTP 协议中对压缩方式的常规支持有哪些？
=========== 我是分割线 ============
查阅相关资料如下：
LZ77 是一种基于字典的无损数据压缩算法（还有 LZ78, LZW 等）。
deflate 是一种数据压缩算法，实际上就是先用 LZ77 压缩，然后用霍夫曼编码压缩。
gzip 的基础是 defalte 。其通过 defalte 算法压缩数据，然后加上 gzip 文件头和 CRC 校验。压缩后生成 .tar.gz 或者 .tgz 文件。既是一种文件结构，也可以算一种压缩格式。
ZIP 也使用 defalte 算法，但可移植性更好，并且不需要一个外部的归档工具就可以包容多个文件。但是由于 ZIP 对每个文件进行单独压缩而没有利用文件间的冗余信息(固实压缩)，所以 ZIP 的压缩率要稍逊于 tar 压缩包。
zlib 是一个提供了 deflate, zlib, gzip 压缩方法的函数库；同时也是一种压缩格式，可以通过 deflate 压缩数据，之后加上 zlib 头和 CRC 校验来生成 zlib 文件格式。
bzip2 是一个基于数据块排序算法的文件压缩工具，并作为 gzip 的替代者逐渐得到流行，它可以生成相当小的压缩文件，尤其是对于源代码以及其它的结构化文本来说更是这样，但是这样做的代价是最高达 4倍内存与处理器时间消耗。bzip2 压缩的 tar 包传统上叫作 .tar.bz2 。
zlib 数据流格式、defalte 以及 gzip 文件格式均已被标准化成了，分别是 RFC 1950、RFC 1951 以及 RFC 1952。
=========== 我是分割线 ============
HTTP／1.1 协议允许客户端可以选择要求从服务器下载压缩内容，这个标准本身定义了三种压缩方法：
- “gzip”（内容用 gzip 数据流进行封装）
- “compress”（内容用 compress 数据流进行封装）
- “deflate”（内容是原始格式、没有数据头的 DEFLATE 数据流）
许多 HTTP 客户端库以及绝大多数现代的浏览器都支持前后两种格式。
=========== 我是分割线 ============
Web 压缩相关技术如下：
- HTTP 压缩：压缩来自 Web 服务器的内容
- Gzip 压缩： 一种无损失的数据压缩格式
- 静态压缩：预压缩，用于发送静态页面
- 内容及传输编码：IETF 用于压缩 HTTP 内容的两级标准
HTTP 压缩
HTTP 压缩是一种用于压缩来自 Web 服务器（HTTP 服务器）的内容的技术。Web 服务器内容的格式可以是诸多 MIME 类型中的一种：HTML、纯文本、图像格式、PDF 文件等。其中 HTML 和图像格式是在 Web 应用程序中最常用的 MIME 格式。
Web 应用程序中使用的大多数图像（例如 GIF 和 JPG）已经是压缩过的格式，无需进一步压缩；即使再压缩，性能也不会有大的改善。然而，静态或动态创建的 HTML 内容只包含纯文本，适合进行压缩。
HTTP 压缩的目的是使 Web 站点发送更少的数据。要有效实地现这个目的，需要以下条件：
- Web 服务器应该能够压缩数据
- 浏览器应能解压缩数据并以正常的方式显示页面
这是很明显的。当然，压缩和解压缩的处理不应消耗大量的时间或资源。
Gzip 压缩
Gzip 是一种无损失的数据压缩格式。所使用的算法是开源、无专利的 LZ77（Lempel-Ziv 1977）算法的变体。 该算法寻找输入数据内的重复字符串。二次出现的字符串由一个指向前一字符串的指针代替。
静态压缩
如果 Web 内容是预生成的并且不需要与其他系统进行服务器端动态交互，那么内容就可以被预压缩并放置在 Web 服务器内。而这些压缩了的页面则在用户请求时被发送。流行的压缩工具（gzip、Unix compress）均可压缩这些静态文件。
但是，当内容必须动态生成，比如对于电子商务站点或由应用程序和数据库驱动的站点，静态压缩没有什么用处。
内容和传输编码
IETF 用来压缩 HTTP 内容的标准包括两级编码：内容编码 和 传输编码 。
内容编码 是指在 Web 用户请求文档之前就已经应用到这些文档的编码和压缩方法。这也被称为预压缩 或静态压缩。由于存在复杂的文件维护负担，这个概念从来没有得到真正的重视，而且使用预压缩页面的站点也很少。
传输编码 是指实际数据传输过程中的编码方法。