一、视角一换，问题就变了

同一条网络，两种问法：

| 视角 | 关心什么 | 典型问题 | |---|---| | 使用者 | 能不能通、快不快 | 为什么打不开 | | 发布者 | 多少字节、多少往返 | 怎么让首屏更快 |

第一行是前面九节一直在讲的角度：协议、地址、设备、分层，全是「怎么把数据送过去」。 第二行是这一节的角度：数据已经能送到了，现在的问题是「送得贵不贵、慢不慢」。 这个转换的意义在于： 使用者只能优化自己这一端，发布者能优化「路径上的每一环」—— 换更近的机房、压更小的格式、减更少的往返。 所以大厂能把首屏压到几百毫秒，靠的不是「网络更好」，是「这三个动作做得更彻底」。

二、减字节：压缩与编码

同一段文本，三种形态差得很远：

第二行那个 2.6% 不要当成常态：那是因为这段文本重复度极高， 真实网页的压缩率通常在 30%~70% 之间。 所以「压缩能省 97%」这句话只对这份样本成立，换成图片、视频，压缩率完全是另一个量级。 第三行那个 Base64 会把体积放大 33%（4/3）： 所以它能不用就不用—— 只在「必须走纯文本通道」时才用，比如把图片塞进 JSON、或者把二进制塞进邮件正文。 很多人以为 Base64 是「编码所以更省」，正好搞反了。 这里还有一层：压缩不是免费的，它要 CPU、要时间。 所以静态资源「预先压缩好存着」，动态内容才「现压」—— 这就是 gzip_static 这类配置存在的原因。

三、减往返、拉距离

三个动作的完整清单：

第二行省的是「固定开销」：一次往返 168 毫秒，减掉十次就是 1.7 秒。 这比「把图片压小一半」的收益大得多，因为压缩只影响传输时间，而往返是纯等待。 第三行省的是「光速」：电信号在光纤里大约每毫秒 200 公里， 所以北京到广州（约 2000 公里）单程就要 10 毫秒。 一个往返 20 毫秒——这就是「为什么 CDN 有用」的物理基础。 把服务器搬到离用户 200 公里的地方，往返就只剩 1 毫秒。 三个动作的优先级也是这个顺序的倒序：拉距离收益最大（量级变化），减往返次之，减字节最后。 所以「先把机房搬到用户旁边」比「把图片压到极限」有用得多。

四、动手 Demo：发布者视角，同一份内容怎么传得更省

把同一段文本压成三种形态，看字节数怎么变。 Base64 那一行会变大，这是故意的。

import zlib, base64

src = ('网络协议分层的本质是把复杂问题切成若干段，'
       '每段只解决一个问题。') * 60
raw = src.encode('utf-8')
z = zlib.compress(raw, 9)
b64 = base64.b64encode(z)

print('字符数 %d' % len(src))
print('%-12s %-8d %5.1f%%' % ('UTF-8 原文', len(raw), 100))
print('%-12s %-8d %5.1f%%' % ('zlib 压缩', len(z), len(z) * 100.0 / len(raw)))
print('%-12s %-8d %5.1f%%' % ('再 Base64', len(b64), len(b64) * 100.0 / len(raw)))

实跑输出：

--------------------------------------------------------------------
发布者视角，同一份内容怎么传得更省
--------------------------------------------------------------------
**从「信息发布者」的角度看网络，问题就变成一句话：同样的内容，怎么用更少的字节送到。**

同一段文本（2520 个字符）：

  形态           字节数     相对原文
  -----------------------------------
  UTF-8 原文     5040       100%
  zlib 压缩      133        2.6%
  再 Base64      177        3.5%

**第二行的压缩率之所以这么高，是因为这段文本重复度极高**——
**真实网页的压缩率通常在 30%~70% 之间。**
**第三行那个 Base64 会把体积放大 33%**（4/3），
**所以它能不用就不用**——**只在「必须走纯文本通道」时才用，比如把图片塞进 JSON。**

**从这里能看出「发布者视角」的三个动作**：
**① 减少字节（压缩、换格式）② 减少往返（合并请求、长连接）③ 拉近距离（CDN）**
**三件事都是围绕「用户等待时间」做的**，
**不是围绕「服务器省资源」做的**——**这个视角转换是理解现代 Web 架构的起点。**

2520 字符 → 5040 字节 → 133 字节 → 177 字节： 原文是 5040 字节（中文一个字 3 字节），压到 133 字节。 这个压缩率高得离谱，因为这段文本重复了 60 遍。 Base64 把 133 涨到 177，正好是 4/3 倍：这就是「Base64 会放大体积」的直接证据， 它能不用就不用。 真实网页的压缩率通常在 30%~70%，这里的 2.6% 只说明「重复度越高、压缩越狠」， 不能当成普遍结论。

30 秒实验

1. 把 * 60 改成 * 1，看压缩率变成多少——这就是「重复度决定压缩率」。
2. 把 src 换成一段随机字符，看 zlib 还能不能压。
3. 算一下：北京到广州往返 20 毫秒，如果服务器搬到 200 公里外，往返变成多少？

常见误区

1. 以为 Base64 能省空间。 它会把体积放大 33%，只是为了走纯文本通道。
2. 以为压缩率越高越好。 高压缩率需要高重复度，真实网页通常只有 30%~70%。
3. 以为优化就是「压缩资源」。 拉距离与减往返的收益更大，因为省的是纯等待时间。

第一章到此结束。下一章进入 2：TCP／IP 基础知识—— 把这一章的分层、地址、设备，落到 TCP／IP 的具体实现上。

• ☐ （本章完，下一节 2.1.1 从军用技术的应用谈起）

相关笔记

• 移动通信
• 7层通信
• 📚 图解TCP／IP · 索引