共享代理缓存何时有助于爬虫
在期待共享正向代理缓存提升吞吐量之前，先评估重复资源、新鲜度和爬虫的实际请求。
假设若干浏览器工作进程打开同一个网站的多个页面。这些页面引用相同的样式表、徽标和脚本包。当响应可以复用时，共享正向缓存可以让第一次抓取对后续工作进程也有价值。
现在改变负载：每个工作进程只下载一个 HTML 文档，从不加载其链接的资源。公共样式表仍存在于标记中，但没有任何工作进程请求它。它对代理的缓存命中率毫无贡献。
从爬虫实际发出的请求开始
渲染页面的浏览器与获取页面源码的 HTTP 客户端会产生不同的请求集合。在选择缓存设计之前，先检查这些集合。
| 工作负载 | 共享复用的可能性 |
|---|---|
| 工作进程反复抓取相同的公共资源 | 在新鲜度和缓存键规则允许时有用 |
| 每个请求都有唯一的 URL 或响应变体 | 可复用的重叠很少 |
| 响应在复用前需要重新验证 | 可能节省响应字节，但仍需要一次向上游的往返 |
| 工作进程已从自己的本地缓存满足请求 | 这些请求可能永远到不了共享代理 |
只有 URL 相同还不够。响应的新鲜度策略以及 Vary 指定的字段可以区分不同表示。私有、不可存储或需认证的内容需要适用的共享缓存规则；不应仅仅为了提高命中次数而把它强行并入一个公共结果。
对于普通的 HTTPS CONNECT 流量，正向代理承载的是加密隧道，内部没有可缓存的 HTTP 对象。部署 TLS 检查时，信任与处理行为不同。评估对象缓存是否可用时，应纳入实际模式。
缓存命中可以避免向上游获取，而缓存未命中仍要支付中间层的工作。针对预期负载，比较已完成的有效字节、上游流量和延迟。线程数描述的是并发度，并不描述这些线程共享了多少可复用内容。