網路伺服器如何知道在 HTTP/2 請求中發送哪些文件？
據我了解，HTTP/2 可以通過單個連接發送網站資產（圖像、腳本、css 文件等），也可以推送它們。我感興趣的是這在實踐中是如何發生的。
通用伺服器（例如 Apache 或 nginx）如何決定發送什麼以及發送什麼？特別是，我知道理論上伺服器可以推送它知道將被請求的數據，但它怎麼知道要發送什麼？
例如，假設您有一個配置了 index.php 腳本的網路伺服器（Apache 或 nginx），該腳本生成一個頁面和許多資產。網路伺服器是否會自動解析 index.php 的輸出並將所有必需的文件連同響應一起發送？或者 index.php 文件是否需要以某種方式指定？
還是這樣的情況，雖然理論上可能，但在實踐中不會發生，瀏覽器只是稍後才請求資產？
這完全取決於伺服器及其配置方式。
大多數伺服器不夠智能，不知道要推送什麼，並且依賴於配置。因此，您可以設置配置來說明是否
index.html請求了任何文件，然後推送common.css和common.js. 然後考慮訪問的下一頁很重要 - 無需再次推送這些文件，因為使用者應該已經擁有它們。您可以使用基於 cookie 的方法來跟踪它。有關如何在 Apache 中進行配置，請參閱我的文章。一些伺服器（例如 Apache）還維護該連接的已知推送資產列表以避免過度推送，儘管這只適用於相同的連接，因此基於 cookie 的方法更好。許多伺服器和 CDN 可以使用 HTTP
link標頭來通知 Web 伺服器要推送哪些資產。這允許控制由後端應用程序伺服器進行，但推送從邊緣 Web 伺服器發生，因此不需要在 Web 伺服器上顯式配置。其他伺服器嘗試對此更加智能，並嘗試根據觀察請求猜測要推送哪些資源。例如，Jetty 有一個工具可以做到這一點。我無法證明這是多麼準確或有用。
還是這樣的情況，雖然理論上可能，但在實踐中不會發生，瀏覽器只是稍後才請求資產？
雖然推送肯定是可能的（我的部落格可以在上面的文章中看到），但推送確實存在問題。過度推動是一種真正的風險，即使沒有這種風險，其好處也從未真正得到證實。此外，還需要考慮實施問題和復雜性。所以現實情況是它並沒有被太多使用。根據我去年完成的一項研究，大約一半 (0.5%) 的網站使用 HTTP/2 推送。Chrome 已經聲明了一段時間，它正在考慮關閉對 HTTP/2 推送的支持。謹慎使用。