题干与适用场景
一个文档站点每次发布都会生成相似的 HTML、CSS 和 JavaScript。团队希望让后续响应复用先前响应作为 Brotli 或 Zstandard 字典，降低重复传输，但浏览器支持仍不完全一致，且响应可能包含用户私密数据。请依据 Compression Dictionary Transport 设计灰度、缓存和安全方案。
RFC 9842 定义了通过 Use-As-Dictionary 声明字典、客户端用 Available-Dictionary 提示可用字典，再协商字典压缩编码的机制。规范要求只在 HTTPS 安全上下文使用；MDN 当前将该能力标为 Limited availability，因此不能把它当成所有浏览器都支持的必选路径。
面试官考察点
- 能否讲清字典注册、匹配、哈希协商、编码选择和普通压缩回退。
- 能否处理字典新鲜度、缓存键、版本发布、CDN 和多节点一致性。
- 能否识别共享字典导致的内容推断或压缩侧信道风险。
- 能否根据浏览器能力、HTTPS 和响应可读性设计渐进增强。
- 能否用真实指标证明节省了字节，同时没有扩大错误率或隐私暴露。
回答前需要澄清的问题
- 目标浏览器、WebView、代理和 CDN 是否支持对应字典编码？是否允许只对 Chromium 灰度？
- 哪些响应是公开、同源且高度重复的，哪些包含用户、租户或权限相关数据？
- 字典由谁生成、签名、过期和回滚，发布版本是否与资源哈希绑定？
- 缓存是否按语言、租户、授权状态和内容编码分隔？
- 站点是否已有 Brotli、Zstandard、ETag、Early Hints 或 service worker 缓存策略？
30 秒回答框架
“我先按浏览器能力和响应敏感度筛选公开、同源、重复度高的资源。服务器只在 HTTPS 下通过 Use-As-Dictionary 声明版本化字典，客户端带 Available-Dictionary 后再选择 dcb、dcz 或普通 Brotli/gzip。字典和内容一起做版本、哈希、缓存隔离，敏感响应不共享。先灰度 Chromium 和少量资源，观察压缩后字节、解码错误、缓存命中和隐私告警，任何不支持或校验失败都回退普通编码。”
分步骤深入解答
- 选择适合的资源。 优先静态、公开、同源且版本稳定的资源；不要把用户个性化 HTML、账户数据、跨租户响应或包含秘密的内容放进共享字典。先测重复度和字典收益，再决定是否值得引入复杂度。
- 建立协商流程。 资源响应用
Use-As-Dictionary声明匹配范围、类型、标识和新鲜度。客户端有匹配字典时，在请求中发送Available-Dictionary哈希，并在Accept-Encoding中声明支持的字典编码；服务器仅在双方可用且字典仍新鲜时返回dcb或dcz，否则使用普通编码。
HTTP/2 200
Content-Type: text/javascript
Cache-Control: public, max-age=3600
Use-As-Dictionary: match="/assets/*", id="docs-v42", type="dictionary"
HTTP/2 200
Content-Encoding: dcb
Vary: Accept-Encoding, Available-Dictionary- 固定一致性边界。 字典 ID、资源版本和内容哈希进入发布工件；CDN 节点必须能取得相同字典，不能让一半节点返回旧字典、一半返回新编码。
Vary和缓存键要覆盖会改变表示的请求头，避免把字典压缩响应发给不支持的客户端。
- 处理新鲜度与回滚。 字典过期、撤回或内容版本切换时，服务器停止声明并回退普通压缩。保留旧字典一段受控时间以吸收缓存，但设明确下线时间；回滚只需撤下声明、清理 CDN 变体并恢复 Brotli/gzip，不应依赖客户端清空缓存。
- 隔离隐私风险。 字典内容应与同源公开资源一致地保护。若攻击者能控制部分输入并观察压缩大小，重复片段可能泄露字典或响应内容；避免把秘密与攻击者可控文本放在相同压缩上下文，必要时关闭字典压缩。HTTPS 保护传输，但不能消除压缩侧信道。
- 设计渐进增强。 能力探测和服务器协商失败时，继续返回 Brotli、gzip 或未压缩响应。先选一组静态资源和少量浏览器，比较
Content-Encoding分布、传输字节、TTFB、解码错误、缓存命中和回退率；没有稳定收益就撤回。
高质量示范回答
我会先把范围限定为公开、同源、版本化且重复度高的静态资源，排除用户 HTML、租户数据和秘密。服务器在 HTTPS 下用 Use-As-Dictionary 声明一份带 ID、匹配范围和过期时间的字典；客户端带 Available-Dictionary 后，服务器才在 Accept-Encoding 协商成功时返回 dcb 或 dcz。不支持、字典过期或哈希不匹配时，普通 Brotli/gzip 是无感回退。
发布系统把字典、资源哈希和 CDN 缓存变体作为同一工件，确保所有节点一致，并用 Vary 隔离编码和字典请求头。安全上，我不会把可控输入和秘密放进同一压缩上下文；即使 HTTPS 正常，压缩大小仍可能产生侧信道。灰度从 Chromium 的少量静态资源开始，监控节省字节、缓存命中、解码错误、回退和隐私告警，收益不足或风险上升就撤下字典声明。
常见错误
- 错误表现： 对所有响应启用共享字典 → 失败原因： 个性化或敏感数据可能进入可推断的压缩上下文 → 修正方法： 只选择公开静态资源，敏感响应保持普通压缩。
- 错误表现： 只检查
Accept-Encoding，忽略字典哈希和新鲜度 → 失败原因： 客户端可能用错字典或解码失败 → 修正方法： 绑定 ID、哈希、版本和过期策略。 - 错误表现： CDN 只按 URL 缓存 → 失败原因： 字典压缩响应可能发送给不支持的客户端 → 修正方法： 用
Vary和缓存键隔离编码、字典头与资源版本。 - 错误表现： 把 HTTPS 当作全部安全保证 → 失败原因： 压缩侧信道仍可能泄露重复片段 → 修正方法： 隔离攻击者可控输入与秘密，必要时关闭字典压缩。
追问及应对
浏览器不支持时会发生什么？
服务器只在协商到字典编码且字典可用时返回 dcb 或 dcz。其他请求继续使用 Brotli、gzip 或未压缩响应；监控回退率，不能要求客户端升级才能访问页面。
字典应该多久过期？
根据资源发布频率、重复收益和撤回速度决定，并把过期时间写入发布策略。静态版本切换时保留短暂重叠窗口，过后撤下旧字典并清理 CDN，避免无限保留含旧内容的字典。
如何测试解码和缓存正确性？
用支持与不支持的浏览器、HTTP/1.1、HTTP/2、不同 CDN 节点和冷暖缓存测试。验证 Vary、内容哈希、解码结果、304、回源和普通编码回退，不能只看压缩比。
什么信号会让你立即关闭？
出现跨用户内容混用、字典哈希不一致、解码错误、缓存污染、异常压缩大小或隐私扫描告警时，立即撤下 Use-As-Dictionary，恢复普通编码并保留现场指标。
参考资料
- Compression Dictionary Transport（RFC 9842）
- MDN Compression Dictionary Transport
- Chrome for Developers：Improving Google Search with Compression Dictionaries
- Chromium Compression Dictionary Transport 文档
面试作答要点
先讲公开静态资源筛选和协商头，再讲字典版本、缓存键、HTTPS、侧信道、渐进增强和回滚。收益必须用字节、缓存与错误指标验证。
一句话总结
共享压缩字典能减少重复传输，但只有在资源隔离、版本哈希、浏览器回退和隐私护栏同时成立时才适合灰度。