背景与旧方案问题

在 CDN 场景下，视频拖拽、断点续传、包管理器等都会使用 HTTP 范围请求（Range Request）获取大文件的部分字节。Cloudflare 原有基于 nginx 的范围缓存采用按区域固定范围大小的切片方式，范围尺寸作为缓存键的一部分。

该设计存在明显缺陷：

  • 范围过小会导致大量回源小请求及内存聚合压力；
  • 范围过大则下载远超客户端所需数据，浪费带宽与磁盘 IO；
  • 修改范围尺寸会使缓存失效；
  • 同范围并发请求相互阻塞，且无法与并发流式缓存结合。

新方案：Origin Range Requests

Cloudflare 在将缓存从 nginx 迁移到 Pingora 后，利用后者固定大小磁盘分块的特性重构逻辑：范围尺寸不再作为配置项，直接等于缓存块大小。

核心处理流程

  1. 解析客户端 Range 头，查询已缓存字节与范围覆盖元数据；
  2. 从磁盘或内存流式读取已有部分；
  3. 对缺失部分按块边界对齐回源，存入通用缓存块；
  4. 仅向客户端返回所请求字节，并正确设置 Content-Range 与 Content-Length。

系统作为协调器，可组合缓存前缀、进行中下载与新建回源后缀；若其他请求已覆盖所需字节，则复用该下载，突发大文件场景下显著减少回源。

一致性与安全

组合响应前会校验实体标签与文件大小一致性；支持 If-Range，版本不匹配则返回完整对象。对于即将解压的表示，不广告无法正确生效的范围，直接返回转换后完整响应，遵循标准 HTTP 语义（206 / 416）。

生产收益与可用性

内部迁移后，R2 对象存储 p99 TTFB 降低约一半，后续改进使分层缓存流量减少约 6%。该能力现已作为全套餐自助功能开放，用户仅需通过 Cache Rule 开启，无需调参或联系支持。

技术解读：对运维与 SRE 而言，该特性消除了“范围大小”这一易误用的旋钮，将回源放大行为从“用户配置驱动”变为“系统块边界约束”，带宽与缓存效率更可预测。在大规模分发大文件、AI 数据集或媒体时，可显著降低源站压力与跨 DC 流量，是边缘缓存架构向自适应演进的实例。