Web缓存如何降低请求对象的接收延迟？适用于全部还是部分请求？

• 缩短网络传输路径：缓存节点大多部署在离用户物理距离更近的边缘节点，无需每次请求都跨地域、跨运营商访问远在核心机房的源站，直接返回本地存储的内容，这部分减少的传输耗时通常占总请求延迟的60%以上。
• 省略源站计算开销：对于需要源站做数据库查询、逻辑渲染才能返回的内容，缓存直接返回已经处理完成的静态结果，完全省去了源站的业务处理耗时。
• 减少传输异常损耗：边缘缓存的出口带宽压力远低于核心源站，请求也无需经过拥堵的骨干网络，出现丢包重传的概率大幅降低，传输稳定性更高，间接降低了平均请求延迟。

缓存的收益核心取决于命中率，行业内常规的静态资源缓存命中率通常在90%_{98%之间，也就是说仅有2%}10%的请求需要回源，无法享受缓存的低延迟收益，甚至可能延迟略高于直连源站。

以下是缓存无法降低延迟的典型场景：

• 首次请求某一对象时，缓存节点还没有存储对应内容，需要先回源拉取再返回给用户，整个链路比用户直接访问源站多了一层缓存节点的转发，延迟反而会比直连略高。
• 缓存对象达到设置的过期时间，或是源站内容更新触发了缓存主动淘汰，用户请求时缓存需要重新回源校验或拉取最新内容，这部分请求也无法享受缓存加速。
• 源站通过Cache-Control: no-cache/Cache-Control: no-store头强制要求不缓存的内容，比如实时交易数据、敏感个人信息等，每次请求都必须回源，缓存完全不会起到降延迟的作用。
• 用户个性化专属内容，比如个人中心页面、定制化推荐结果等，不同用户访问的内容完全不同，缓存命中率极低，几乎无法通过缓存降低延迟。

内容的提问来源于stack exchange，提问作者Yoshizawa Shun