分块传输的“流”与“存”矛盾
故障定位思路
折腾分块传输时，我发现最麻烦的往往不是安装，而是配置。当源站响应头中出现 Transfer-Encoding: chunked 时，意味着内容将以不定长的数据块（chunk）依次发送，每个块前有16进制长度标识，最后以0长度块结束。这种机制对实时流媒体、大文件下载、动态接口推送极为友好——客户端可以边接收边处理，无需等待完整内容。
然而，CDN 边缘节点的传统工作模式是“先收后发”：将整个响应缓存到本地磁盘或内存后，再统一响应给后续请求。这种模式与分块传输的流式特性天然冲突。若边缘节点坚持缓存完整对象，则必须等待最后一个 chunk 到达，这将严重增加首字节时间（TTFB）；若直接透传，则无法复用缓存，CDN 的加速效果大打折扣。
因此，“优雅代理”的核心在于：在保持流式传输低延迟的同时，尽可能复用缓存，并保证跨请求的数据一致性。
关联教程：此处可内链到“分块传输部署与验证”内容。
三种代理模式的技术对比
模式一：纯流式透传（不缓存）
边缘节点收到分块响应后，立即将每个 chunk 转发给当前请求的客户端，完全不写入本地存储。这种模式的优点在于零延迟引入，适合动态数据或极短时间内的重复请求；缺点是同一资源若被多个用户请求，源站会反复承受相同负载，且边缘节点的缓存利用率极低。通常适用于 实时股票行情、WebSocket 升级流 等场景，其中 URL 本身已带有防缓存参数或源站明确禁止缓存。
模式二：分块级缓存（逐块存储）
为弥补纯透传的缺陷，部分高级 CDN 实现将每个 chunk 独立缓存——边缘节点收到一个 chunk 后，不仅转发给当前客户端，还将其切片存入缓存系统。当第二个请求到达同一资源时，边缘节点即可从缓存中读取已到达的 chunk 并立即转发，同时继续向后请求尚未到达的块。这种模式能显著降低源站压力，但要求缓存系统支持 增量写入与边读边写，对存储引擎的并发控制（如防读写冲突）提出较高要求。
实践中，该模式常用于 HLS/DASH 直播的 TS 切片：每个切片约 2–10 秒，分块传输的 chunk 边界恰好与切片边界对齐，缓存粒度合理。但对动态大文件（如按行推送的日志），chunk 尺寸可能极小（几十字节），导致缓存碎片化和元数据膨胀，反而降低性能。
模式三：分块重组后缓存（整文件缓存）
这是最接近传统 CDN 工作模式的方案：边缘节点在流式转发的同时，将所有 chunk 的内容拼接为完整实体，待最后一个 chunk 到达后，将完整响应存入缓存（同时清除临时缓存标识）。后续请求直接命中完整缓存，不再触发回源。
该方案的优点是兼容现有 CDN 缓存架构，无需改造存储引擎；缺点是 缓存填充前，所有请求都必须回源——无法利用部分缓存。若分块传输持续数十分钟（如长时间音频流），则首次访问期间大量请求仍会穿透到源站。适用于 文件上传后分块返回、短时间动态接口 等场景，其中传输时长可控在秒级以内。
相关阅读：此处可内链到“分块传输常见问题”专题。
关键设计：何时缓存，何时透传？
故障定位思路
优雅代理并非单一模式走天下，而是依赖可配置的 缓存策略表达式。边缘节点在收到 Transfer-Encoding: chunked 响应头后，先检查源站返回的 Cache-Control 指令：
- 若包含
no-store，则直接进入纯流式透传； - 若包含
public且s-maxage大于 0，则尝试分块级缓存或整文件缓存（取决于配置）； - 若未明确禁止缓存但无过期时间，则按默认缓存时长处理（建议仅短期缓存如 30 秒），避免过时数据滞留。
此外，分块传输的 chunked 编码本身不携带 Content-Length，导致 CDN 无法预知文件总大小。因此，边缘节点在决定分块级缓存时，常引入 分块数量上限 或 累计数据量上限（例如超过 1000 个块或 10 MB 后自动转为整文件缓存模式），防止内存溢出。
延伸阅读：此处可内链到“分块传输配置案例”相关文章。
生产环境验证与回滚
配置前的检查
部署分块传输代理策略前，必须进行回归测试：
- 抓包验证：在边缘节点上通过 tcpdump 或 Wireshark 捕获回源与响应客户端的数据包，确认 chunk 长度字段（十六进制）未被修改，且块顺序一致。
- 断点续传测试：模拟客户端在接收中途断开连接，再发起 Range 请求（若分块传输对应的是可随机访问资源），确认缓存系统能正确处理部分内容。
- 热点压力测试：用 wrk 或 ab 同时发送 100 个请求至同一个分块资源，观察源站连接数是否被有效收敛（应远小于客户端请求数）。
- 回滚方案：在 CDN 配置平台中对特定域名或路径启用“禁用分块缓存”开关，将模式一键切换为纯流式透传，确保紧急时源站不受缓存策略影响。
补充参考：此处可内链到“分块传输故障排查实例”。
想继续深入：此处可内链到“分块传输优化清单”文章。
实践建议：从粗粒度到精细化与分块传输
配置前的检查
大多数 CDN 服务商默认对分块传输采用纯流式透传，避免因缓存不当导致数据异常。若你希望通过缓存降低源站成本，可遵循以下步骤：
- 第一步：识别可缓存的分块资源。检查源站日志，找到 Content-Type 为 video/mp4、application/octet-stream 且 Transfer-Encoding 为 chunked 的请求，确认其 URL 稳定不携带随机参数。
- 第二步：测试整文件缓存模式。在 CDN 配置中对该路径启用“忽略 Transfer-Encoding”并强制缓存（需注意：源站返回的 Content-Length 可能缺失，CDN 会使用 chunked 尾部标记作为结束信号）。
- 第三步：若文件过大（> 100 MB），切换为分块级缓存。此时务必设置合理的内存限制（例如每 chunk 最大 64 KB），并监控边缘节点的 CPU 与内存使用率。
- 第四步：长期运行后检查数据一致性。通过对比源站文件的 MD5 与 CDN 缓存文件的 MD5（在边缘节点上直接计算），确保分块重组未引入乱序或重复。
记住：分块传输的本意是“边生产边消费”，CDN 代理的精髓也是“边代理边缓存”。只有当缓存粒度与传输粒度相匹配时，才能达成优雅。
延伸阅读