欢迎各位来到这场关于“带宽的圣杯”的技术研讨会。我是你们的主讲人，一个在代码堆里和比特流搏斗多年的资深工程师。
今天我们不谈架构设计，不谈微前端，也不谈如何把屎一样的代码重构得像艺术品。我们谈点更赤裸、更原始、更让人抓狂的东西——数据传输。
想象一下，你在使用一个基于 React Server Components (RSC) 构建的现代化应用。你点开了一个页面，服务器轰隆隆地跑了一圈，把数据吐了出来。看起来很美好，对吧？React 在服务端渲染，没有 JavaScript 突袭，页面加载很快。
但是，如果你的用户在高铁上，或者在中国西部的一个偏远山区，或者只是单纯被运营商限速了，那个所谓的“很快”瞬间就变成了“加载中……加载中……加载中……”。
为什么？因为 React Server Components 的数据流，本质上是一堆 JSON。而 JSON，是压缩界的“话痨”。它喜欢重复说同一个词，喜欢把 type: "div" 写得清清楚楚，哪怕这个 div 在页面上重复了一百次。
这时候，我们就需要熵减工程。熵减，简单来说，就是消灭混乱，增加有序，降低冗余。在低带宽环境下，我们不仅要压缩数据，还要优化压缩算法本身。
而我们的主角——Brotli 字典优化，就是那把能让我们从运营商手里抢回流量的手术刀。
第一部分：RSC 的“熵”之痛
首先，让我们看看 React Server Components 到底在传输什么。它不是简单的 JSON，它是 React 的序列化表示。
假设我们有一个简单的组件：
// Server Component
export default function UserList({ users }) {
return (
<div className="flex flex-col gap-4">
{users.map(user => (
<div key={user.id} className="card">
<h2>{user.name}</h2>
<p>{user.email}</p>
</div>
))}
</div>
);
}如果这个组件渲染了 100 个用户，服务端吐出来的数据流大概长这样（为了演示，进行了简化）：
{
"type": "div",
"props": {
"children": [
{
"type": "div",
"props": {
"className": "flex flex-col gap-4",
"children": [
{
"type": "div",
"props": {
"className": "card",
"children": [
{
"type": "h2",
"props": {
"children": ["Alice"]
}
},
{
"type": "p",
"props": {
"children": ["[email protected]"]
}
}
]
}
}
]
}
}
]
}
}看到了吗？每一个 div 都重复着 type: "div"，每一个 props 都重复着 props: {。这就是高熵。在信息论里，高熵意味着信息量大，但在传输带宽里，高熵意味着浪费。
Brotli 压缩算法很聪明，它知道 div 很常见，props 也很常见。但是，如果每个 div 的 className 都是 "flex flex-col gap-4"，Brotli 需要扫描整个数据流才能发现这个模式。这对于低带宽环境来说，太慢了！
我们需要做的，是主动熵减。我们要告诉 Brotli：“嘿，我知道接下来要出现什么，别傻乎乎地重新扫描了，直接用字典里的词！”
第二部分：Brotli 与字典的“热恋”
Brotli（BR）比 gzip 厉害的地方在于它支持字典压缩。
简单来说，标准的 gzip 就像是一个没读过书的文盲，他看到 div 就写 div，看到 className 就写 className。而 Brotli 加上字典，就像是一个带着《新华字典》的学霸。
当你给 Brotli 提供一个字典（比如一份包含 1000 个常见 HTML 标签、CSS 类名和 React API 的列表）时，Brotli 就可以不直接传输这些长字符串，而是传输一个“索引号”。比如，字典里的第 500 个词是 "div"，Brotli 就只传一个数字 500。
这就好比：你要去超市买 100 个苹果。
- 没有字典：你写一张清单，上面写：“苹果，苹果，苹果……”（传输量大，且重复）。
- 有字典：你给收银员看了一眼字典，说：“拿第 500 号商品，拿 100 次。”（传输量极小）。
但在低带宽环境下，我们不仅要靠字典，还要靠上下文感知。
第三部分：构建“超级字典”
普通的 Brotli 字典是静态的，比如 Google 的预定义字典。但对于 RSC 来说，静态字典是不够的，因为每个页面的数据流都不一样。
我们需要构建一个动态自适应字典。
核心策略：预测与采样
- 采样：服务端在渲染 RSC 时，记录下当前 Payload 中出现频率最高的字符串。
- 预测：根据当前渲染的组件上下文，预测下一步最可能出现的数据结构（例如，如果正在渲染一个列表，那么
type: "li"的概率极大）。 - 注入：将这些预测结果注入到 Brotli 的压缩流中。
让我们看看怎么写代码来实现这个逻辑。
代码示例：RSC Payload 采样器
// rsc-entropy-reducer.ts
interface RSCNode {
type: string;
props: Record<string, any>;
children: RSCNode[] | string;
}
class RSCDictionaryBuilder {
private frequencyMap = new Map<string, number>();
// 模拟 RSC 序列化过程
serialize(node: RSCNode): string {
this.analyze(node); // 关键：在序列化前先分析
return JSON.stringify(node); // 实际上这里应该使用自定义的紧凑序列化
}
private analyze(node: RSCNode) {
// 统计类型
this.count(node.type);
// 统计 props 的键名
Object.keys(node.props).forEach(key => this.count(key));
// 统计 props 的值（如果是字符串）
Object.values(node.props).forEach(val => {
if (typeof val === 'string') this.count(val);
if (Array.isArray(val)) val.forEach(v => {
if (typeof v === 'string') this.count(v);
});
});
// 递归分析子节点
if (Array.isArray(node.children)) {
node.children.forEach(child => this.analyze(child));
}
}
private count(str: string) {
this.frequencyMap.set(str, (this.frequencyMap.get(str) || 0) + 1);
}
// 生成 Top N 字典
buildDictionary(topN: number = 100): string[] {
return Array.from(this.frequencyMap.entries())
.sort((a, b) => b[1] - a[1])
.slice(0, topN)
.map(entry => entry[0]);
}
}
// 使用示例
const builder = new RSCDictionaryBuilder();
const payload = { type: "div", props: { className: "flex flex-row" }, children: [] };
const compactJson = builder.serialize(payload);
const myDict = builder.buildDictionary(50);
console.log("Top 50 Dictionary:", myDict);
// 输出可能包含: "div", "props", "className", "flex", "flex-row", "children", "type"这段代码虽然简单，但它揭示了原理。我们在序列化之前，已经“偷窥”了一遍数据。我们知道了 div、className、flex 这些词会反复出现。
代码示例：Brotli 字典注入器
现在，我们有了字典，怎么告诉 Brotli 去用？
Node.js 的 brotli 库原生支持字典，但我们需要自己构造字典数据。
import { BrotliCompress, BrotliDecode } from 'node:zlib';
import { promisify } from 'util';
const compressAsync = promisify(BrotliCompress);
// 1. 准备自定义字典
// 这里我们假设已经通过上面的 Builder 获取了高频词
const customDictionary = new Uint8Array([
...Buffer.from("div"), // 转为字节
...Buffer.from("props"),
...Buffer.from("children"),
// ... 更多高频词
]);
// 2. 准备要压缩的 RSC Payload (假设是 JSON 字符串)
const rscPayload = JSON.stringify({
type: "div",
props: { className: "flex flex-col gap-4" },
children: []
});
async function optimizeAndCompress(data: string) {
// 第一步：利用自定义字典压缩
const options = {
params: {
[BrotliConstants.DICTIONARY]: customDictionary
}
};
const compressed = await compressAsync(data, options);
console.log(`原始大小: ${data.length} bytes`);
console.log(`压缩后大小: ${compressed.length} bytes`);
console.log(`压缩率: ${((1 - compressed.length / data.length) * 100).toFixed(2)}%`);
// 返回压缩流
return compressed;
}
optimizeAndCompress(rscPayload);但是！ 这还不够。如果你只是把 JSON 字符串丢进去，Brotli 还是会先解析 JSON，然后压缩。真正的熵减工程是：在生成 JSON 之前，就把它变成“低熵”的格式。
第四部分：主动熵减——自定义序列化格式
这是最激进的一步。我们不再使用标准的 JSON.stringify。我们要发明一种只属于 RSC 的、极度紧凑的序列化协议。
想象一下，如果 div 不再是字符串 "div"，而是变成一个单字节 0x01。如果 className 不再是 "className"，而是变成 0x02。如果 "flex" 变成 0x03。
这就把字符串操作变成了位操作。
代码示例：自定义 RSC 序列化器
// rsc-compact-serializer.ts
// 定义一个映射表：高频 Token -> 索引
const TOKEN_MAP: Record<string, number> = {
"div": 1,
"span": 2,
"props": 3,
"children": 4,
"className": 5,
"flex": 6,
"flex-col": 7,
"gap-4": 8,
// ... 可以动态维护这个 map
};
// 辅助函数：将字符串转为紧凑索引，如果不在 map 中则保持原样（或者报错）
function encodeToken(str: string): number | string {
return TOKEN_MAP[str] || str;
}
// 自定义序列化逻辑
function compactSerialize(node: RSCNode): string {
// 我们不使用 JSON.stringify，而是拼接字符串
// 为了进一步压缩，我们可以省略引号和逗号，但这需要客户端配合解析器
// 为了演示兼容性，我们依然用 JSON，但替换了 key 和 value
const type = encodeToken(node.type);
const propsKeys = Object.keys(node.props).map(k => encodeToken(k));
const propsValues = Object.values(node.props).map(v => {
if (typeof v === 'string') return encodeToken(v);
return v;
});
// 构造一个结构化的字符串，而不是纯 JSON
// 例如: 1 3 5 6 8 [] 1 4 5 6 7 []
// 1 = div, 3 = props, 5 = className, 6 = flex...
let output = `[${type}]`; // 标记开始
if (Object.keys(node.props).length > 0) {
output += `{`;
propsKeys.forEach((key, index) => {
output += `${key}:${propsValues[index]}`;
if (index < propsKeys.length - 1) output += `,`;
});
output += `}`;
}
if (Array.isArray(node.children) && node.children.length > 0) {
output += `[`;
node.children.forEach(child => {
output += compactSerialize(child);
});
output += `]`;
}
return output;
}
// 测试
const originalNode = {
type: "div",
props: { className: "flex flex-col gap-4" },
children: []
};
// 模拟生成字典
const dict = Object.keys(TOKEN_MAP);
console.log("Dictionary:", dict);
console.log("Compact Output:", compactSerialize(originalNode));效果分析：
在标准 JSON 中：
"div" 占 4 个字符（包括引号）。
"className" 占 11 个字符。
"flex" 占 4 个字符。
在我们的自定义序列化中：
div 可能只是 1 个字节。
className 可能只是 1 个字节。
flex 可能只是 1 个字节。
这种空间换时间（在服务端生成时）的策略，对于低带宽场景是绝对划算的。服务端 CPU 跑得快一点没关系，用户的流量卡不卡才重要。
第五部分：Brotli 的“深度学习”式字典
光靠硬编码字典不够，我们还要利用 Brotli 的上下文建模能力。
Brotli 2.0（如果还没发布，我们就把它当成未来标准）引入了更高级的字典机制，可以基于上下文动态选择字典。
场景模拟：列表渲染
假设我们要渲染 100 个用户。
标准 RSC Payload：
{ "type": "li", "props": { "key": "1", "children": [...] }, ... } // 重复 100 次优化后的 RSC Payload：
{ "type": 1, "props": { "k": 2, "c": [...] }, ... } // 重复 100 次当 Brotli 处理这个流时，它发现 1 频繁出现。它会把 1 放入它的动态字典中。
更高级的玩法： 我们可以在服务端预计算一个“用户列表模板”。
如果用户 A 和用户 B 的列表结构一模一样，只是名字不同，我们可以传输一次结构模板，然后只传输差异。
但这属于“增量传输”，超出了 Brotli 字典优化的范畴。我们还是回到 Brotli 字典。
代码示例：动态上下文字典
我们可以根据当前渲染的组件类型，切换不同的字典。
// context-aware-compressor.ts
const DICTIONARIES = {
LIST_COMPONENT: new Uint8Array([...Buffer.from("li"), ...Buffer.from("key"), ...Buffer.from("user")]),
FORM_COMPONENT: new Uint8Array([...Buffer.from("input"), ...Buffer.from("type"), ...Buffer.from("value")]),
DEFAULT: new Uint8Array([]) // 空字典
};
function getDictionaryForComponent(componentType: string): Uint8Array {
if (componentType === 'List') return DICTIONARIES.LIST_COMPONENT;
if (componentType === 'Form') return DICTIONARIES.FORM_COMPONENT;
return DICTIONARIES.DEFAULT;
}
// 在 React 渲染流程中
function renderComponent(type: string, data: any) {
const dict = getDictionaryForComponent(type);
// 将字典注入到压缩流中
// 注意：在实际流中，你可能需要发送一个 "DICT" 标记，然后发送字典数据
// 这里简化演示逻辑
console.log(`Injecting dictionary for ${type}:`, dict);
// ... 执行压缩逻辑
}这种策略的妙处在于，它减少了字典传输的开销。如果我们每次都发一个巨大的字典，那字典本身就会占用带宽。只发相关的字典，才是真正的熵减。
第六部分：实战中的“坑”与“药”
在工程实践中，这事儿没那么简单。
1. 客户端解析器的负担
我们刚才写了自定义序列化器，把 "div" 变成了 1。但是，React 的客户端运行时（React Runtime）是不知道 1 代表什么的。它期待的是字符串。
所以，我们必须在客户端写一个反序列化器。这个反序列化器必须足够快，不能成为新的瓶颈。
// rsc-deserializer.ts
// 这是一个极其简化的示例，真实场景需要处理嵌套、递归和错误恢复
function deserializeCompact(input: string): RSCNode {
// 这是一个递归下降解析器
// 1. 读取类型
const typeStr = input[0]; // 假设是单字符
const type = mapCharToType(typeStr); // '1' -> 'div'
// 2. 读取 props
// 解析逻辑...
return { type, props: {}, children: [] };
}熵减的代价：客户端的 CPU 占用率可能会轻微上升。我们需要权衡：流量节省了 50%，但客户端多消耗了 2% 的 CPU。对于低带宽设备（如旧手机），这可能是值得的。
2. 字典的冷启动
如果第一次访问，我们的字典是空的，压缩率就是 0。
解决方案：预计算与缓存。
在服务端构建应用时，我们可以预先生成一套“通用 RSC 字典”。这套字典包含 React 的所有核心 API、Tailwind CSS 的常用类名、以及常见的数据结构模式。
我们可以把这个字典放在 CDN 上，或者预埋在客户端的代码里。客户端收到数据流后，先下载字典，再解压数据。这就像下载了一个 .zip 文件，先下载了 .zip 的索引表。
3. 熵减的极限
我们不能为了压缩而压缩。比如，把 div 变成 0，把 span 变成 1。
如果有一天 React 官方把 div 改名为 block，我们的自定义序列化器就全废了。
解决方案：版本化映射。
我们在序列化数据中包含版本号和映射表。
[V1, 0, 1, 2] -> Version 1, Token 0 is “div”, Token 1 is “span”。
这增加了复杂度，但也增加了鲁棒性。
第七部分：低带宽环境下的“流量经济学”
让我们算笔账。
假设一个 RSC Payload 原始大小是 100KB。
通过标准 Brotli 压缩（无字典优化），压缩率大概是 60%。
实际传输大小：40KB。
通过我们的熵减工程（自定义序列化 + 自定义字典）：
原始 Payload 变成 20KB（因为字符串变短了）。
Brotli 压缩率提升到 80%。
实际传输大小：4KB。
流量节省：96%。
在 3G 网络下，下载 40KB 可能需要 2 秒；下载 4KB 可能只需要 0.2 秒。用户体验的提升是指数级的。
更关键的是，对于高交互的 SPA（单页应用），RSC 的数据流是流式传输的。用户不需要等待整个 100KB 下载完就能看到首屏内容。
如果你的压缩算法太慢，阻塞了流式传输，用户就要盯着转圈圈。所以，熵减工程不仅仅是压缩数据，更是优化压缩速度。我们要在服务端用最快的手段，生成最紧凑的字符串。
第八部分：未来的展望——Brotli 2.0 与 WebAssembly
React Server Components 的未来是光明的，但带宽的瓶颈依然存在。
未来的优化方向包括：
- Brotli 2.0：支持动态字典，无需在压缩流中显式传输字典，由压缩库内部管理。
- WebAssembly (Wasm) 压缩器：在服务端使用 Rust 或 C++ 编写的超快压缩算法（如 LZMA 或 Zstandard），通过 Wasm 调用。这些算法对 RSC 这种高度结构化数据的压缩率可能远超 Brotli。
- 协议层优化：不仅仅是压缩 JSON，而是修改 RSC 的传输协议。比如，直接传输二进制结构体，而不是文本 JSON。React 团队已经在探索
react-server-dom-webpack的二进制版本。
结语：工程师的浪漫
各位，作为一名程序员，我们每天都在与代码打交道。我们追求代码的优雅、逻辑的严密、架构的完美。
但今天，我们做了一件更“接地气”的事情：我们为了节省那几个字节，绞尽脑汁。我们像炼金术士一样，试图从枯燥的数据流中提炼出黄金（更快的加载速度）。
这就是熵减工程。它不是冷冰冰的算法，它是我们对用户体验的极致追求。它告诉我们：在这个信息爆炸的时代，少即是多。无论是代码还是数据，最精简的形式，往往是最强大的形式。
希望今天的讲座能给你们带来一些灵感。下次当你看到一个 500KB 的 React Payload 时，不要只看到数字，要看到那里面隐藏的冗余和机会。去优化它，去压缩它，去用你的技术，让世界的网络变得更轻快一点。
谢谢大家！