🔗 功能：支持部分响应的缓存
- 目标：启用部分响应的缓存，并淘汰 range_offset_limit 配置选项。
- 状态：未开始
- 预计完成时间: 未知
- 版本:
- 优先级:
- 开发者:
- 更多：最初来自 Bug 1337
- 更多：http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-26
🔗 详细信息
（来自 Bug 报告）：当 range_offset_limit 设置为 -1 时，Squid 会尝试响应 HTTP Range 请求来获取整个对象。
- Bug：即使对象不可缓存（例如，因为它大于 maximum_object_size 或其他标准），整个对象仍会被获取。
- 如果整个对象无法缓存，Squid 应该恢复为仅获取 Range。
- Squid 应该能够仅获取对象所需的节（或节），并在后台填补空白。否则，像 Windows Update 这样的补丁获取机制，会以 N 个块的形式获取补丁文件，导致该文件被完整获取 N 次。这会造成巨大的低效率。Squid 应该始终在获取整个文件之前检查是否可缓存。
对此的正确修复是添加部分响应的缓存，从而完全消除对 range_offset_limit 的需求。
🔗 提议 1：分块排序
- 作者 Faysal Banna（附带一些小更新）
Squid 应该将每个对象存储为一系列 N 字节的块。当请求一个 Range 时，应将包含这些字节的整个块获取到相关的块位置。
例如；在我的缓存中，我会以 1KB 的范围保存，这意味着一个 40KB 的文件将成为 40 个 1KB 的块。
假设我的文件名为 faysal.data
chunk0 = faysal.data,0-1KB
chunk1 = faysal,data,1-2KB
...
现在假设文件尚未缓存也未被请求，并且我请求一个 Range：bytes=2100-3000。
Squid 应该做的是：
- 跳过 1024-2048 块
- 获取 2049-3072 块
- 可选地跳过 3073+ 块，或继续获取。
缓存接收到的块，并将响应标记为不完整。
- Rock 缓存已经将每个对象操作为大约 32KB 的一系列块。只需要扩展它来存储非连续的块，并在客户端请求的字节多于已存在字节时，检测到缺失的块以启动后台请求来填补空白。
🔗 提议 2：稀疏缓存文件
Squid 应该为整个文件大小打开一个磁盘文件，并仅填充收到的字节。其余部分稍后可以通过后台请求加载。
注意：需要某种方法来映射已接收的文件字节，并考虑每个缓存对象文件中的可变长度元数据头。
🔗 提议 3：按 Range 缓存
Squid 使用额外的缓存键组件缓存 Vary 响应。Range 响应应该使用类似的机制缓存，修改 Range 的缓存键。
注意：需要逻辑来表示变体元条目中所有已存储 Range 的列表。Vary 缓存使用 X-Vary-Headers。Range 需要一个有效载荷。
更新：Store-ID 助手可能可用于跟踪哪些 URL 被不完整地存储，并处理键的修改。
分类: WantedFeature
导航：站点搜索，站点页面，类别，🔼 向上