在2017年，我有机会从事一个旨在提高数据压缩性能的项目。在此过程中，我研究了zlib库及其实现的deflate压缩算法。在这里，我想与那些也希望对zlib有更好理解的人分享我的研究。

zlib是一个免费的开源软件库，用于无损数据压缩 和 减压。它是由Jean-loup Gailly（压缩）和Mark Adler（解压缩）用C语言编写的。zlib的第一个版本于1995年5月发布。Jean-loupGailly和Mark Adler也为gzip（GNU zip）。在后台，gzip使用zlib库。

迄今为止，zlib主要由Mark Adler维护，其最新更新和版本均可在GitHub上找到。Mark Adler还积极参与Stack Overflow，以回答有关zlib和gzip的技术问题。

许多软件应用程序和库都使用zlib。如果引起注意，您几乎可以在操作系统，Internet服务，流服务，文档编辑器等中的任何地方找到zlib。这是这些应用程序的不完整列表。

zlib规范于1996年5月获得正式的Internet RFC（征求意见）状态。

• RFC 1950：zlib压缩数据格式
• RFC 1951：压缩压缩数据格式
• RFC 1952：gzip文件格式

的 压缩 zlib中使用的算法是 放气方法。deflate方法将输入数据编码为压缩数据。的减压 zlib中使用的算法是 膨胀 方法，这是一种解码过程，需要使用压缩的位流进行解压缩并正确生成原始的全尺寸数据或文件。

在本文档中，我将重点介绍zlib的压缩部分以及zlib对zlib的实现。 放气算法。

放气的方法最初是由定义菲尔·卡茨在PKWARE的归档工具PKZIP 2.x版本 它是LZ77算法 和 霍夫曼编码。

下图从高层次说明了放气和充气过程。

LZ77是基于字典的无损压缩算法。它也被称为LZ1。

基于字典的算法的基本思想是，通过引用该序列的先前出现来替换数据中特定字节序列的出现。

基于字典的压缩算法有两种主要类型：LZ77和LZ78。这两个算法以两个创建者Jakob Ziv和Abraham Lempel命名。LZ77（Lempel-Ziv77）和LZ78（Lempel-Ziv78）分别发表于1977年和1978年。

LZ77压缩算法通过使用 滑动窗口 查找重复的数据序列，并使用称为a的一对数字对每个重复的序列进行编码 长距离对。

滑动窗口用于检查输入数据序列，并维护用作字典的历史数据。换句话说，字典是先前出现和编码的数据的一部分。

滑动窗由两部分组成： 搜索缓冲区和 前瞻缓冲区。搜索缓冲区包含字典-最近编码的数据，而前瞻缓冲区包含要编码的输入数据序列的下一部分。下图给出了一个滑动窗口的示例。

长度-距离对指示下一个 长度 字符与字符完全相同 距离 原始数据流中后面的字符。

在LZ77算法中，压缩器通过搜索缓冲区进行搜索，直到找到与超前缓冲区中的第一个字符匹配为止。搜索缓冲区中可能存在多个匹配项，并且压缩程序将找到长度最长的一个匹配项。当。。。的时候最长的匹配 找到后，压缩器将其编码为三元组 （D，L，C） 哪里：

• D =搜索光标到超前缓冲区起点的距离
• L =最长匹配的长度
• C =超前缓冲区中最长匹配的下一个字符

在三元组中添加第三个元素C的原因是为了处理在搜索缓冲区中找不到匹配项的情况。在这种情况下，D和L的值均为0，并且C是当前预读缓冲区中的第一个字符。

下图显示了LZ77如何找到最长匹配项并为给定字符串编码重复字符“axrrmaxrbaxssr”的示例。

霍夫曼编码是一种统计压缩方法。它使用以下代码编码数据符号（例如字符）可变长度代码，代码长度基于相应符号的频率。

霍夫曼编码以及其他可变长度编码方法具有两个属性：

1. 对更加频发发生的数据符号的代码比低频发生的数据符号 更短。
2. 每个代码可以是 唯一解码。这要求代码是前缀码，表示一个符号的任何代码都不是其他符号的代码前缀。例如，如果将code“0”用作symbol “A”，则code“01”不能用于symbol“B”，因为code“0”是code“01”的前缀。前缀属性可确保在解码时确定符号边界在哪里没有歧义。

霍夫曼编码有两个步骤：

1. 从原始数据符号构建霍夫曼树。霍夫曼树是一种二叉树结构。
2. 遍历霍夫曼树并将代码分配给数据符号。

霍夫曼码可以是 固定（静态） 要么 动态。两者都用deflate方法。

可以通过检查大量数据集并找到典型的代码长度来创建固定的霍夫曼代码。使用固定霍夫曼编码时，所有输入数据符号均使用相同的编码。

动态霍夫曼码是通过将输入数据分为多个块，并为每个数据块生成代码来生成的。

zlib的实现是实用且高效的。在过去的20年中，人们进行了许多尝试来提高压缩应用程序的性能，但是似乎我们只能通过使用除放气（和放气），采用并行处理或改进CPU级别指令以外的算法来获得更好的性能。因此，zlib（在其GitHub存储库中指出）相当庞大而精致的压缩库。

在以下各节中，我们将介绍zlib用于实现deflate压缩算法的一些详细技术。

zlib具有10个压缩级别（0-9）。不同级别的压缩性能不同压缩率 和 速度。级别0表示不压缩，zlib将输出原始数据。1级是最快的，但压缩率较低。级别9提供最高的压缩率，但压缩速度较慢。zlib使用的默认压缩级别为6。

在引擎盖下，压缩级别会在放气过程中更改放气策略和参数。更多细节将在以下各节中讨论。

在zlib中，滑动窗口的默认大小为64KB。滑动窗分为两部分，分别对应搜索缓冲区 和 前瞻缓冲区，每个部分为32KB。输入字节被读入窗口的后半部分，然后移至前半部分以保持至少32KB的字典。该组织确保始终以块大小（8KB）的倍数执行IO。此外，在较旧的平台MSDOS上64KB的限制非常有用。

以下代码段显示了如何初始化滑动窗口。宏MAX_WBITS确定滑动窗口的大小。它是可配置的，默认值为15，这将导致32KB的搜索缓冲区和64KB的滑动窗口。

zlib用于在搜索缓冲区中找到最长匹配项的技术很简单，而且对于大多数输入文件来说，它是最快的：使用字符串匹配算法查找可能的匹配项，然后尝试所有可能的匹配项并选择最长的匹配项。

小字符串的匹配算法的灵感来自 Rabin-Karp算法。该算法的关键特征是，在字符串字典中的插入非常简单，因此速度很快，并且完全避免了删除。插入在每个输入字符处执行，而字符串匹配仅在上一个匹配结束时执行。因此，最好花更多时间进行匹配，以允许非常快速的字符串插入并避免删除。当发现较小的匹配项时，将使用蛮力方法来查找较长的字符串。

因此，总而言之，找到最长匹配项的过程包括两个主要部分：

1. 在滑动窗口中，对于超前缓冲区中的每个数据符号，使用基于Rabin-Karp算法的方法来查找 可能的匹配在搜索缓冲区中，并记录匹配开始位置。可能有多个可能的匹配项。
2. 对于每个可能的匹配，从匹配开始位置开始，检查以下每个数据符号以找到 当前最长的匹配。搜索在步骤1中找到的所有可能的匹配项，直到找到最长的匹配，或找到长度超过预定义的匹配项 最长匹配限制。

zlib将MIN_MATCH和MAX_MATCH定义为最低 和 最大值 匹配搜索的长度。

Rabin-Karp算法是由Richard M. Karp和Michael O. Rabin创建的字符串搜索算法。它使用散列来查找文本中一组模式字符串中的任何一个。例如，给定文字“AABAACAADAABAABA”和图案“AABA”，我们可以使用Rabin-Karp算法来找出模式在索引中的文本存在0，9，12。

以下伪代码描述了Rabin-Karp算法的工作原理。

如前所述，Rabin-Karp算法检查子字符串的哈希值，以查找文本中的匹配项。为了在存储最新数据符号的搜索缓冲区中找到匹配项，zlib使用了哈希链组织保留每3个字节（或由MIN_MATCH定义的其他值）的哈希值的记录。

zlib中的此哈希链通过使用两个数组来实现：prev[]和head[]。两个数组都将位置存储在滑动窗口中。该head[]数组存储哈希链的头部，该prev[]数组存储并链接具有相同哈希索引的字符串的位置。下图显示了哈希链如何工作的示例。

在哈希链中搜索最长匹配项时，zlib会限制 链长 以提高搜索效率。搜索限制是通过以下方式设置的：

1. 预定义max_chain_length值。对于不同的压缩级别，此值是不同的。
2. 在搜索过程中，如果找到匹配项且其长度不小于预定义的good_match长度，则搜索长度将缩短为new_search_chain_length = search_chain_length / 4

搜索极限值在 配置表：

Zib既实现 静态（固定）霍夫曼编码 和 动态霍夫曼编码。对于LZ77编码数据的每个块，zlib使用静态霍夫曼编码和动态霍夫曼编码来计算该块中的位数，然后选择方法 产生 较小的数量数据的。如果使用两种方法使位数相等，则zlib选择静态霍夫曼编码，因为解码过程更快。

整个数据流可以包含静态和动态霍夫曼编码数据的混合。在每个块的放气流头中发送霍夫曼码。

总而言之，zlib中的霍夫曼编码过程包括以下步骤：

1. 在LZ77编码过程中，收集 数据字节统计 并生成直方图
2. 对于每个数据块，构建一个 动态霍夫曼树 使用收集的统计信息。
3. 使用动态霍夫曼树和静态霍夫曼树计算并比较编码的块长度，并确定是否值得使用 动态或静态树 用于编码阶段。
4. 对数据块执行动态或静态霍夫曼编码。

压缩中的一个重要概念是 数据块。 压缩数据格式由块组成，这些块的头取决于块数据。因此，deflate的输出一次到达一个块，直到第一个块完成之前，什么都没有写（zlib或gzip标头除外）。考虑到数据块在deflate过程中如何传输，zlib实现了几个缓冲区 存储数据块并控制I / O性能。

开始压缩之前，zlib 积累数据 在一个 输入缓冲区，当输入缓冲区已满时开始压缩。默认输入缓冲区大小为8KB。

之所以具有输入缓冲区，是因为zlib不会生成任何输出数据，直到在其中生成16K数据符号为止。 文字缓冲区（文字缓冲区的默认大小为16K，有关文字缓冲区的详细信息，请参见下一部分）。因此，以非常短的数据长度开始压缩没有任何好处。使用输入缓冲区可提高I / O效率。

可以使用gzbuffer功能更改默认的输入缓冲区大小。

文字缓冲区存储的数据符号由LZ77编码。符号可以是编码为文字的单个字节，也可以是长度-距离对，它可以对前32K未压缩数据中某处最多258个字节的副本进行编码。默认的文字缓冲区大小为16K，因此未压缩数据的累积范围为16K至4MB（对于高度可压缩的数据）。

一旦 文字缓冲区已满，zlib决定为霍夫曼编码构造哪种块，然后执行此操作，创建标头，该标头针对动态块描述该块中的霍夫曼代码，然后为该块创建编码符号。或者，它会创建一个存储块或静态块，无论结果是最少的位数。只有这样，压缩数据才能用于输出。

默认文字缓冲区大小由marco配置DEF_MEM_LEVEL。在zlib的代码中，DEF_MEM_LEVEL = 8，所有压缩级别都相同。因此，所有压缩级别都具有相同的16K文字缓冲区大小。

为了输出压缩数据，zlib使用两个缓冲区： 暂挂缓冲区， 和 输出缓冲区。数据流如下图所示：

多家公司对通过优化zlib的实施来提高压缩性能感兴趣。以下是一些摘要最近的相关作品。

参考：英特尔：英特尔架构处理器上的高性能ZLIB压缩（pdf）

优化的重点在于改进的散列，在LZ77进程中搜索子串的最长前缀匹配以及Huffman代码流。

改进的哈希：对于压缩级别1到5，哈希元素为四元组（至少匹配4个字节）。对于6到9的压缩级别，请使用zlib的原始哈希元素作为三元组（至少匹配3个字节）。

添加两个其他策略：级别1为DEFLATE_quick，级别4至6为DEFLATE_medium。

• DEFLATE_quick：将哈希链搜索限制为第一个条目。
• DEFLATE_medium：旨在在zlib的压缩率之间取得平衡 DEFLATE_slow 策略以及zlib的性能 DEFLATE_fast战略。找到匹配项后，它将跳过匹配长度的转发，并支持延迟匹配评估的变体。当在位置p和长度l上找到匹配项时，在位置p + l + 1检查匹配项。如果找到新的匹配项，则从position p + l + 1向后扫描，以确定是否可以改善第二个匹配项。

哈希表移动速度更快：利用SSE（Intel©）一次对8个条目（16字节）进行哈希移位。

更快的CRC计算：利用PCLMULQDQ（Intel©）指令以更改的算法一次处理64字节的输入。

减少循环展开：消除了现代处理器上Adler32和CRC32计算中过多的循环展开。对于Adler32，将展开系数从16减小到8。对于CRC32，将展开系数从8减小到4。

参考：IBM：Deflate的快速实现

优化的重点是通过使用LZ4的重复消除过程和改进的霍夫曼编码过程来提高zlib放气过程的速度。

用LZ4替换LZ77更快地消除重复：观察到的提速是中等的，可能由于缓存使用率的差异而未达到LZ4的性能。还观察到的压缩比几乎不受影响。

强制使用静态霍夫曼树：达到较快的速度，但可能对压缩率产生负面影响。

半静态霍夫曼编码：使用静态树压缩中间数据的第一个块（LZ77的输出），并收集该第一个块的统计信息，以构建用于编码后续块的霍夫曼树。第一个块的大小是配置，默认大小是8KB。其他块的大小也是可配置的，默认值为128KB。添加的另一个步骤是在构建霍夫曼树之前确定初始块的统计信息，以确定是否值得使用动态树。这种方法既可以实现更快的速度，又可以实现更好的压缩率。

参考：Facebook Zstandard（zstd）设计介绍

GitHub上的Zstandard

Zstandard旨在与现代硬件一起扩展，并压缩得更快，更小，从而可以对各种数据类型进行通用压缩。

通过结合几种最新创新并针对现代硬件来改进zlib。

增加视窗大小 到1MB-8MB（推荐）。

压缩使用 有限状态熵 基于ANS（非对称数字系统）的系统，以提高性能并减少延迟。

用 repcode建模 有效压缩结构化数据

用一个 无分支设计风格 减少CPU分支预测器的开销。

在解压缩中，将数据分成多个并行流，并使用新一代的霍夫曼解码器 并行解码多个符号一个核心。这利用了现代CPU的能力，即每个周期可以发出多个指令。

参考：使用Zopfli的数据压缩（pdf），Brotli，Deflate，Zopfli，LZMA，LZHAM和Bzip2压缩算法的比较（pdf）

GitHub上的Zopfli

GitHub上的Brotli

Google在2013年推出了 佐普利，与deflate格式兼容。Zopfli给较小的压缩数据大小 比gzip（小3.7-8.3％），但它具有 压缩速度较慢 比gzip 9级高。Zopfli库只能压缩，不能解压缩。

布罗特利 尝试实施 新的压缩格式，并且比放气更有效。它的速度与放气相似，但压缩更紧密。

Brotli压缩格式在RFC 7932中定义。该算法结合了LZ77算法的现代变体，霍夫曼编码和二阶上下文建模的组合。它还使用包含超过13K个单词的静态字典。静态字典有助于压缩短文件。

参考：Apple数据压缩：LZFSE

LZFSE专为iOS和macOS设计，以实现更高的能源效率和速度（介于2x和3x之间）。

LZFSE算法的用途 LZ77 和 有限状态熵编码。

参考：CloudFlare与癌症抗争：开放源代码带来的意想不到的好处

GitHub上的CloudFlare zlib fork

CloudFlare对zlib的改进包括：

• 用 uint64_t 替换16位类型。
• 使用 改进的哈希函数iSCSI CRC32。此功能作为Intel处理器上的硬件指令实现。它具有非常快的性能和更好的碰撞性能。
• 搜索至少匹配的项 4字节。
• 使用SIMD指令 窗户滚动。
• 使用Intel的硬件无携带乘法指令PCLMULQDQ CRC32校验和。
• 优化的最长匹配功能。这是库中对性能要求最高的功能。

尚未包含在已发布的zlib fork中的其他实验：

• 使用zlib（哈希链）中使用的链表的改进版本

基准测试结果

• 测试数据集是四个标准语料库数据，包括ASCII文本，位图图像，数字和源代码文件。
• 速度：通常，CloudFlare的zlib比zlib和Intel的zlib快2至9级，尤其是6至9级（2倍-7.5倍）。
• 压缩率：在所有级别上与zlib非常相似，并且在级别1上优于Intel的zlib。

参考：CloudFlare：使用预设的deflate字典改善压缩

优化旨在提高HTML文件的压缩性能（降低25％）（主要是 短文）。

将最小匹配长度更改为 4字节。

用一个 预设字典 因此在输入的开头有用于搜索匹配项的反向参考。

• 通过对一组要压缩的文件执行伪LZ77来创建预设字典，并在每个输入文件的前16Kb中找到DEFLATE不会压缩的字符串。然后对各个字符串进行频率计数，并根据其长度和频率对其进行评分。得分最高的字符串将保存到词典文件中。
• 使用Go程序制作这样的deflate字典：GitHub上的独裁者

• zlib源代码
• zlib技术细节
• 数据压缩-斯坦福大学二年级项目