公司因业务须要,要求实现 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 用户请求文档以前就已经应用到这些文档的编码和压缩方法。这也被称为预压缩 或静态压缩。因为存在复杂的文件维护负担,这个概念历来没有获得真正的重视,并且使用预压缩页面的站点也不多。
传输编码 是指实际数据传输过程当中的编码方法。