# 随机数据压不动：gzip砍的只是重复 ## 导语：压缩是日常魔法，但它的"魔法"有个硬上限 你每天离不开压缩。打开网页，HTTP 响应体多半被 `Content-Encoding: gzip` 压过；保存一张截图，PNG 内部跑的是 DEFLATE；`git` 把每个对象塞进 zlib；你下载的 `.zip`、`.gz`、`.tar.gz`，本质都是同一族算法。我们早就把"文件能变小"当成理所当然，却很少有人追问：**它凭什么能让 100MB 变成 10MB？那 90MB 去哪了？** Computerphile 这支由 Nottingham 大学 David Brailsford 教授主讲的《Compression》正是来拆解这个日常魔法的。它不长，只有十分钟出头，却把压缩的**第一性原理**讲得异常干净——压缩不是"凭空省空间"，它的全部秘密只有四个字：**砍掉重复**。一支视频、一个教授、一块黑板，告诉你为什么文本能压、为什么 JPEG 已经压过就不能再压、以及那个最反直觉的结论——**随机数据，你一比特都压不动，越压反而越大。** 这篇文章以该视频为锚，补全视频没展开的工程实现：LZ77 的滑动窗口到底怎么工作、Huffman 为什么用变长编码、DEFLATE 如何把两者缝成 gzip 的真身，以及 Shannon 熵这个"天花板"如何决定了所有压缩算法的物理极限。看完你会真正理解：**压缩的本质不是技术，是信息论。** ## 视频背景卡片 | 项目 | 内容 | |------|------| | 视频标题 | Compression - Computerphile | | 频道 | Computerphile（University of Nottingham） | | 主讲 | Professor David Brailsford | | 时长 | 约 10 分钟 | | 播放量 | 百万级（Computerphile 经典科普视频） | | 频道订阅 | 约 270 万 | | 核心主题 | 无损压缩与有损压缩的第一性原理 | ## 核心内容拆解 ### 一、压缩的第一性原理：它砍的是"冗余"，不是"比特" 这是 Brailsford 教授在视频里反复强调的底层逻辑（**视频原话核心**）：所谓压缩，本质上是**找出数据里重复出现的模式，然后用更短的符号去指代它**。数据本身的信息量（información）一个比特都没少——少的是**冗余的编码方式**。 举个视频里会点到、我在这里彻底展开的例子：一段英文里，字母 `e` 出现的频率远高于 `z`。如果你坚持用 8 个比特（一个 ASCII 字节）等长编码每个字母，那么对 `e` 和 `z` 你都付了 8 比特的"票价"，这显然不划算。压缩要做的，就是承认这种**频率不均**，让高频符号买短票、低频符号买长票。**延伸分析**：这其实就是 Huffman 编码的思想内核，也是为什么同样一段文字，英文能压到原始大小的 30%，而你已经加密过、看起来毫无规律的密文几乎压不动——因为加密把频率信息"抹平"了，把数据推向了最大熵。 记住这一条，后面所有的算法都是在围着它转：**没有重复、没有规律，就没有压缩。** ### 二、无损 vs 有损：文本必须无损，图像可以"骗眼睛" 视频把压缩分成两大类（**视频原话核心**）： - **无损压缩（Lossless）**：解压后逐比特还原。文本、源代码、可执行文件、数据库——这些**错一个比特就废了**的东西，必须用无损。 - **有损压缩（Lossy）**：解压后"长得像"，但不完全一样。照片、音乐、视频——这些**人眼/人耳感知有冗余**的东西，可以丢。 为什么图像能"骗眼睛"？**延伸分析**：因为人眼对亮度的敏感度远高于对色彩的敏感度（这是 JPEG 把 RGB 转成 YCbCr 后对色度通道大幅降采样的生理依据），且对高频细节的失真容忍度很高。所以 JPEG 敢直接丢掉一部分高频系数——它丢的是"你本来就看不太清"的信息。而 `gzip`、`PNG`、`ZIP` 属于无损阵营，一个比特都不能错。 这个分类看似常识，却是理解所有压缩工具选型的起点：**你能不能"丢"，决定了你能用哪一类算法。** ### 三、最朴素的去冗余：游程编码（RLE） 视频用一个非常直觉的例子引入了第一种无损算法（**视频原话核心**）：如果数据里出现连续的相同字符，比如 `AAAAAAAAAA`（10 个 A），你完全没必要老老实实写十遍，写成 `A10` 就够了。这就是**游程编码（Run-Length Encoding, RLE）**——用"字符 + 重复次数"替代连续串。 RLE 简单到令人发指，但它的局限也立刻暴露：**只对"成片重复"的数据有效**。文本里几乎没有连续几十个相同字母，所以 RLE 压文本几乎没用；但它压传真图像（大面积黑白）、BMP 位图却立竿见影。**延伸分析**：早期 PCX、部分 BMP 就用 RLE。RLE 的价值在于它揭示了压缩的统一公式——**找到某种可被规律描述的结构，再用更短的符号重写它**。LZ77 不过是把"成片相同"推广成了"成段相同"。 ### 四、Lempel-Ziv（LZ77）：滑动窗口里找"似曾相识" 这是视频真正点名的现代无损压缩基石（**视频原话核心**）。LZ77 的天才之处在于：它不再只盯着"连续相同字符"，而是开一个**滑动窗口（sliding window）**，在窗口里找"刚才是不是出现过一模一样的片段"。如果出现过，就用一个**指针 `(距离, 长度)`** 指回去，告诉解压器"往前数 N 个字节，抄 M 个字节过来"。 **延伸分析（视频未展开的工程细节，但这是 gzip 的真身）**：DEFLATE 里的 LZ77 有几个硬参数—— - 滑动窗口最大 **32KB**（往后回看最多 32768 字节）； - 最小匹配长度 **3 字节**（短于 3 用指针反而更亏）； - 最大匹配长度 **258 字节**； - 输出的是一个由**字面量（literal）和匹配指针（length/distance pair）**交替组成的流。 举个例子，文本 `"the quick brown fox, the quick brown fox"`，第一次出现 `"the quick brown fox"` 时照实写字面量；第二次出现时，LZ77 直接回指——"往前 20 字节抄 19 字节"。这就是为什么**重复越多，压缩率越高**。HTML、JSON、源代码这种结构性极强、标签和关键字反复出现的格式，正是 LZ77 的猎物。这也解释了一个工程直觉：**gzip 对文本效果好（能压到 1/3 到 1/5），对二进制/媒体文件效果差**——因为它们已经被压过或本就高熵。 ### 五、Huffman 编码：高频符号买短票 LZ77 把"重复"换成了指针，但输出流里的每个符号还是等长存储的。**视频**点到了压缩的另一半——变长编码。**延伸分析**：Huffman 编码（DEFLATE 的第二阶段）干的就是这件事：统计每个符号的出现频率，构建一棵**前缀树**，让高频符号（如空格、字母 `e`）分到 3-4 比特的短码，低频符号（如 `z`、`q`）分到 10 多比特的长码。加权平均下来，每个符号的平均码长逼近 Shannon 熵。 Huffman 有个硬约束：必须是**前缀码（prefix code）**——任何一个符号的编码都不能是另一个符号编码的前缀，否则解码时无法判断边界。Huffman 树天然满足这点。**延伸分析**：DEFLATE 里 Huffman 有两种模式——**固定 Huffman**（用预设码表，省去传码表的开销）和**动态 Huffman**（根据实际数据统计出最优码表，连同码表一起写进压缩流）。聪明的是，连"码表本身"DEFLATE 都再用一次类 LZ 的游程压缩，把元数据也压一遍——这种"压缩的压缩"是 DEFLATE 效率的关键。 ### 六、DEFLATE：把 LZ77 和 Huffman 缝成 gzip 的真身 视频讲的是原理，但很多观众看完仍不知道 `gzip` 到底是什么。**延伸分析（关键科普）**：这是开发者最常混淆的一组概念—— - **DEFLATE**（RFC 1951）才是**真正的算法**，它 = LZ77（去重复）+ Huffman（变长编码）两步流水线。 - **zlib**（RFC 1950）= DEFLATE + 一个轻量头部（含 Adler-32 校验），`git`、`PNG` 用的就是它。 - **gzip**（RFC 1952）= DEFLATE + 文件头（含文件名、时间戳）+ CRC32 校验 + 文件尾，常用于 `.gz` 单文件和 HTTP 传输。 - **ZIP** = 一种**归档容器格式**，内部对每个文件用 DEFLATE 压缩，还能塞多个文件和目录结构。 所以"ZIP、GZIP、zlib 是不是一回事？"——**算法内核（DEFLATE）是同一个，外层包装不同**。这条冷知识能解决 90% 的开发者对压缩格式名混乱的困惑。 ### 七、最反直觉的结论：随机数据压不动，再压反而变大 这是整支视频（也是整个压缩理论）最该被记住的一句话（**视频原话核心 + 我的强调**）：**压缩不能凭空创造空间，它有天花板，这个天花板叫 Shannon 熵。** **延伸分析**：Claude Shannon 在 1948 年证明，一段数据的**信息熵** H = −Σ p·log₂(p) 给出了无损压缩的**理论下界**——你不可能把数据无损压到平均码长低于它的熵。已经接近最大熵的数据（加密密文、随机数、已压缩过的 JPEG/MP4）几乎没有冗余可砍，所以压不动。 更尖锐的是**鸽巢原理（pigeonhole principle）**的反证：所有长度为 N 比特的输入共有 2ⁿ 种，而长度 < N 比特的输出只有不到 2ⁿ 种——**必然存在某些输入，压完反而变长**（否则多对一的映射会让信息无法还原）。所以压缩算法都内置了"压缩失败就原样存储"的逃生通道：如果某个块压完比原来还大，DEFLATE 会标记为 `stored` 块，原封不动写进去。这也是为什么**给 `.zip` 再 `.zip` 一遍，文件不但不会变小，还会因为多了文件头而变大**。 一句话锁死：**压缩是在低熵数据上赚钱的生意，对高熵数据它要亏本。** ### 八、为什么压缩和安全绑在一起：CRIME 与 BREACH 这是视频完全没涉及、但工程师必须知道的一层（**纯延伸分析**）。既然压缩会把"重复/相似"压得更短，那么**响应体长度本身就泄露了内容信息**。攻击者正是利用了这一点： - **CRIME（2012）** 和 **BREACH（2013）** 攻击，就是通过观察 HTTPS 响应被 gzip 压缩后的**长度变化**，逐比特猜出 Cookie、CSRF Token 等敏感字段。攻击者把自己的猜测拼进请求里，若猜测与密文有重复，gzip 会把它压得更短——长度的小幅下降就成了"猜对了"的信号。 - 正因如此，**现代 TLS 早就禁用了传输层压缩**，HTTPS 不再压缩整个请求/响应；应用层若要用 gzip，也必须配合填充（padding）或随机化长度来防 BREACH。 这条把"压缩"和"安全"焊在一起：**压缩不是免费的——它在缩短数据的同时，也在制造一个隐蔽的信息侧信道。** ## 知识结构图 ```mermaid flowchart TD A["原始数据 Raw Data
（低熵 = 可压 / 高熵 = 压不动）"] --> B{"第一性原理：
有冗余/规律吗？"} B -->|是| C["无损压缩 Lossless"] B -->|否 / 已是高熵| Z["压不动，再压反而变大
Shannon 熵 = 天花板"] C --> D["第一步：LZ77
滑动窗口 32KB 找重复
输出 字面量 + 距离/长度指针"] D --> E["第二步：Huffman
高频短码 / 低频长码
前缀码保证可解码"] E --> F["DEFLATE 算法
= LZ77 + Huffman"] F --> G1["gzip 包装
RFC1952 / .gz / HTTP"] F --> G2["zlib 包装
RFC1950 / git / PNG"] F --> G3["ZIP 容器
多文件归档 + DEFLATE"] C --> H["有损压缩 Lossy
JPEG/MP3/H.264
丢人眼/人耳不敏感的频率"] G1 --> I["⚠ 安全侧信道
CRIME / BREACH
长度泄露内容"] ``` ## 实战启示：把它变成你手上的工具 对开发者而言，理解 DEFLATE 不是玄学，而是一组可操作的工程判断： 1. **选对场景才开 gzip。** 文本类（HTML/JSON/JS/CSS/源码/日志）是 gzip 的主场，通常能压到 1/3 ~ 1/5，能直接砍掉带宽成本和首屏延迟。但**对已压缩的二进制（PNG/JPEG/MP4/ZIP/加密文件）开 gzip 几乎无效，反而白耗 CPU**——这也是 Nginx 默认 `gzip_types` 不包含图片的原因。 2. **调参看业务。** gzip 有 1–9 共 9 个压缩等级，等级越高压缩率越好但越吃 CPU、越慢。在线实时传输通常用 `gzip 4~6` 平衡速度与压缩率；离线打包分发可以用 `gzip 9` 或 `zstd --ultra`。Facebook 推的 **Zstandard（zstd）** 是 DEFLATE 的现代替代，同压缩率下快一个数量级，新项目值得直接上。 3. **警惕"再压一遍"的幻觉。** 永远不要指望链式压缩能继续省空间——`gzip` 一个 `.jpg` 只会更大。判断一个文件"压不压得动"，看熵：**接近随性的文件，放手。** 4. **安全先于体积。** 如果你的 HTTPS 接口返回体里混着用户可控输入和敏感数据（典型如错误页回显），开 gzip 就要防 BREACH——加随机 padding、或干脆对这类响应不压缩。**压缩的长度是侧信道，工程师必须心里有数。** 5. **数据库与存储里主动用压缩。** `git` 用 zlib 压对象、很多数据库（如列存、ClickHouse、Parquet）默认带压缩——理解 LZ77+Huffman，你就能理解为什么"列存 + 压缩"是分析型查询的标配：**列内数据同质度高、冗余多，正是 LZ77 最爱的猎物。** 一句话行动指南：**先判断熵，再决定压不压；压文本，别压媒体；开 gzip，想安全。** ## 延伸学习路径 1. **Computerphile《Compression》原视频** — Brailsford 教授十分钟讲透压缩第一性原理，本文的锚点：https://www.youtube.com/watch?v=Lto-ajuqW3w 2. **《Data Compression (Summer 2023) - Lecture 11 - DEFLATE》by BillBird** — 大学的系统讲座，把 DEFLATE 从 RFC 逐字段拆给你看，适合想啃实现细节的工程师：https://www.youtube.com/watch?v=SJPvNi4HrWQ 3. **RFC 1951 (DEFLATE)** — 想真正手写一个解压器，这是唯一的权威：https://datatracker.ietf.org/doc/html/rfc1951 4. **《Compression: Clearing the Confusion on ZIP, GZIP, Zlib and DEFLATE》** — 一篇把这几个名字关系理清楚的好文：https://dev.to/biellls/compression-clearing-the-confusion-on-zip-gzip-zlib-and-deflate-15g1 5. **Reducible 频道的压缩系列** — 用可视化讲 LZ、Huffman、视频压缩，工程质量顶级的科普频道，强烈推荐订阅。 ## 一句话总结 压缩不是魔法，它的全部秘密是"砍掉重复"——LZ77 找重复、Huffman 给短码，缝成 DEFLATE；而 Shannon 熵决定了天花板，随机数据一比特都压不动，开 gzip 还得防着它把长度变成泄露内容的侧信道。 ## 参考来源 1. [Compression - Computerphile](https://www.youtube.com/watch?v=Lto-ajuqW3w) — 本文分析的核心视频（Prof. David Brailsford） 2. [Data Compression Lecture 11 - DEFLATE (gzip) - BillBird](https://www.youtube.com/watch?v=SJPvNi4HrWQ) — DEFLATE 算法的系统讲座 3. [Compression: Clearing the Confusion on ZIP, GZIP, Zlib and DEFLATE - dev.to](https://dev.to/biellls/compression-clearing-the-confusion-on-zip-gzip-zlib-and-deflate-15g1) — 压缩格式名关系梳理 4. [RFC 1951 - DEFLATE](https://datatracker.ietf.org/doc/html/rfc1951) — DEFLATE 算法权威规范 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。