我已经阅读了 HTTP/2 规范和其他几个教程中关于 push-promise 的内容，并且有了一个概念。
我在这里读过为什么捆绑在未来几天不会那么重要。因此，如果我必须将 push promise 合并到应用程序中，那么理想的地方是哪里。是否应该在从 Action 方法重定向到视图之前？或者，在视图中的脚本中？据我搜索，我找不到任何例子。
请有人分享他们在真实代码中实现的经验。如果您必须同时支持这两种协议，这似乎是一种开销吗？
另外，如果我使用的是 IIS 10，那么我应该做任何配置更改来支持这两种协议吗？[据我所知，我们不必这样做。但总是更好地注意一些专家。]
因此，如果我必须将 push promise 合并到应用程序中，那么理想的地方是哪里。是否应该在从 Action 方法重定向到视图之前？或者，在视图中的脚本中？
我在试验时在控制器操作方法中完成了它，但是如果您有公共资源，您可能希望将其移动到管道中更基本/共享的位置。可以访问该HttpResponse对象的任何地方都应该可以工作。正如我在此处所指出的，如果您推送的内容会根据任何请求标头（例如接受编码（压缩））而有所不同，那么您将需要使用接收 HTTP 方法和标头的PushPromise 重载。
如果您必须同时支持这两种协议，这似乎是一种开销吗？
另外，如果我使用的是 IIS 10，那么我应该做任何配置更改来支持这两种协议吗？
你不需要明确地做任何事情来支持这两种协议；IIS 会处理它。根据Microsoft 的 David So，“如果客户端和服务器配置支持 HTTP/2，那么 IIS 将使用 HTTP/2（或者如果不可能，则回退到 HTTP/1.1）”。即使您使用服务器推送也是如此：“如果底层连接不支持推送（客户端禁用推送，或 HTTP/1.1 客户端），则调用不执行任何操作并返回成功，因此您可以安全地调用 API 而无需需要担心是否允许推送。”
顺便说一句，如果你想在 Windows Server 2016 上禁用 HTTP/2，你可以通过注册表来实现。
除了检查 IIS 日志，正如 David So 建议的那样，您可以通过右键单击 Chrome 网络选项卡中的标题行（名称、状态、类型等）并选中“协议”来验证是否正在使用 HTTP/2；您将看到 HTTP/2 响应的“h2”。您可以通过查看 Chrome HTTP/2 内部页面 (chrome://net-internals/#http2) 并查看您的域的“已推送”和“已推送并声明”列来验证推送承诺是否有效。