源站范围请求：无需调优范围请求即可提供大文件
内容提要
Cloudflare推出Origin Range Requests自助功能，重写缓存处理HTTP范围请求的方式。旧方案按客户配置的固定范围大小缓存，易造成过量下载或大量小请求，浪费带宽与磁盘。新方案基于Pingora的固定大小缓存块，按块边界从源站获取缺失字节，并协调已缓存、传输中与新获取的数据，确保响应仅含客户端请求的字节。R2的p99首字节时间约减半，分层缓存流量降约6%。用户可通过Cache Rules开启，无需调参。
延伸解读
从“客户调参”到“系统自适应”
旧方案要求客户为每个域名配置范围大小，但任何固定值都难以同时适配小范围跳转、顺序下载和大文件等场景，配置不当会直接放大源站流量或内存压力。新方案将范围大小与Pingora的固定缓存块对齐，客户不再需要理解内部缓存机制，只需通过Cache Rules开启。这降低了使用门槛，也把调优责任从客户转移到了平台侧。
收益有边界：小请求仍可能多取
文章明确说明，小于缓存块大小的请求仍可能触发整个块的源站获取，非对齐范围也会带来额外工作。区别在于这种额外开销是有界且可预测的，不再由客户选择的固定范围大小决定。因此，该功能并非消除所有多余下载，而是把浪费控制在系统可管理的范围内，读者不应将其理解为零开销。
正确性依赖协调与校验
范围响应可能由已缓存数据、传输中下载和新获取字节拼接而成，实现上需要检查每个源站响应是否匹配请求范围、总大小是否稳定、ETag是否一致。若If-Range不匹配，则返回完整表示；对即将解压的表示也不拼接范围。这说明该功能在提升效率的同时，把HTTP范围语义的正确性放在了重要位置，避免混合不同版本字节。
适用场景与前提条件
该功能面向客户端自然请求大文件部分的流量，如可拖动视频、可续传下载、软件包仓库、磁盘镜像和AI模型文件等。启用它不会让原本不可缓存的响应变得可缓存，且源站必须支持字节范围请求，部分获取才有意义。因此，它更适合大对象分发场景，而非通用缓存加速开关。
Q&A
Cloudflare的Origin Range Requests功能是什么？
Origin Range Requests是Cloudflare推出的自助功能，允许客户通过Cache Rules开启，无需调优范围大小。它重写了缓存处理HTTP范围请求的方式，基于Pingora的固定大小缓存块，按块边界从源站获取缺失字节，并协调已缓存、传输中与新获取的数据，确保响应仅含客户端请求的字节。
旧的缓存范围请求方案有什么问题？
旧方案按客户配置的固定范围大小缓存，范围大小需要权衡：小范围导致大量小源站请求和内存压力，大范围导致过量下载浪费带宽和磁盘。更新范围大小会使缓存失效，因为大小是缓存键的一部分。并发请求可能互相阻塞，且无法与并发流式传输结合，导致每个范围必须完全下载后才能读取。
新方案如何协调已缓存和正在下载的数据？
边缘节点先查找资产头部和范围覆盖元数据，从磁盘或内存流读取已缓存部分，对缺失部分按对齐的块边界从源站获取，写入新字节并记录完成的范围，最后组合各部分并设置Content-Range和Content-Length。如果现有下载覆盖了另一请求的字节，第二个请求可以附加到该下载，共享工作。
启用Origin Range Requests后对R2的性能有什么提升？
对于R2，p99首字节时间在缓存命中和未命中时均下降约一半。最近的一项改进让协调器将磁盘上已有字节与从上游获取的字节组合在单个响应中，使R2及类似工作负载的分层缓存流量周环比下降约6%，相当于每天减少数PB的数据中心间数据传输。
如何启用Origin Range Requests？
通过Cache Rules匹配大文件流量，并将Origin Range Requests设置为On。可以在仪表板的Caching > Cache Rules下操作，或通过API设置origin_range_requests: { "mode": "on" }。无需调整范围大小或联系支持。
Origin Range Requests适用于哪些场景？
适用于客户端自然请求大文件部分的流量，包括：渐进式和可寻址视频（如MP4）、可恢复的大文件下载、软件分发和包仓库、磁盘映像和归档等多GB对象、传输大型模型文件或获取模型工件选定区域的AI训练和推理工作负载，以及获取元数据或大文件小区域的客户端。
使用Origin Range Requests有什么限制或注意事项？
该功能不改变正常的缓存资格，启用它不会使原本不可缓存的响应变得可缓存。源站需要支持字节范围，部分源站获取才有用。对于小于块大小的请求，仍可能需要获取整个块；非对齐范围会增加额外工作，但额外工作是有界且可预测的。对于即将解压缩的表示，Cloudflare避免组合范围，而是提供转换后的完整响应。
