我已閱讀了HTTP/2規範和其他幾個教程中的push-promise，並有一個概念作爲概念。MVC應用程序中的HttpResponse.PushPromise（）的工作示例
我已閱讀here in SO爲什麼在未來的日子裏，捆綁銷售不會相關。所以，如果我必須將推送承諾整合到應用程序中，那麼這是一個理想的地方。是否應該在重定向到Action方法的視圖之前？或者，在視圖中的腳本？據我搜查，我找不到任何例子。
請有人分享他們在真實代碼中實施的經驗。如果您必須同時支持兩種協議，它看起來像是一個開銷嗎？另外，如果我使用IIS 10，那麼是否有任何配置更改需要我支持這兩種協議？ [據我所讀，我們不必。但總是更好地留意一些專家。]
因此，如果我必須將推諾承諾整合到應用程序中，那麼理想的地方是做什麼的。是否應該在重定向到Action方法的視圖之前？或者，在視圖中的腳本？
我在控制器操作方法中做了試驗，但是如果你有共同的資源，你可能想把它移到管道中更基本/共享的地方。任何可以訪問HttpResponse對象的地方都可以工作。正如我注意到here，您需要使用PushPromiseoverload，它採用HTTP方法和標頭，如果您推送的內容將根據任何請求標頭而變化，例如， 接受編碼（壓縮）。
如果您必須同時支持兩種協議，看起來像是開銷嗎？另外，如果我使用IIS 10，那麼是否有任何配置更改需要我支持這兩種協議？
您不需要明確地做任何事情來支持這兩種協議; IIS會照顧它。每David So of Microsoft，「提供的客戶端和服務器配置支持HTTP/2，然後IIS將使用HTTP/2（或回退到HTTP/1.1如果不可能）」。即使您使用服務器推送，情況也是如此：「如果底層連接不支持推送（客戶端禁用推送，或HTTP/1.1客戶端），則該呼叫不執行任何操作並返回成功，因此您可以安全地調用API需要擔心是否允許推送。「順便提一句，如果你想在Windows Server 2016上禁用HTTP/2，你可以這樣做。via the registry。
除了按照David So的建議檢查IIS日誌之外，還可以通過在Chrome的Network選項卡中右鍵單擊標題行（名稱，狀態，類型等）來驗證HTTP/2，然後檢查「協議」;你會看到HTTP/2響應的「h2」。您可以通過查看Chrome HTTP/2內部頁面（chrome：// net-internals /＃http2）並查看您的域的「推送」和「推送並聲明」列來驗證推送承諾。
我相信，如果最終文件的**內容**將根據標題而有所不同，那麼您只希望在'headers'中使用重載。在壓縮的情況下，即使用戶禁用了壓縮並刷新了頁面，正確的（所需的）文件也將被緩存。只有當標題影響內容時，你需要使用這個過載 –
我不清楚你的意思。推送承諾是客戶根據您的初始響應請求的其他資源;我不確定刷新頁面與什麼有關。即使最初的請求帶有兼容的Accept-Encoding標頭，如果您使用[僅使用虛擬路徑的重載]來推送資源（https://msdn.microsoft.com/zh-cn/library/dn823329.aspx ），推送的資源將被解壓縮;您必須將初始請求的（相關）頭傳遞給[其他重載]（https://msdn.microsoft.com/en-us/library/dn823340.aspx）。 – ejohnson