我一直在阅读有关 HTTP/2 的文章，服务器预先将资源推送给客户端的想法看起来不错。但是，如果客户端不需要它，因为客户端已经在上次访问时缓存了它，该怎么办？
似乎有一个恢复流允许客户端立即终止流。但是如果服务器速度太快并且已经发送了流，会发生什么情况？RST_STREAM 是否能有效地向服务器发出文件已缓存的信号？
答案1
是的，这就是 RST_STREAM 的要点。
您说得对，这会增加发生得太晚的风险，对于以下两方面来说：
服务器 — 当收到 RST_STREAM 消息时，它将浪费时间来获取资源。
客户端 - 因为当客户端意识到不需要时，部分/大部分/所有资源可能已经发送，并发送了重置流。这会浪费时间和资源（尤其是移动设备上的带宽！）。
RST_STREAM 应是最后的手段，而不是用来防止资源流失的手段。否则，它很容易成为性能问题，而不是解决方案。
我们需要明智地只在需要的时候推动有可能需要资源，有多种方法可以实现这一点，但目前还没有公认的标准。我曾在博客中提到一种使用 cookies 的方法例如，还有各种基于 cookie 和其他选项的缓存摘要已被提出。HTTP/2 规范对于如何最好地实现这一点保持沉默（可能故意如此）。
我个人认为服务器推送是 HTTP/2 中最有趣的部分之一，我们需要花一些时间来了解如何正确使用它，并且可能会产生各种有趣的应用程序。就像 HTTP/1.1 下的一些性能吹嘘技术（例如串联、精灵图……等）需要一段时间和一些实验来帮助推动协议可以做什么一样——尽管有趣的是，它们现在都已成为HTTP/2 下的反模式。也许将来 HTTP/3 出现后，服务器推送的一些技术也会变得一样！